Thread: [limesurvey-developers] LS2 status update and suggestions
The leading Open Source survey tool
Brought to you by:
c_schmitz
From: Macasek, M. A. <mma...@mi...> - 2008-04-07 19:47:58
|
I believe my email issues have been resolved with regard to the LS dev mailing list. I¹ve been temporarily out of the loop and missed several key emails. In the limesurvey20/ source repo there is a folder cake¹ which contains the bulk of the CakePHP framework. This code is responsible for the functionality provided by Cake as well as some of the base templates that are used when generating a new cake app, controllers, models, etc. This framework is packaged so the cake files are not intermingled with our application code. This allows for easy upgrading and maintenance. Editing files inside this folder should be avoided. These changes prevent our ability to easily upgrade cake. We will find bugs in the cake framework. 1. Local fixes (i.e. code the LS2 team creates to fix the CakePHP bug) should be vetted by the LS2 development team/community before committing. A dev list email and dev team confirmation/thumbs up should be required. Let¹s prevent future headaches! 2. We immediately report the issue to the folks behind CakePHP (via their groups.google.com group and/or their bug tracking service) to ensure the fix is in the next cakePHP release. There should be no reason to change the .htaccess files under the cake folder; they do not impact the functionality of our application. Files in the top level config/ directory are mostly an extension of the cake folder as it holds all the application specific CakePHP configuration details. Any install process we come up with will likely modify/rewrite these required config files. This may seem like it is adding a lot to the install process but the install wizard¹ we provide will do all the heavily lifting here and it will not be exposed to the end user. I am in the process of extracting all the limesurvey specific configurations to a file config/limesurvey.php. This includes the CAS server options, system feedback email settings, etc. In order for the cake framework to load this file I added an include at the the bottom of the config/core.php file to include the config/limesurvey.php file. This modification allows us to separate the majority of the cake and limesurvey configuration details. Settings in this file will need to be tweaked by our install process. The config/database.php file is a CakePHP specific configuration file that will be tailored to the installed instances of LimeSurvey. Other config files will need to be tweaked as well. Combining these files is not an option as they are required by CakePHP. We need to leverage the framework by adopting its methodology. Let the framework do its job and not fight it. mod_rewrite concerns: This is an install instance-specific configuration and should be handled by our install wizard. Requiring mod_rewrite does not seem to be that big of a hurdle as long as the install process handles it. The current url rewrite of baseUrl/index.php/path/to/action is messy and does not exude a professional service. It makes the application appear more like a hack then a quality open source tool. Let¹s promote best web practices and standards which includes clean urls (baseUrl/path/to/action). We need to be conscious of how our commits will effect the rest of the team. We are currently heavily in development mode, there really is no (real) LS2.0 baseline yet and as such things are hairy. The install process may not be the cleanest and does not reflect the final install process in any way. What we have now is a configuration that works for the current developers. It is understandable that this config may not be optimal for many people but at the moment, it is all we have. We need to start addressing this immediately but without major impact to current development. We should not be making changes to the setup and committing them if they have not been vetted through the entire development community. We need to know the changes are coming and are optimal. We cannot check in incremental changes that breaks the system. The install wizard is not going to be easy to write. The wizard will expose a seemingly easy process to the user to collect the configuration specific details but under the hood there will be a lot of work needed to do the configuration. I am not suggesting this will be easy to do, if it was then everyone would do it. We should not just dive in and write code. We need to consider the options, devise the plan, and only then do we code. Finally, I just wanted to give a quick heads up on the pending removal of the Smarty templating system from our system views. Initially, we decided to use smarty templating to capture the question layouts and went with a blanket change of all the views in the system. This was a mistake. Smarty templating is great for restricting what can be done in a question layout template but has proven too limiting for our system views. We were fighting the tool instead of using it to our advantage. Brian Staats is migrating the system views back to CakePHP views and question layout templates will continue to use Smarty. Over the next few days all the .tpl files under the views folder will be migrated to .ctp files and the .tpl files will disappear. That is all for now. You feedback, suggestions, and comments would be great! Michael (with the nod from Brian, Rob, and Juhan) |
From: Carsten S. <car...@go...> - 2008-04-07 23:08:08
|
Hello Michael Macasek, Michael A. schrieb: > In the limesurvey20/ source repo there is a folder ‘cake’ which > contains the bulk of the CakePHP framework. This code is responsible > for the functionality provided by Cake as well as some of the base > templates that are used when generating a new cake app, controllers, > models, etc. This framework is packaged so the cake files are not > intermingled with our application code. This allows for easy upgrading > and maintenance. Editing files inside this folder should be avoided. > These changes prevent our ability to easily upgrade cake. > For the most part agreed. > We will find bugs in the cake framework. > 1. Local fixes (i.e. code the LS2 team creates to fix the CakePHP bug) > should be vetted by the LS2 development team/community before > committing. A dev list email and dev team confirmation/thumbs up > should be required. Let’s prevent future headaches! > 2. We immediately report the issue to the folks behind CakePHP (via > their groups.google.com group and/or their bug tracking service) to > ensure the fix is in the next cakePHP release. Agreed. > > There should be no reason to change the .htaccess files under the cake > folder; they do not impact the functionality of our application. > These .htaccess files impacted functionality since the application was not working without it so far (but should - I fixed it). Also it is not a problem to deactivate the .htacess files when a new CakePHP version is installed. I think that the default configuration should be not requiring mod_rewrite. A base install of LS2 should be runnable everywhere - independently of installed add-ons. If someone wants the pretty URLs and has the mod_rewrite package installed it would be no problem for that person to switch it on. The default configuration however should have it set to off. > Files in the top level config/ directory are mostly an extension of > the cake folder as it holds all the application specific CakePHP > configuration details. Any install process we come up with will likely > modify/rewrite these required config files. This may seem like it is > adding a lot to the install process but the install ‘wizard’ we > provide will do all the heavily lifting here and it will not be > exposed to the end user. I am in the process of extracting all the > limesurvey specific configurations to a file config/limesurvey.php. > This includes the CAS server options, system feedback email settings, > etc. In order for the cake framework to load this file I added an > include at the the bottom of the config/core.php file to include the > config/limesurvey.php file. This modification allows us to separate > the majority of the cake and limesurvey configuration details. > Settings in this file will need to be tweaked by our install process. > The config/database.php file is a CakePHP specific configuration file > that will be tailored to the installed instances of LimeSurvey. Other > config files will need to be tweaked as well. Combining these files is > not an option as they are required by CakePHP. We need to leverage the > framework by adopting its methodology. Let the framework do its job > and not fight it. I strongly disagree here. The only files the install process should modify is the database configuration and maybe, maybe a few special cakePHP settings. All other configuration data should be in the database. That allows for easy updates, no file permission problems, no data is overwritten on upload of a new version and all data is kept in one place (easy transfer from one server to another). Additionally providing a user interface with CakePHP to configuration data held in a database is alot easier than having to rewrite text files. I think having a limesurvey.php (i think the file name is non-saying too) is not the right way to store specific configuration data. > > mod_rewrite concerns: > This is an install instance-specific configuration and should be > handled by our install wizard. Requiring mod_rewrite does not seem to > be that big of a hurdle as long as the install process handles it. The > current url rewrite of baseUrl/index.php/path/to/action is messy and > does not exude a professional service. It makes the application appear > more like a hack then a quality open source tool. Let’s promote best > web practices and standards which includes clean urls > (baseUrl/path/to/action). > Saying that a URL like rewrite of baseUrl/index.php/path/to/action (this is not a rewrite) would make LS2 appear like a hack is very exaggerated. I think that a software proves its quality - not by the URL but by function and stability. There are certainly more important things to worry about than the look of the URL. For example the easiness of installation: First of all would the installer (written using CakePHP) not be running if the mod_rewrite is missing or misconfigured. Mod_rewrite is a big hurdle and so are things like PEAR packages. You really should do some support for LS1 in the forums and you will find out that most people don't even know how to set a session directory in their PHP configuration - even if they are theoretically able to do it. Installing mod_rewrite or installing PEAR packages is way over the head for most people installing LimeSurvey. So if you really want to have an external installer that configures CakePHP the only option to configure everything would be an installer that is not using CakePHP. Do you really want to do that? This would bloat the total package alot since all the database functionality for a non-CAKE application has to be deployed too. Additionally a non-Cake installer would not be able to activate mod-rewrite functionality and not be able to install PEAR on the server. Also you will need much more time to write such a non-Cake installer than just use the existing tools. I would like a generic CakePHP deployment alot more - one that runs out of the box (and which it already does in its current state regarding mod_rewrite) - meaning that the little installations needed for the database properties and migration can be executed inside the CakePHP framework - this is alot better than a bloated non-Cake installer that rewrites _text files_ (which imho is very backward) and setups the database. Additionally I would like to see all PEAR dependencies removed for the basic install (I don't consider 'migrate' as a part of this as it is a pure developer tool) and (for cases like phpCAS that is PEAR dependent) a module configuration inside LS administration where you can disable, enable, install, uninstall different kind of modules. The module configuration should be saved in the database. A disabled module will not be initialized and so does not need dependencies. On activation the module should check if the required libraries exist before binding the module and creating the related tables. This is very similar to Joomla, which works mostly that way. They have one of the biggest module repositories because it is a piece of cake to code and install a module inside the application using an easy interface. It works the same way there.. expect for the module files on installing the module no config files are written. All setup data is saved in the database by Joomla. Or take a look at SugarCRM, one of the big open source and very successful PHP software startups. SugarCRM stores everything in the database. No saving of configuration textfiles except for the basic database configuration. Most other good applications I know of do it the same way. > We need to be conscious of how our commits will effect the rest of the > team. We are currently heavily in development mode, there really is no > (real) LS2.0 baseline yet and as such things are hairy. The install > process may not be the cleanest and does not reflect the final install > process in any way. What we have now is a configuration that works for > the current developers. It is understandable that this config may not > be optimal for many people but at the moment, it is all we have. We > need to start addressing this immediately but without major impact to > current development. We should not be making changes to the setup and > committing them if they have not been vetted through the entire > development community. We need to know the changes are coming and are > optimal. We cannot check in incremental changes that breaks the system. > I totally agree. > > Finally, I just wanted to give a quick heads up on the pending removal > of the Smarty templating system from our system views. Initially, we > decided to use smarty templating to capture the question layouts and > went with a blanket change of all the views in the system. This was a > mistake. Smarty templating is great for restricting what can be done > in a question layout template but has proven too limiting for our > system views. We were fighting the tool instead of using it to our > advantage. Brian Staats is migrating the system views back to CakePHP > views and question layout templates will continue to use Smarty. Over > the next few days all the .tpl files under the views folder will be > migrated to .ctp files and the .tpl files will disappear. I am looking forward to that. Brian is doing great work! As a my first task and to get into CakePHP I am just writing a small installer that is checking for system requirements and doing the db setup. It is a module that does not need schema DB binding at this point even though it is a native Cake module. I am also testing internationalization that way (the installer is multilingual) and found the current CakePHP i18n system very limiting since it is using a strange way of mapping languages - with lots of languages missing. But maybe I am have overseen something - I am just exploring this part. The language switch in the first screen is already working and screen 2 is already using the chosen language. For now the installer has the following steps. # 1 : Welcome & Language choice # 2 : Pre-installation Check & Authorization # 3 : License Agreement # 4 : Database Configuration # 5 : Database Migration # 6 : Finish This is for first install. For updates I think there should be an upgrade module taking care. Anyway, I am still in the process of finding out how to force the user into this workflow and I am using a separate view template for each step which might be not optimal. This was my first week on CakePHP and I like it - but since you have several months of cake experience in advance I will certainly ask one or another thing - if that's okay for you. Best regards Carsten |
From: Juhan S. <juhan@MIT.EDU> - 2008-04-08 03:37:57
|
> >> >> mod_rewrite concerns: >> This is an install instance-specific configuration and should be >> handled by our install wizard. Requiring mod_rewrite does not seem to >> be that big of a hurdle as long as the install process handles it. >> The >> current url rewrite of baseUrl/index.php/path/to/action is messy and >> does not exude a professional service. It makes the application >> appear >> more like a hack then a quality open source tool. Let’s promote best >> web practices and standards which includes clean urls >> (baseUrl/path/to/action). >> > Saying that a URL like rewrite of baseUrl/index.php/path/to/action > (this > is not a rewrite) would make LS2 appear like a hack is very > exaggerated. > I think that a software proves its quality - not by the URL but by > function and stability. There are certainly more important things to > worry about than the look of the URL. Carsten, Great services should exceed your expectations and make you smile. It's more than raw # of functions and stability. Beautiful code matters (not that we're quite there yet... we obviously need help here). Ugly URLs are so 1999. LS2 needs to have easy to understand addressing. People, not just machines, are reading and remembering URLs. http://www.apple.com/quicktime/ http://www.flickr.com/photos/juhansonin http://en.wikipedia.org/wiki/Beauty vs http://www.amazon.com/gp/richpub/listmania/byauthor/A1QKRMQ4O9GIK1/ref=pd_ys_homenav_lm?pf_rd_p=258341001&pf_rd_s=right-1&pf_rd_t=1501&pf_rd_i=home&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0A18MTTNKK6WZNKJNCA3 http://www.weather.com/weather/local/02476?lswe=02476&lwsa=WeatherLocalUndeclared&from=whatwhere .... and millions more impossible to read URLs. I agree: performance and rockin' core features are a big measure of success. Let's not treat URLs like forgotten stepchildren. Tag, your it. -Juhan ps: Finally - some good tech talk on LS2!! Carsten, thanks for jumping into the code and discussion. |
From: Carsten S. <car...@go...> - 2008-04-08 08:12:46
|
Hello Juhan, > Carsten, > > Great services should exceed your expectations and make you smile. > It's more than raw # of functions and stability. Beautiful code > matters (not that we're quite there yet... we obviously need help here). > > Ugly URLs are so 1999. > LS2 needs to have easy to understand addressing. People, not just > machines, are reading and remembering URLs. > > http://www.apple.com/quicktime/ > http://www.flickr.com/photos/juhansonin > http://en.wikipedia.org/wiki/Beauty > > vs > > http://www.amazon.com/gp/richpub/listmania/byauthor/A1QKRMQ4O9GIK1/ref=pd_ys_homenav_lm?pf_rd_p=258341001&pf_rd_s=right-1&pf_rd_t=1501&pf_rd_i=home&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0A18MTTNKK6WZNKJNCA3 > http://www.weather.com/weather/local/02476?lswe=02476&lwsa=WeatherLocalUndeclared&from=whatwhere > > .... and millions more impossible to read URLs. > > I agree: performance and rockin' core features are a big measure of > success. Let's not treat URLs like forgotten stepchildren. > I totally agree with you. But the URL in this case is not going from http://limesurvey2/surveys to http://limesurvey2/index.php?moduleid=13&sessid=135723598267 (no, it won't be like that) but only to http://limesurvey2/index.php/surveys (oinly the index.php is inserted) To get the prettier URLs you have to have mod_rewrite installed on the server. And what worth is the prettier URL if 30% of the users (and hereby I am thinking of the private users) is not able to install the software from the start. (since mod_rewrite is needed for that). On the other hand it is no problem for a sysadmin (=experienced person) to activate the mod_rewrite settings after installation manually if the server is configured correctly. I did not say the prettier URL (using mod_rewrite) should not be possible. I am just saying that these things should not be activated by default and that the application has to be working under both conditions (with and without mod_rewrite). What you use in development as a default on your local machine is your own decision - but subversion version should default to non-mod_rewrite URLs. Best regards Carsten |
From: Brian S. <bs...@mi...> - 2008-04-08 11:56:44
|
Carsten, Just say no to ugly URLs. :) Seriously though... Is your stance on the (mod_rewrite == excluding % of users) based on admin privileges needed to install mod_rewrite or is it just more difficult to install mod_rewrite? (excuse my ignorance of apache moding) If it is the latter, then why can not the installer take care of mod_rewrite? Is it that difficult to include mod_rewrite in the installer? If it is the former, what LS user base does not have the correct privileges to install mod_rewrite (given the installer can do it for them)? Can you give a specific example? Thanks in advance for the response! On Apr 8, 2008, at 4:12 AM, Carsten Schmitz wrote: > Hello Juhan, >> Carsten, >> >> Great services should exceed your expectations and make you smile. >> It's more than raw # of functions and stability. Beautiful code >> matters (not that we're quite there yet... we obviously need help >> here). >> >> Ugly URLs are so 1999. >> LS2 needs to have easy to understand addressing. People, not just >> machines, are reading and remembering URLs. >> >> http://www.apple.com/quicktime/ >> http://www.flickr.com/photos/juhansonin >> http://en.wikipedia.org/wiki/Beauty >> >> vs >> >> http://www.amazon.com/gp/richpub/listmania/byauthor/A1QKRMQ4O9GIK1/ref=pd_ys_homenav_lm?pf_rd_p=258341001&pf_rd_s=right-1&pf_rd_t=1501&pf_rd_i=home&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0A18MTTNKK6WZNKJNCA3 >> http://www.weather.com/weather/local/02476?lswe=02476&lwsa=WeatherLocalUndeclared&from=whatwhere >> >> .... and millions more impossible to read URLs. >> >> I agree: performance and rockin' core features are a big measure of >> success. Let's not treat URLs like forgotten stepchildren. >> > I totally agree with you. But the URL in this case is not going from > > http://limesurvey2/surveys > > to > > http://limesurvey2/index.php?moduleid=13&sessid=135723598267 (no, it > won't be like that) > > but only to > > http://limesurvey2/index.php/surveys (oinly the index.php is > inserted) > > To get the prettier URLs you have to have mod_rewrite installed on the > server. And what worth is the prettier URL if 30% of the users (and > hereby I am thinking of the private users) is not able to install the > software from the start. (since mod_rewrite is needed for that). On > the > other hand it is no problem for a sysadmin (=experienced person) to > activate the mod_rewrite settings after installation manually if the > server is configured correctly. I did not say the prettier URL (using > mod_rewrite) should not be possible. I am just saying that these > things > should not be activated by default and that the application has to be > working under both conditions (with and without mod_rewrite). > What you use in development as a default on your local machine is your > own decision - but subversion version should default to non- > mod_rewrite > URLs. > > Best regards > > Carsten > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > limesurvey-developers mailing list > lim...@li... > https://lists.sourceforge.net/lists/listinfo/limesurvey-developers |
From: Macasek, M. A. <mma...@mi...> - 2008-04-08 12:05:39
|
Carsten, I think we are in agreement on some points and disagreement on other points, but that is a good thing. :) I feel we need to set a minimal baseline for the install and treat installs that are below this baseline as special cases. Mod_rewrite should be in that minimum. There will need to be a basic installer that collects initial configuration details, there is no reason this needs to live outside of Cake. This installer may be inside the application in the form of a system configuration page/wizard. The user will need to indicate their DB settings, maybe a global system email address, an initial admin account password, if they have mod_rewrite enabled (if they do not have it enabled provide a quick tutorial on how to turn it on, if the are able to great if not there is a fall back configuration), etc. There is no was we can have a simple extract zip and go with no initial setup. This configuration will potentially require a lot of work to get right but we need to do it. As for the 'put all the configuration details in a DB' idea, this is silly. We would have to then write bootstrap non-Cake code (which would need to replicate the DB access layer) for Cake so we can talk to the DB to get the Cake initialization config details (and change how Cake works, fighting the framework not leveraging it). Assuming the DB is on a remote system this will also involve web requests on top of the DB query. Other limesurvey settings should not be in the database either. A good example of this is authentication. You would rather have the system: 1. identify a user is not authenticated 2. Then you have to talk to the DB to figure out how they should be authenticating (lsDB, CAS, LDAP, etc). 3. This would also require the the DB to pull out the details for the authentication service (url, etc) 4. and finally perform the authentication? Why do we need to go to the DB here? This information will already be available if loaded during the Cake initialization process from the configuration files as CakePHP is designed to function. Even if we modified Cake to allow it to pull these details out of the DB at Cake's initialization time we would be needlessly performing extra web and DB request. The bottom line is querying the DB every time you need basic system configuration details is to expensive. Every time a request is handled Cake needs to reinitialize itself, so for every request we would be doing these DB calls just to initialize Cake, this is a performance nightmare. If the i18n support in Cake is insufficient we should modify it and give it back to the Cake Community. This can be done by either making a patch to the Cake baseline or via a plugin (there may even be a plugin in existence that better meets our needs check out the bakery off cakephp.org). Michael On 4/8/08 7:56 AM, "Brian Staats" <bs...@mi...> wrote: > Carsten, > > Just say no to ugly URLs. :) > > Seriously though... Is your stance on the (mod_rewrite == excluding % > of users) based on admin privileges needed to install mod_rewrite or > is it just more difficult to install mod_rewrite? (excuse my ignorance > of apache moding) > > If it is the latter, then why can not the installer take care of > mod_rewrite? Is it that difficult to include mod_rewrite in the > installer? > > If it is the former, what LS user base does not have the correct > privileges to install mod_rewrite (given the installer can do it for > them)? Can you give a specific example? > > Thanks in advance for the response! > > On Apr 8, 2008, at 4:12 AM, Carsten Schmitz wrote: > >> Hello Juhan, >>> Carsten, >>> >>> Great services should exceed your expectations and make you smile. >>> It's more than raw # of functions and stability. Beautiful code >>> matters (not that we're quite there yet... we obviously need help >>> here). >>> >>> Ugly URLs are so 1999. >>> LS2 needs to have easy to understand addressing. People, not just >>> machines, are reading and remembering URLs. >>> >>> http://www.apple.com/quicktime/ >>> http://www.flickr.com/photos/juhansonin >>> http://en.wikipedia.org/wiki/Beauty >>> >>> vs >>> >>> http://www.amazon.com/gp/richpub/listmania/byauthor/A1QKRMQ4O9GIK1/ref=pd_ys >>> _homenav_lm?pf_rd_p=258341001&pf_rd_s=right-1&pf_rd_t=1501&pf_rd_i=home&pf_r >>> d_m=ATVPDKIKX0DER&pf_rd_r=0A18MTTNKK6WZNKJNCA3 >>> http://www.weather.com/weather/local/02476?lswe=02476&lwsa=WeatherLocalUndec >>> lared&from=whatwhere >>> >>> .... and millions more impossible to read URLs. >>> >>> I agree: performance and rockin' core features are a big measure of >>> success. Let's not treat URLs like forgotten stepchildren. >>> >> I totally agree with you. But the URL in this case is not going from >> >> http://limesurvey2/surveys >> >> to >> >> http://limesurvey2/index.php?moduleid=13&sessid=135723598267 (no, it >> won't be like that) >> >> but only to >> >> http://limesurvey2/index.php/surveys (oinly the index.php is >> inserted) >> >> To get the prettier URLs you have to have mod_rewrite installed on the >> server. And what worth is the prettier URL if 30% of the users (and >> hereby I am thinking of the private users) is not able to install the >> software from the start. (since mod_rewrite is needed for that). On >> the >> other hand it is no problem for a sysadmin (=experienced person) to >> activate the mod_rewrite settings after installation manually if the >> server is configured correctly. I did not say the prettier URL (using >> mod_rewrite) should not be possible. I am just saying that these >> things >> should not be activated by default and that the application has to be >> working under both conditions (with and without mod_rewrite). >> What you use in development as a default on your local machine is your >> own decision - but subversion version should default to non- >> mod_rewrite >> URLs. >> >> Best regards >> >> Carsten >> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Register now and save $200. Hurry, offer ends at 11:59 p.m., >> Monday, April 7! Use priority code J8TLD2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaon>> e >> _______________________________________________ >> limesurvey-developers mailing list >> lim...@li... >> https://lists.sourceforge.net/lists/listinfo/limesurvey-developers > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > limesurvey-developers mailing list > lim...@li... > https://lists.sourceforge.net/lists/listinfo/limesurvey-developers |
From: Carsten S. <car...@go...> - 2008-04-08 13:20:48
|
Macasek, Michael A. schrieb: > Carsten, > > I feel we need to set a minimal baseline for the install and treat installs > that are below this baseline as special cases. Mod_rewrite should be in that > minimum. Sorry.. that doesn't fly. And then the person cannot install it? How would the message look like? 'Sorry you cannot install LS because we require mod_rewrite to be installed just to have prettier URLs from the start"? > There will need to be a basic installer that collects initial > configuration details, there is no reason this needs to live outside of > Cake. This installer may be inside the application in the form of a system > configuration page/wizard. The user will need to indicate their DB settings, > maybe a global system email address, an initial admin account password, if > they have mod_rewrite enabled (if they do not have it enabled provide a > quick tutorial on how to turn it on, if the are able to great if not there > is a fall back configuration), etc. As I said.. alot of users won't have the possibility to activate it. > There is no was we can have a simple > extract zip and go with no initial setup. This configuration will > potentially require a lot of work to get right but we need to do it. > As I said... I am all for a installer to > As for the 'put all the configuration details in a DB' idea, this is silly. > Oh.. that means they way most applications handle their configuration data is silly? > We would have to then write bootstrap non-Cake code (which would need to > replicate the DB access layer) for Cake so we can talk to the DB to get the > Cake initialization config details (and change how Cake works, fighting the > framework not leveraging it). Sorry, but this is false. There is no need to write bootstrap non-Cake code to access the db after basic install. Why would there? The controller/scheme for the install I am just working on does not need any DB connection and does not open the connections of the existing other modules/schemes either. So it is perfectly possible to have the basic installation in CakePHP to create and setup the DB for the first real usage. > Assuming the DB is on a remote system this > will also involve web requests on top of the DB query. Other limesurvey > settings should not be in the database either. A good example of this is > authentication. You would rather have the system: > > 1. identify a user is not authenticated > 2. Then you have to talk to the DB to figure out how they should be > authenticating (lsDB, CAS, LDAP, etc). > 3. This would also require the the DB to pull out the details for the > authentication service (url, etc) > 4. and finally perform the authentication? > Exactly. > Why do we need to go to the DB here? This information will already be > available if loaded during the Cake initialization process from the > configuration files as CakePHP is designed to function. Even if we modified > Cake to allow it to pull these details out of the DB at Cake's > initialization time we would be needlessly performing extra web and DB > request. There is no need to modify cake core files for this. > The bottom line is querying the DB every time you need basic system > configuration details is to expensive. Every time a request is handled Cake > needs to reinitialize itself, so for every request we would be doing these > DB calls just to initialize Cake, this is a performance nightmare. > Still most applications do it that way. It is very easy to pull the configuration from the DB and to cache it, maybe even in the users session. > If the i18n support in Cake is insufficient we should modify it and give it > back to the Cake Community. This can be done by either making a patch to the > Cake baseline or via a plugin (there may even be a plugin in existence that > better meets our needs check out the bakery off cakephp.org). > No there isn't anything available regarding that. I am in the process of contacting the developers about it already. Regards Carsten > Michael > > > On 4/8/08 7:56 AM, "Brian Staats" <bs...@mi...> wrote: > > >> Carsten, >> >> Just say no to ugly URLs. :) >> >> Seriously though... Is your stance on the (mod_rewrite == excluding % >> of users) based on admin privileges needed to install mod_rewrite or >> is it just more difficult to install mod_rewrite? (excuse my ignorance >> of apache moding) >> >> If it is the latter, then why can not the installer take care of >> mod_rewrite? Is it that difficult to include mod_rewrite in the >> installer? >> >> If it is the former, what LS user base does not have the correct >> privileges to install mod_rewrite (given the installer can do it for >> them)? Can you give a specific example? >> >> Thanks in advance for the response! >> >> On Apr 8, 2008, at 4:12 AM, Carsten Schmitz wrote: >> >> >>> Hello Juhan, >>> >>>> Carsten, >>>> >>>> Great services should exceed your expectations and make you smile. >>>> It's more than raw # of functions and stability. Beautiful code >>>> matters (not that we're quite there yet... we obviously need help >>>> here). >>>> >>>> Ugly URLs are so 1999. >>>> LS2 needs to have easy to understand addressing. People, not just >>>> machines, are reading and remembering URLs. >>>> >>>> http://www.apple.com/quicktime/ >>>> http://www.flickr.com/photos/juhansonin >>>> http://en.wikipedia.org/wiki/Beauty >>>> >>>> vs >>>> >>>> http://www.amazon.com/gp/richpub/listmania/byauthor/A1QKRMQ4O9GIK1/ref=pd_ys >>>> _homenav_lm?pf_rd_p=258341001&pf_rd_s=right-1&pf_rd_t=1501&pf_rd_i=home&pf_r >>>> d_m=ATVPDKIKX0DER&pf_rd_r=0A18MTTNKK6WZNKJNCA3 >>>> http://www.weather.com/weather/local/02476?lswe=02476&lwsa=WeatherLocalUndec >>>> lared&from=whatwhere >>>> >>>> .... and millions more impossible to read URLs. >>>> >>>> I agree: performance and rockin' core features are a big measure of >>>> success. Let's not treat URLs like forgotten stepchildren. >>>> >>>> >>> I totally agree with you. But the URL in this case is not going from >>> >>> http://limesurvey2/surveys >>> >>> to >>> >>> http://limesurvey2/index.php?moduleid=13&sessid=135723598267 (no, it >>> won't be like that) >>> >>> but only to >>> >>> http://limesurvey2/index.php/surveys (oinly the index.php is >>> inserted) >>> >>> To get the prettier URLs you have to have mod_rewrite installed on the >>> server. And what worth is the prettier URL if 30% of the users (and >>> hereby I am thinking of the private users) is not able to install the >>> software from the start. (since mod_rewrite is needed for that). On >>> the >>> other hand it is no problem for a sysadmin (=experienced person) to >>> activate the mod_rewrite settings after installation manually if the >>> server is configured correctly. I did not say the prettier URL (using >>> mod_rewrite) should not be possible. I am just saying that these >>> things >>> should not be activated by default and that the application has to be >>> working under both conditions (with and without mod_rewrite). >>> What you use in development as a default on your local machine is your >>> own decision - but subversion version should default to non- >>> mod_rewrite >>> URLs. >>> >>> Best regards >>> >>> Carsten >>> >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >>> Register now and save $200. Hurry, offer ends at 11:59 p.m., >>> Monday, April 7! Use priority code J8TLD2. >>> >>> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaon>> > e > >>> _______________________________________________ >>> limesurvey-developers mailing list >>> lim...@li... >>> https://lists.sourceforge.net/lists/listinfo/limesurvey-developers >>> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Register now and save $200. Hurry, offer ends at 11:59 p.m., >> Monday, April 7! Use priority code J8TLD2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >> _______________________________________________ >> limesurvey-developers mailing list >> lim...@li... >> https://lists.sourceforge.net/lists/listinfo/limesurvey-developers >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > limesurvey-developers mailing list > lim...@li... > https://lists.sourceforge.net/lists/listinfo/limesurvey-developers > |
From: Carsten S. <car...@go...> - 2008-04-08 13:00:36
|
Brian Staats schrieb: > Carsten, > > Just say no to ugly URLs. :) > > Seriously though... Is your stance on the (mod_rewrite == excluding % > of users) based on admin privileges needed to install mod_rewrite or > is it just more difficult to install mod_rewrite? (excuse my ignorance > of apache moding) > Hi Brian, it is indeed a sysadmin task. If mod_rewrite is not installed it means modding the apache configuration, sometime even recompiling the appropriate apache server module. A PHP installer cannot take care of that. > If it is the latter, then why can not the installer take care of > mod_rewrite? Is it that difficult to include mod_rewrite in the > installer? > > Yes. > If it is the former, what LS user base does not have the correct > privileges to install mod_rewrite (given the installer can do it for > them)? Can you give a specific example? > For example the webspace I am using does not have support for mod_rewrite - and there is no way I could switch it on myself. I will have to contact my provider and plead to make them activate it. And maybe (after a certain amount of time) they would do it. Until I get to this point I would have given up on installing the software if I was a LS user. PEAR packages are even worse since you need shell access to install it. Most providers here in Germany do not have shell access unless you have a root/virtual server. And even then the shell access is cryptic for most user people. > Thanks in advance for the response! > You are welcome! Best regards Carsten |
From: Brian S. <bs...@mi...> - 2008-04-08 13:37:23
|
Carsten, Ok, so if it is a permission issue. Have the installer do he following. 1. Check if mod_rewrite is installed. Yes? Cool, proceed. No? Go to step 2 2. Check if mod_rewrite _can_ be installed Yes? Cool, proceed. No? Go to step 3. 3. Install _without_ mod_rewrite and notify to the user so they can install mod_rewrite later if they can/want to. Help them by pointing to wiki instructions. CakePHP should be able to do the checking and setting of the mod_rewrite since they are only files on the file system and php can access the file system. If something happens where mod_rewrite fails, then the installer proceeds to step 3 (with a little info about the failure) and to the end user.. LS2 is now installed and ready to roll (albeit with a 1990's URL). :) On Apr 8, 2008, at 8:59 AM, Carsten Schmitz wrote: > Brian Staats schrieb: >> Carsten, >> >> Just say no to ugly URLs. :) >> >> Seriously though... Is your stance on the (mod_rewrite == >> excluding % >> of users) based on admin privileges needed to install mod_rewrite or >> is it just more difficult to install mod_rewrite? (excuse my >> ignorance >> of apache moding) >> > Hi Brian, > > it is indeed a sysadmin task. If mod_rewrite is not installed it means > modding the apache configuration, sometime even recompiling the > appropriate apache server module. > A PHP installer cannot take care of that. >> If it is the latter, then why can not the installer take care of >> mod_rewrite? Is it that difficult to include mod_rewrite in the >> installer? >> >> > Yes. >> If it is the former, what LS user base does not have the correct >> privileges to install mod_rewrite (given the installer can do it for >> them)? Can you give a specific example? >> > For example the webspace I am using does not have support for > mod_rewrite - and there is no way I could switch it on myself. I will > have to contact my provider and plead to make them activate it. > And maybe (after a certain amount of time) they would do it. Until I > get > to this point I would have given up on installing the software if I > was > a LS user. > PEAR packages are even worse since you need shell access to install > it. > Most providers here in Germany do not have shell access unless you > have > a root/virtual server. > And even then the shell access is cryptic for most user people. > >> Thanks in advance for the response! >> > You are welcome! > > Best regards > > Carsten > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > limesurvey-developers mailing list > lim...@li... > https://lists.sourceforge.net/lists/listinfo/limesurvey-developers |
From: Carsten S. <car...@go...> - 2008-04-08 13:49:03
|
Brian Staats schrieb: > Carsten, > > Ok, so if it is a permission issue. Have the installer do he following. > > 1. Check if mod_rewrite is installed. > Yes? Cool, proceed. > No? Go to step 2 > PHP itself does not know about mod_rewrite of the apache server. It is not elegant to find this out using PHP. Find instructions here: http://www.wallpaperama.com/forums/how-to-test-check-if-mod-rewrite-is-enabled-t40.html I am not sure if this is possible inside a CakePHP installer. It would require that CakePHPs mod_rewrite setting is set to off from the start to be able to start the install at all. Lets find out if this is possible. > 2. Check if mod_rewrite _can_ be installed > Yes? Cool, proceed. > No? Go to step 3. > Only the user can determine if he can install it. So the user will have to make that decision. > 3. Install _without_ mod_rewrite and notify to the user so they can > install mod_rewrite later if they can/want to. Help them by pointing > to wiki instructions. > > I am cool with that. > CakePHP should be able to do the checking and setting of the > mod_rewrite since they are only files on the file system and php can > access the file system. If something happens where mod_rewrite fails, > then the installer proceeds to step 3 (with a little info about the > failure) and to the end user.. LS2 is now installed and ready to roll > (albeit with a 1990's URL). :) > Should be no problem. This sounds good for me! Regards Carsten > On Apr 8, 2008, at 8:59 AM, Carsten Schmitz wrote: > > >> Brian Staats schrieb: >> >>> Carsten, >>> >>> Just say no to ugly URLs. :) >>> >>> Seriously though... Is your stance on the (mod_rewrite == >>> excluding % >>> of users) based on admin privileges needed to install mod_rewrite or >>> is it just more difficult to install mod_rewrite? (excuse my >>> ignorance >>> of apache moding) >>> >>> >> Hi Brian, >> >> it is indeed a sysadmin task. If mod_rewrite is not installed it means >> modding the apache configuration, sometime even recompiling the >> appropriate apache server module. >> A PHP installer cannot take care of that. >> >>> If it is the latter, then why can not the installer take care of >>> mod_rewrite? Is it that difficult to include mod_rewrite in the >>> installer? >>> >>> >>> >> Yes. >> >>> If it is the former, what LS user base does not have the correct >>> privileges to install mod_rewrite (given the installer can do it for >>> them)? Can you give a specific example? >>> >>> >> For example the webspace I am using does not have support for >> mod_rewrite - and there is no way I could switch it on myself. I will >> have to contact my provider and plead to make them activate it. >> And maybe (after a certain amount of time) they would do it. Until I >> get >> to this point I would have given up on installing the software if I >> was >> a LS user. >> PEAR packages are even worse since you need shell access to install >> it. >> Most providers here in Germany do not have shell access unless you >> have >> a root/virtual server. >> And even then the shell access is cryptic for most user people. >> >> >>> Thanks in advance for the response! >>> >>> >> You are welcome! >> >> Best regards >> >> Carsten >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Register now and save $200. Hurry, offer ends at 11:59 p.m., >> Monday, April 7! Use priority code J8TLD2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >> _______________________________________________ >> limesurvey-developers mailing list >> lim...@li... >> https://lists.sourceforge.net/lists/listinfo/limesurvey-developers >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > limesurvey-developers mailing list > lim...@li... > https://lists.sourceforge.net/lists/listinfo/limesurvey-developers > |
From: Carsten S. <car...@go...> - 2008-04-08 13:52:32
|
Hi! I just looked again and found this: http://de2.php.net/manual/en/function.apache-get-modules.php So i was wrong about being hard to find out if mod_rewrite is installed. So I am all with your solution. Would this be acceptable for everyone? regards Carsten Brian Staats schrieb: > Carsten, > > Ok, so if it is a permission issue. Have the installer do he following. > > 1. Check if mod_rewrite is installed. > Yes? Cool, proceed. > No? Go to step 2 > > 2. Check if mod_rewrite _can_ be installed > Yes? Cool, proceed. > No? Go to step 3. > > 3. Install _without_ mod_rewrite and notify to the user so they can > install mod_rewrite later if they can/want to. Help them by pointing > to wiki instructions. > > CakePHP should be able to do the checking and setting of the > mod_rewrite since they are only files on the file system and php can > access the file system. If something happens where mod_rewrite fails, > then the installer proceeds to step 3 (with a little info about the > failure) and to the end user.. LS2 is now installed and ready to roll > (albeit with a 1990's URL). :) > > > On Apr 8, 2008, at 8:59 AM, Carsten Schmitz wrote: > > >> Brian Staats schrieb: >> >>> Carsten, >>> >>> Just say no to ugly URLs. :) >>> >>> Seriously though... Is your stance on the (mod_rewrite == >>> excluding % >>> of users) based on admin privileges needed to install mod_rewrite or >>> is it just more difficult to install mod_rewrite? (excuse my >>> ignorance >>> of apache moding) >>> >>> >> Hi Brian, >> >> it is indeed a sysadmin task. If mod_rewrite is not installed it means >> modding the apache configuration, sometime even recompiling the >> appropriate apache server module. >> A PHP installer cannot take care of that. >> >>> If it is the latter, then why can not the installer take care of >>> mod_rewrite? Is it that difficult to include mod_rewrite in the >>> installer? >>> >>> >>> >> Yes. >> >>> If it is the former, what LS user base does not have the correct >>> privileges to install mod_rewrite (given the installer can do it for >>> them)? Can you give a specific example? >>> >>> >> For example the webspace I am using does not have support for >> mod_rewrite - and there is no way I could switch it on myself. I will >> have to contact my provider and plead to make them activate it. >> And maybe (after a certain amount of time) they would do it. Until I >> get >> to this point I would have given up on installing the software if I >> was >> a LS user. >> PEAR packages are even worse since you need shell access to install >> it. >> Most providers here in Germany do not have shell access unless you >> have >> a root/virtual server. >> And even then the shell access is cryptic for most user people. >> >> >>> Thanks in advance for the response! >>> >>> >> You are welcome! >> >> Best regards >> >> Carsten >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Register now and save $200. Hurry, offer ends at 11:59 p.m., >> Monday, April 7! Use priority code J8TLD2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >> _______________________________________________ >> limesurvey-developers mailing list >> lim...@li... >> https://lists.sourceforge.net/lists/listinfo/limesurvey-developers >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > limesurvey-developers mailing list > lim...@li... > https://lists.sourceforge.net/lists/listinfo/limesurvey-developers > |
From: Thibault Le M. <Thi...@su...> - 2008-04-08 14:53:57
|
Carsten Schmitz a écrit : > Hi! > > I just looked again and found this: > > http://de2.php.net/manual/en/function.apache-get-modules.php > > So i was wrong about being hard to find out if mod_rewrite is installed. > So I am all with your solution. Would this be acceptable for everyone? > Perfect for me. Thibault |
From: Juhan S. <juhan@MIT.EDU> - 2008-04-08 11:30:28
|
> > > http://limesurvey2/index.php/surveys (oinly the index.php is > inserted) > > To get the prettier URLs you have to have mod_rewrite installed on the > server. And what worth is the prettier URL if 30% of the users (and > hereby I am thinking of the private users) is not able to install the > software from the start. (since mod_rewrite is needed for that). On > the > other hand it is no problem for a sysadmin (=experienced person) to > activate the mod_rewrite settings after installation manually if the > server is configured correctly. I did not say the prettier URL (using > mod_rewrite) should not be possible. I am just saying that these > things > should not be activated by default and that the application has to be > working under both conditions (with and without mod_rewrite). > What you use in development as a default on your local machine is your > own decision - but subversion version should default to non- > mod_rewrite > URLs. > > Best regards > > Carsten > We're all on the same page in terms of the install: brain-dead for everyday people. The 1-click and go. Love it x10. However, it's not just about pretty. It's about human usable. Injecting noise hurts regardless of whether it's a URL (even just / index.php/), code, a TV show, or your favorite itunes collection. If we need to do a bit more code wrangling, so be it. Also, I hope we're aiming for limesurvey/ and not limesurvey2/. The "2" is also noise. ? -Juhan |
From: Carsten S. <car...@go...> - 2008-04-08 12:52:22
|
Juhan Sonin schrieb: >> http://limesurvey2/index.php/surveys (oinly the index.php is >> inserted) >> >> To get the prettier URLs you have to have mod_rewrite installed on the >> server. And what worth is the prettier URL if 30% of the users (and >> hereby I am thinking of the private users) is not able to install the >> software from the start. (since mod_rewrite is needed for that). On >> the >> other hand it is no problem for a sysadmin (=experienced person) to >> activate the mod_rewrite settings after installation manually if the >> server is configured correctly. I did not say the prettier URL (using >> mod_rewrite) should not be possible. I am just saying that these >> things >> should not be activated by default and that the application has to be >> working under both conditions (with and without mod_rewrite). >> What you use in development as a default on your local machine is your >> own decision - but subversion version should default to non- >> mod_rewrite >> URLs. >> > We're all on the same page in terms of the install: brain-dead for > everyday people. The 1-click and go. Love it x10. > > However, it's not just about pretty. It's about human usable. > Injecting noise hurts regardless of whether it's a URL (even just / > index.php/), code, a TV show, or your favorite itunes collection. If > we need to do a bit more code wrangling, so be it. > > Also, I hope we're aiming for limesurvey/ and not limesurvey2/. The > "2" is also noise. > As I said.. it won't be a problem for the experienced sysadmin to activate it and have your prettier URLs - but this is a sysadmin task - it means messing with the apache configuration and activating .hatccess files - no PHP installation program can take care of that. Thats why it should default to OFF and not be a requirement for installation.. Regards Carsten |