On 2010.06.16 07:12, Shlomi Fish wrote: > On Wednesday 16 Jun 2010 01:58:19 Herb wrote:
>> My goal is to create a form that has multiple pages with a few >> questions per page so that visitors aren’t dropped into a large single >> page form that they feel is too daunting and therefore don’t fill it >> out. I would like the form to write to a mysql database and I’ve read >> that gathering the information via multiple pages would be done with >> ‘hidden fields’. >> >> Is it best to create multiple HTML pages containing hidden fields with >> the last pages’ action submitting to the cgi script, or is it fine to >> create one cgi script for the entire process? > > I've always done it with hidden fields, which allows the final form > submission > to be done atomically. It is possible that web-development frameworks such as > Catalyst (see: > http://www.catalystframework.org/ ) provide elegant abstractions above it, > but I never investigated. I always used to use one CGI script that also contained the HTML code. I'd have a 'do' param that would essentially guide the script into the next subroutine. For MySQL, I'd use DBI. Things have changed a bit. Now I use CGI::Application along with DBIx::Class. A current project I'm working on uses this setup. The CGI portion of the application is simply a GUI front-end 'plugin' for an otherwise CLI-oriented system. The primary cgi script simply bootstraps itself, does the session work, then passes off all responsibility to the backend modules. The gui module itself contains some 50+ subs and 2700 lines of code. All of the HTML is handled by HTML::Template, so the code is absolutely 100% separate from the HTML (Literally... there is not a single HTML element or text anywhere in the code). CGI::Application has numerous handy plugins which further ease coding. DBIx::Class is a tremendously handy piece of software for db interaction, and I'll likely never use anything else again for the task. All three combined allow code to be written in a straight-forward and easy-to-understand reusable-type fashion. The template system allows you to throw simple scalars, up to complex Perl data structures at it (aref of hrefs that contain arefs of hrefs) directly for looping, instead of declaring each and every form variable individually. The learning curve is higher than just writing CGI-type code, but I assure you that it is well, well worth doing it in a scalable manner like this from the beginning. In my current case, the cgi/gui portion is simply a front-end that takes input, and displays output of a much larger system that contains numerous other modules that actually do the work. With that said, I can see how using a setup like this even for a small project would be well worth the time that is needed to invest into learning more. Automation becomes a piece of cake. The following modules contain exceptionally good documentation, specifically introductory tutorials...particularly DBIx::Class. All have active mail lists, and strong communities of people who are always willing to help. http://cgi-app.org/ http://search.cpan.org/~samtregar/HTML-Template-2.6/Template.pm http://search.cpan.org/dist/DBIx-Class/ I'll provide examples (or all my code itself) if you're interested. Cheers, Steve ps. I've read up a bit on Catalyst, but by that time I was already too heavily using CGI::App to even consider changing. I do have another project on the go that will require a lighter-weight gui front-end, so I'm considering trying it out for that. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
