From: Matthew G. <gr...@mu...> - 2002-03-22 16:38:30
|
Hi folks, Man our timeing stinks... MUSC.edu has decided to use phpESP as our main survey tool. We had just begun a couple of modifications, "section text" and LDAP auth., being the first two. So as I was about to post the "section text" patch, Kon jumps in and beats me to it :-) Thats awesome! I would like to throw out a possible change to Kon's patch. Instead of having the "section text" indented, have it flush with the question numbering. For example: Put the "section text" in the left column and do a colspan="2". Thoughts? |
From: James E. F. <jf...@ac...> - 2002-03-22 17:17:13
|
On Fri, 22 Mar 2002, Matthew Gregg wrote: > I would like to throw out a possible change to Kon's patch. Instead of > having the "section text" indented, have it flush with the question > numbering. > > For example: > Put the "section text" in the left column and do a colspan="2". > > Thoughts? +1 : sounds good to me. -James [ For those not familiar, it's common to just say "+1" or "-1" for agree or disagree to a suggestion. That makes it easy to quickly see general opinion. (or we could use phpesp to acutally "vote". :-p ] |
From: Christopher Z. <zo...@mu...> - 2002-03-22 17:21:30
|
+1 for me. :) On Fri, Mar 22, 2002 at 12:17:08PM -0500, James E. Flemer wrote: > On Fri, 22 Mar 2002, Matthew Gregg wrote: > > I would like to throw out a possible change to Kon's patch. Instead of > > having the "section text" indented, have it flush with the question > > numbering. > > > > For example: > > Put the "section text" in the left column and do a colspan="2". > > > > Thoughts? > > +1 : sounds good to me. > > -James > > [ For those not familiar, it's common to just say "+1" or > "-1" for agree or disagree to a suggestion. That makes it > easy to quickly see general opinion. (or we could use > phpesp to acutally "vote". :-p ] > > > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > |
From: James E. F. <jf...@ac...> - 2002-03-22 18:40:18
|
Done. Check out CVS now. I also added a patch to survey_results, to include the "section text" in the results (it was in the merge, but not standard results). -James On Fri, 22 Mar 2002, James E. Flemer wrote: > On Fri, 22 Mar 2002, Matthew Gregg wrote: > > I would like to throw out a possible change to Kon's patch. Instead of > > having the "section text" indented, have it flush with the question > > numbering. > > > > For example: > > Put the "section text" in the left column and do a colspan="2". > > > > Thoughts? > > +1 : sounds good to me. > > -James > > [ For those not familiar, it's common to just say "+1" or > "-1" for agree or disagree to a suggestion. That makes it > easy to quickly see general opinion. (or we could use > phpesp to acutally "vote". :-p ] > > > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > |
From: Matthew G. <gr...@mu...> - 2002-03-22 19:52:17
|
Cool. Since that was done so fast. I can move on to the next change. Unless someone objects or has already started it, I would like to add "download" to the export function. --On Friday, March 22, 2002 01:40:10 PM -0500 "James E. Flemer" <jf...@ac...> wrote: > Done. Check out CVS now. I also added a patch to > survey_results, to include the "section text" in the > results (it was in the merge, but not standard results). > > -James > > On Fri, 22 Mar 2002, James E. Flemer wrote: > >> On Fri, 22 Mar 2002, Matthew Gregg wrote: >> > I would like to throw out a possible change to Kon's patch. Instead of >> > having the "section text" indented, have it flush with the question >> > numbering. >> > >> > For example: >> > Put the "section text" in the left column and do a colspan="2". >> > >> > Thoughts? >> >> +1 : sounds good to me. >> >> -James >> >> [ For those not familiar, it's common to just say "+1" or >> "-1" for agree or disagree to a suggestion. That makes it >> easy to quickly see general opinion. (or we could use >> phpesp to acutally "vote". :-p ] >> >> >> _______________________________________________ >> phpESP-devel mailing list >> php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpesp-devel >> > > > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > |
From: James E. F. <jf...@ac...> - 2002-03-22 20:00:11
|
Please do! How do you plan to do this? I was thinking that there would have to be some script outside the admin/include framework to do this (since by then there are already headers/data sent). This script outside should use a content-type of "application/x-csv"(?) and return the actual csv data. I would suggest splitting the exising survey_export_cvs() into: survey_generate_cvs() -- creates a string/array of data survey_export_cvs() -- calls generate, and writes to file Then your download script could call generate, and just print the appropriate headers then the data directly. -James On Fri, 22 Mar 2002, Matthew Gregg wrote: > Cool. Since that was done so fast. I can move on to the next change. > Unless someone objects or has already started it, I would like to add > "download" to the export function. |
From: Roman J. <cit...@ma...> - 2002-03-22 20:22:04
|
I was thinking about a pop-up window (aka Save File). In any case, I think this is a very good feature that people would use, especially those not UNIX savvy (assuming the ESP is running on a *nix). -Roman |
From: James E. F. <jf...@ac...> - 2002-03-22 20:32:47
|
I think that most browsers will give a "Save as..." box if they receive a content-type of "application/x-csv". But I could be wrong since I just use nutscrape (netscape). It should certainly be tested before release tho. -James On Fri, 22 Mar 2002, Roman Jasins wrote: > I was thinking about a pop-up window (aka Save File). > In any case, I think this is a very good feature that > people would use, especially those not UNIX savvy > (assuming the ESP is running on a *nix). > > -Roman |
From: Roman J. <cit...@ma...> - 2002-03-22 20:41:10
|
From: Roman Jasins <cit...@ma...> Date: Fri Mar 22, 2002 10:40:05 PM Europe/Helsinki To: "James E. Flemer" <jf...@ac...> Subject: Re: [phpesp-dev] Export Download alright, just another idea (maybe not so bright, but anyway). what if just display the csv file in a browser (even nutscrape should handle that w/o extra effort from a developer), so users just save it from there. might be simplistic, but looks like a step up from /tmp/ (i'm not trying to offend anybody here ;-) -Roman On Friday, March 22, 2002, at 10:32 PM, James E. Flemer wrote: I think that most browsers will give a "Save as..." box if they receive a content-type of "application/x-csv". But I could be wrong since I just use nutscrape (netscape). It should certainly be tested before release tho. -James On Fri, 22 Mar 2002, Roman Jasins wrote: I was thinking about a pop-up window (aka Save File). In any case, I think this is a very good feature that people would use, especially those not UNIX savvy (assuming the ESP is running on a *nix). -Roman |
From: Matthew G. <gr...@mu...> - 2002-03-23 15:09:40
|
I've got this roughed in and working. I'm getting around headers/data being sent as follows: In export.inc on the CSV download url, I'm adding another parameter that is used in manage.php and when export.inc is called later to bypass any headers or data being sent. At your suggestion I split survey_export_cvs() into survey_export_cvs() and survey_generate_cvs() As for as mime types: I'm considering "application/x-msexcel" or "text/plain-text". We've used x-msexcel before to "trick" excel into opening tab delimited text files. Not sure how it will work for csv. How's this sound? --On Friday, March 22, 2002 03:00:06 PM -0500 "James E. Flemer" <jf...@ac...> wrote: > Please do! How do you plan to do this? I was thinking that > there would have to be some script outside the > admin/include framework to do this (since by then there are > already headers/data sent). This script outside should use > a content-type of "application/x-csv"(?) and return the > actual csv data. I would suggest splitting the exising > survey_export_cvs() into: > survey_generate_cvs() -- creates a string/array of data > survey_export_cvs() -- calls generate, and writes to file > Then your download script could call generate, and just > print the appropriate headers then the data directly. > > -James > > On Fri, 22 Mar 2002, Matthew Gregg wrote: > >> Cool. Since that was done so fast. I can move on to the next change. >> Unless someone objects or has already started it, I would like to add >> "download" to the export function. > |
From: Matthew G. <gr...@mu...> - 2002-03-25 20:33:07
Attachments:
export.diff
|
Since I didn't get any feedback on this idea, I went ahead an created the attached patch against current CVS. I'm sure it's lacking somewhere so...comments? --On Saturday, March 23, 2002 10:09:27 AM -0500 Matthew Gregg <gr...@mu...> wrote: > I've got this roughed in and working. > I'm getting around headers/data being sent as follows: > In export.inc on the CSV download url, I'm adding another parameter that > is used in manage.php and when export.inc is called later to bypass any > headers or data being sent. > > At your suggestion I split survey_export_cvs() into survey_export_cvs() > and survey_generate_cvs() > > As for as mime types: > I'm considering "application/x-msexcel" or "text/plain-text". We've used > x-msexcel before to "trick" excel into opening tab delimited text files. > Not sure how it will work for csv. > > How's this sound? > > > --On Friday, March 22, 2002 03:00:06 PM -0500 "James E. Flemer" > <jf...@ac...> wrote: > >> Please do! How do you plan to do this? I was thinking that >> there would have to be some script outside the >> admin/include framework to do this (since by then there are >> already headers/data sent). This script outside should use >> a content-type of "application/x-csv"(?) and return the >> actual csv data. I would suggest splitting the exising >> survey_export_cvs() into: >> survey_generate_cvs() -- creates a string/array of data >> survey_export_cvs() -- calls generate, and writes to file >> Then your download script could call generate, and just >> print the appropriate headers then the data directly. >> >> -James >> >> On Fri, 22 Mar 2002, Matthew Gregg wrote: >> >>> Cool. Since that was done so fast. I can move on to the next change. >>> Unless someone objects or has already started it, I would like to add >>> "download" to the export function. >> > > > > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > one of the friendly folks in the IT Lab. --------------------------------------\ The IT Lab (http://www.itlab.musc.edu) \____________________ Probably the world's premier software development center. Serving: Programming, Tools, Ice Cream, Seminars |
From: James E. F. <jf...@ac...> - 2002-03-26 16:55:50
Attachments:
export.diff
|
I've modified your patch a little bit. Take a look and see what you all think. It allows people to still export data to a file, and also download it. I also changed the content type to "application/x-csv" since "text/plain-text" is not a real content type (and when it is "text/plain" it shows inline, not a save as box). We could also try "application/x-msexcel", tho I believe there is another preferred type for Excel. -James On Mon, 25 Mar 2002, Matthew Gregg wrote: > Since I didn't get any feedback on this idea, I went ahead an created the > attached patch against current CVS. > > I'm sure it's lacking somewhere so...comments? > > --On Saturday, March 23, 2002 10:09:27 AM -0500 Matthew Gregg > <gr...@mu...> wrote: > > > I've got this roughed in and working. > > I'm getting around headers/data being sent as follows: > > In export.inc on the CSV download url, I'm adding another parameter that > > is used in manage.php and when export.inc is called later to bypass any > > headers or data being sent. > > > > At your suggestion I split survey_export_cvs() into survey_export_cvs() > > and survey_generate_cvs() > > > > As for as mime types: > > I'm considering "application/x-msexcel" or "text/plain-text". We've used > > x-msexcel before to "trick" excel into opening tab delimited text files. > > Not sure how it will work for csv. > > > > How's this sound? |
From: Matthew G. <gr...@mu...> - 2002-03-26 18:29:48
|
Yeah. Moving the logic into download.inc is much better. I was hesitant to go that route. One slight change to download.inc. - header("Content-Disposition: attachment; filename=$\"name.csv\""); + header("Content-Disposition: attachment; filename=$name.csv"); That fixes the extra "'s that show up in Konq. and Windows IE. application/x-csv looks like the way to go. What do you think of appending date/time to the exported filename and maybe a check for empty results before download/export? --On Tuesday, March 26, 2002 11:55:44 AM -0500 "James E. Flemer" <jf...@ac...> wrote: > I've modified your patch a little bit. Take a look and see > what you all think. It allows people to still export data > to a file, and also download it. I also changed the content > type to "application/x-csv" since "text/plain-text" is not > a real content type (and when it is "text/plain" it shows > inline, not a save as box). We could also try > "application/x-msexcel", tho I believe there is another > preferred type for Excel. > > -James > > On Mon, 25 Mar 2002, Matthew Gregg wrote: > >> Since I didn't get any feedback on this idea, I went ahead an created the >> attached patch against current CVS. >> >> I'm sure it's lacking somewhere so...comments? >> >> --On Saturday, March 23, 2002 10:09:27 AM -0500 Matthew Gregg >> <gr...@mu...> wrote: >> >> > I've got this roughed in and working. >> > I'm getting around headers/data being sent as follows: >> > In export.inc on the CSV download url, I'm adding another parameter >> > that is used in manage.php and when export.inc is called later to >> > bypass any headers or data being sent. >> > >> > At your suggestion I split survey_export_cvs() into survey_export_cvs() >> > and survey_generate_cvs() >> > >> > As for as mime types: >> > I'm considering "application/x-msexcel" or "text/plain-text". We've >> > used x-msexcel before to "trick" excel into opening tab delimited text >> > files. Not sure how it will work for csv. >> > >> > How's this sound? one of the friendly folks in the IT Lab. --------------------------------------\ The IT Lab (http://www.itlab.musc.edu) \____________________ Probably the world's premier software development center. Serving: Programming, Tools, Ice Cream, Seminars |
From: James E. F. <jf...@ac...> - 2002-03-26 18:59:02
|
On Tue, 26 Mar 2002, Matthew Gregg wrote: > One slight change to download.inc. > - header("Content-Disposition: attachment; filename=$\"name.csv\""); > + header("Content-Disposition: attachment; filename=$name.csv"); > That fixes the extra "'s that show up in Konq. and Windows IE. Done. I am committing this part to CVS now. > What do you think of appending date/time to the > exported filename and maybe a check for empty results > before download/export? I don't know about appending the date ... you saw my comment about the "quarterly" example? How about instead of checking for empty results ... perhaps just list the number of results per survey on the export page? Checking for # on export is harder, especially in the case of downloading because by that point we have already bypassed the standard HTML headers and such. -James |
From: angek p. <ang...@ip...> - 2002-03-23 00:38:01
|
Thanks James Kon -----Original Message----- From: php...@li... [mailto:php...@li...] On Behalf Of James E. Flemer Sent: Saturday, 23 March 2002 5:40 AM To: php...@li... Subject: Re: [phpesp-dev] "section text, etc.. Done. Check out CVS now. I also added a patch to survey_results, to include the "section text" in the results (it was in the merge, but not standard results). -James On Fri, 22 Mar 2002, James E. Flemer wrote: > On Fri, 22 Mar 2002, Matthew Gregg wrote: > > I would like to throw out a possible change to Kon's patch. Instead > > of having the "section text" indented, have it flush with the > > question numbering. > > > > For example: > > Put the "section text" in the left column and do a colspan="2". > > > > Thoughts? > > +1 : sounds good to me. > > -James > > [ For those not familiar, it's common to just say "+1" or > "-1" for agree or disagree to a suggestion. That makes it > easy to quickly see general opinion. (or we could use > phpesp to acutally "vote". :-p ] > > > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > _______________________________________________ phpESP-devel mailing list php...@li... https://lists.sourceforge.net/lists/listinfo/phpesp-devel |
From: angek p. <ang...@ip...> - 2002-03-23 00:36:19
|
Guys, That' s certainly one way to fire me up........ Challenge ACCEPTED.... But I have promised my wife that I'll spend most of the weekend with her and not with my computer so I should have it done for Monday. Kon -----Original Message----- From: php...@li... [mailto:php...@li...] On Behalf Of James E. Flemer Sent: Saturday, 23 March 2002 4:17 AM To: Matthew Gregg Cc: php...@li... Subject: Re: [phpesp-dev] "section text, etc.. On Fri, 22 Mar 2002, Matthew Gregg wrote: > I would like to throw out a possible change to Kon's patch. Instead > of having the "section text" indented, have it flush with the question > numbering. > > For example: > Put the "section text" in the left column and do a colspan="2". > > Thoughts? +1 : sounds good to me. -James [ For those not familiar, it's common to just say "+1" or "-1" for agree or disagree to a suggestion. That makes it easy to quickly see general opinion. (or we could use phpesp to acutally "vote". :-p ] _______________________________________________ phpESP-devel mailing list php...@li... https://lists.sourceforge.net/lists/listinfo/phpesp-devel |
From: Christopher Z. <zo...@mu...> - 2002-03-22 20:37:53
Attachments:
phpESP-ldap-03222002.diff
|
Ok. Here is my patch. It is a quick hack so I may be over looking some things. Please point out anything that you see wrong with it. All I am using ldap for is authentication for now. When someone trys to log into phpESP/admin it will check the database ( this is so we can still have a root user ) if that fails it authenticates against the ldap server and if successfull it will either insert user information into the database and create a seperate group for the user or update the user password to match the one for ldap. What do you guys think? |
From: James E. F. <jf...@ac...> - 2002-03-26 19:52:10
|
Well I don't use LDAP, and haven't for the past 3-4 years... So I made a few cosmetic changes and commited your patch. Could you check out the latest CVS version and try it out. Hopefully I didn't break anything. Also it would be nice if you could write a small README.LDAP or something giving some pointers on what to set each of the new phpESP.ini variables to when using LDAP (and any other pointers you think appropriate). I haven't really looked too closely at your patch, but let me say this in case it applies. There is a field called 'auth' in both the respondent table, and the designer table. The default value is BASIC. That field is currently not used at all. I put it in there for the possiblity of future auth-types to set it if they need to. Perhaps the LDAP auth would want to use that field. Anyway ... it's there for your use. -James On Fri, 22 Mar 2002, Christopher Zorn wrote: > Ok. Here is my patch. It is a quick hack so I may be > over looking some things. Please point out anything > that you see wrong with it. All I am using ldap for is > authentication for now. When someone trys to log into > phpESP/admin it will check the database ( this is so we > can still have a root user ) if that fails it > authenticates against the ldap server and if > successfull it will either insert user information into > the database and create a seperate group for the user > or update the user password to match the one for ldap. > What do you guys think? |
From: Christopher Z. <zo...@mu...> - 2002-03-27 20:25:34
|
On Tue, Mar 26, 2002 at 02:52:04PM -0500, James E. Flemer wrote: > Well I don't use LDAP, and haven't for the past 3-4 > years... So I made a few cosmetic changes and commited your > patch. Could you check out the latest CVS version and try > it out. Hopefully I didn't break anything. Also it would be > nice if you could write a small README.LDAP or something > giving some pointers on what to set each of the new > phpESP.ini variables to when using LDAP (and any other > pointers you think appropriate). Cool. I have looked at it and it looks great. There is one problem though. If the ldap server allows anonymous binding then a blank dn will return a success. We just have to make sure the search results returns the right count. So on line 145 of espauth-ldap.inc just change if ($search_result) { to if (ldap_count_entries($ds,$search_result)==1) { that should fix it. I should have a quick README.ldap coming soon. > > I haven't really looked too closely at your patch, but let > me say this in case it applies. There is a field called > 'auth' in both the respondent table, and the designer > table. The default value is BASIC. That field is currently > not used at all. I put it in there for the possiblity of > future auth-types to set it if they need to. Perhaps the > LDAP auth would want to use that field. Anyway ... it's > there for your use. > Ok. > -James > > On Fri, 22 Mar 2002, Christopher Zorn wrote: > > > Ok. Here is my patch. It is a quick hack so I may be > > over looking some things. Please point out anything > > that you see wrong with it. All I am using ldap for is > > authentication for now. When someone trys to log into > > phpESP/admin it will check the database ( this is so we > > can still have a root user ) if that fails it > > authenticates against the ldap server and if > > successfull it will either insert user information into > > the database and create a seperate group for the user > > or update the user password to match the one for ldap. > > What do you guys think? > |
From: Lou S. <lr...@at...> - 2002-03-24 15:33:42
|
I'm please you started this development list. I've been using phpESP for a while and like it. I would like to contribute my time to some development things. I'm wondering if anyone is working on an install script for phpESP and if not I would be willing to work on one. Just a few ideas: install script for phpESP RPMs, SRPMS, deb, zip, formats for phpESP standardize the config directory so users won't have to modify the source files (i.e. references to the include files) add a stock set of surveys and questionnaires import/export feature which handles XML and other formats use XML and XSLT to generate the HTML pages for reports etc. ability to copy portions of surveys from other surveys change the main maintenance menu to functional areas Survey construction add, edit. delete, copy Survey administration test, activate, close Survey reports view, print, etc Survey authentication user creation, editing, deletion, copying (i.e. duplicate user privileges) Survey utilities export (mySQL, XML, CSV, etc), import(mySQL, XML, CSV, etc) interfaces to other content management systems phpNuke, PostNuke, phpgroupware, ezPublish, etc. Ability to specify a page to include the generated PHP code (i.e. maybe include comment in the HTML/PHP page with a begin/end comment such that phpESP could auto insert the php code directly into the HTML/PHP page e.g. HTML/PHP file. <!-- phpESP v1.4 Survey Start --> Section to include the generated PHP code <!-- phpESP v1.4 Survey End --> Possibility to manage "pages with the php generated survey code" Display phpESP version on Maintenance Page Thank you. Lou. |
From: James E. F. <jf...@ac...> - 2002-03-24 19:29:02
|
Anyone who is seriously interested in contributing should get themselves a sourceforge account, and letting me know their user name. Probably the best way to handle task assignment and such is through the "Feature Request" part of SourceForge, that way hopefully people will not duplicate the efforts of others. I have commented (below) on a few of the items you brought up. I'd like to see other users opinions on them as well. Then perhaps we can try to assign some of them among those willing to contribute. -James On Sun, 24 Mar 2002, Lou Spironello wrote: > I'm please you started this development list. > I've been using phpESP for a while and like it. > > I would like to contribute my time to some development things. > > I'm wondering if anyone is working on an install script for phpESP > and if not I would be willing to work on one. > > Just a few ideas: > install script for phpESP > RPMs, SRPMS, deb, zip, formats for phpESP > standardize the config directory so users won't have to > modify the source files (i.e. references to the include files) This is a good idea, but isn't possible. The location of the files must not be pre-determined. Many people use hosting companies, and have very little control over the actual web server they are running phpESP on. As of version 1.3 (or maybe earlier) I have suggested that the package get installed in /usr/local/lib/php/contrib, since /usr/local/lib/php is typically where PEAR and such gets installed. Installing in lib requires root access to the webserver, however. So the option must exist to install in a user directory. Unfortunately, many people install the *whole* package in their "public_html" directory -- this leads to problems because then the config file (phpESP.ini) is accessible to the world via the web server, hence the database passwords are also available. The best solution to this is something you have already suggested -- an install script. The install script, if written, must check to make sure the user will not install the phpESP.ini in a publicly accessible directory, and must modify all necessary paths depending on the install location. This should be a fairly trivial operation. In addition, I would like (tho not necessary) for the install script to handle the database creation and initialization, and on checking the user permissions (mysql user). > add a stock set of surveys and questionnaires > import/export feature which handles XML and other formats > use XML and XSLT to generate the HTML pages for reports etc. I am very glad you mentioned XML. I would actually like to move a large portion of data out of mysql and into XML. I would like the backend format for the surveys to be XML. With a well written DTD (or schema), the XML based survey format would be much more flexible. It would still be simple enough to allow a similar web interface to design basic surveys, but would also allow advanced users to work directly with the XML to create a more customized layout. Also, by using XSLT, we add the possibility of themes and even more flexibility. > ability to copy portions of surveys from other surveys > change the main maintenance menu to functional areas > Survey construction > add, edit. delete, copy > Survey administration > test, activate, close > Survey reports > view, print, etc > Survey authentication > user creation, editing, deletion, copying (i.e. > duplicate user > privileges) > Survey utilities > export (mySQL, XML, CSV, etc), import(mySQL, XML, CSV, > etc) The whole interface needs to be redone. I am not a designer, and clearly the GUI I designed sucks. Hopefully there is someone who will have the time to rework the interface. > interfaces to other content management systems > phpNuke, PostNuke, phpgroupware, ezPublish, etc. I would like to see an interface to PostNuke first. Note that there are license differences between most of those CMS and phpESP, so phpESP cannot be distributed with them, but I can certainly work with them. > Ability to specify a page to include the generated PHP code > (i.e. maybe include comment in the HTML/PHP page with a > begin/end > comment such that phpESP could auto insert the php code > directly > into the HTML/PHP page > e.g. > HTML/PHP file. > > <!-- phpESP v1.4 Survey Start --> > Section to include the generated PHP code > <!-- phpESP v1.4 Survey End --> > > Possibility to manage "pages with the php generated survey code" I don't quite follow this. I am assuming you mean removing the step where the user inserts the PHP code into their HTML template file. Naturally that would be ideal, but probably not possible security wise (since the web server executes without user privileges). > Display phpESP version on Maintenance Page It is in the "title" tag of the page. :-) |
From: James E. F. <jf...@ac...> - 2002-03-24 19:56:18
|
As far as XML/XSLT is concerned anyone interested should take a look at some stuff I did (a long time ago) with XML for phpESP. http://phpesp.sf.net/xml.tar.gz -James |
From: Matthew G. <gr...@mu...> - 2002-03-24 21:27:11
|
A few comments below... --On Sunday, March 24, 2002 02:28:57 PM -0500 "James E. Flemer" <jf...@ac...> wrote: > Anyone who is seriously interested in contributing should > get themselves a sourceforge account, and letting me know > their user name. My SF username is greggmc. ...snip... > > The best solution to this is something you have already > suggested -- an install script. The install script, if > written, must check to make sure the user will not install > the phpESP.ini in a publicly accessible directory, An install script is surely the way to go. However I'm not sure it's possible for an install script to know what is and what isn't a web accessible directory. We are gonna have to trust the user somewhat. > and must > modify all necessary paths depending on the install > location. This should be a fairly trivial operation. In > addition, I would like (tho not necessary) for the install > script to handle the database creation and initialization, > and on checking the user permissions (mysql user). > >> add a stock set of surveys and questionnaires >> import/export feature which handles XML and other formats >> use XML and XSLT to generate the HTML pages for reports etc. > > I am very glad you mentioned XML. I would actually like to > move a large portion of data out of mysql and into XML. I Are you sure you want to do this? XML is a great data "interchange" mark-up, but generally functions poorly as a data repository, unless you have a specialized XMLDB. I would put my vote in favor of keeping a SQL based back-end and use XML/XLT as presentation/data exchange layer. > would like the back-end format for the surveys to be XML. > With a well written DTD (or schema), the XML based survey > format would be much more flexible. It would still be > simple enough to allow a similar web interface to design ...snip... > >> interfaces to other content management systems >> phpNuke, PostNuke, phpgroupware, ezPublish, etc. > > I would like to see an interface to PostNuke first. Note > that there are license differences between most of those > CMS and phpESP, so phpESP cannot be distributed with them, > but I can certainly work with them. Not that I would distribute ESP with any of the above CMS's, but can you explain why ESP can't be? They are all GPL'd. > >> Ability to specify a page to include the generated PHP code >> (i.e. maybe include comment in the HTML/PHP page with a >> begin/end >> comment such that phpESP could auto insert the php code >> directly >> into the HTML/PHP page >> e.g. >> HTML/PHP file. >> >> <!-- phpESP v1.4 Survey Start --> >> Section to include the generated PHP code >> <!-- phpESP v1.4 Survey End --> >> >> Possibility to manage "pages with the php generated survey code" > > I don't quite follow this. I am assuming you mean removing > the step where the user inserts the PHP code into their > HTML template file. Naturally that would be ideal, but > probably not possible security wise (since the web server > executes without user privileges). This is just off the top of my head, but what's wrong with something like this: <html> <body bgcolor="#ffffff"> <?php $sid=$id; include("/var/www/esp/public/handler.php");?> </body> </html> Then called as survey.php?id=3 would show survey with ID 3. ...snip... |
From: James E. F. <jf...@ac...> - 2002-03-25 04:52:35
|
On Sun, 24 Mar 2002, Matthew Gregg wrote: > On Sunday, March 24, 2002 James E. Flemer wrote: > > > The best solution to this is something you have already > > suggested -- an install script. The install script, if > > written, must check to make sure the user will not install > > the phpESP.ini in a publicly accessible directory, > > An install script is surely the way to go. However I'm not sure it's > possible for an install script to know what is and what isn't a web > accessible directory. We are gonna have to trust the user somewhat. True, but you can do some pretty good guessing, and if it looks like a public directory, give a second confirmation and big warning message. --snip-- > > I am very glad you mentioned XML. I would actually like to > > move a large portion of data out of mysql and into XML. I > > Are you sure you want to do this? XML is a great data "interchange" > mark-up, but generally functions poorly as a data repository, unless you > have a specialized XMLDB. > I would put my vote in favor of keeping a SQL based back-end and use > XML/XLT as presentation/data exchange layer. Well yes and no. My idea is to use XML internally (in PHP) and to store the XML in the database. But when a survey was activated, we would use XSLT to make a (X)HTML rendering of the survey. This would allow very fast serving of the survey, since we would eliminate a lot of SQL/DB overhead. Plus, it is much harder to create a database schema that will allow for the flexibility of survey design I want (and that XML allows) ... --snip-- > > I would like to see an interface to PostNuke first. Note > > that there are license differences between most of those > > CMS and phpESP, so phpESP cannot be distributed with them, > > but I can certainly work with them. > > Not that I would distribute ESP with any of the above CMS's, but can you > explain why ESP can't be? They are all GPL'd. phpESP is not GPL, it has a BSD-style license. GPL is a nasty license, and will not allow you to distribute non-GPL software with it. The phpESP license allows distributing one of the above with it, but not vice versa. --snip-- > > I don't quite follow this. I am assuming you mean removing > > the step where the user inserts the PHP code into their > > HTML template file. Naturally that would be ideal, but > > probably not possible security wise (since the web server > > executes without user privileges). > > This is just off the top of my head, but what's wrong with something like > this: > > <html> > <body bgcolor="#ffffff"> > <?php $sid=$id; include("/var/www/esp/public/handler.php");?> > </body> > </html> > > Then called as survey.php?id=3 would show survey with ID 3. Bad security, the SID should not be seen by the end user, nor specifiable. Also if one was to use the above code, it should really read: <?php $sid=intval($id); ... ?> However, there is certainly nothing stopping any end user from using a script like that. It won't ever be encouraged by me nor be part of the standard distribution. -James |