FormBuilder - Perl CGI Form Builder CPAN module

::Features ::Download ::Tutorial ::Examples
::Documentation ::FormBuilder Google Group ::Old List Archives ::Contribute

Note: The mailing list is has been replaced by the Google FormBuilder Group

Basic

1. Intro to FormBuilder
2. A Simple Form
3. Form Method
4. Input Validation
5. Field Options
6. Multi-Select Lists
7. Field Data
8. Field Attributes
9. HTML Formatting
10. Custom Headers
S. Summary

Intermediate

1. Trickier Forms
2. Perl References
3. Default Values
4. CGI Stickiness
5. JavaScript Actions
6. Input Validation 2
7. Multiple Submits
8. JavaScript Actions 2
9. Modules & mod_perl
10. Smartness
S. Summary

Advanced

1. Remaining Features
2. Intro to Templates
3. HTML::Template
4. HTML::Template 2
5. Template Toolkit
6. Exploiting render()
7. Multi-Screen Apps
8. Multi-Screen Apps 2
9. Multi-Screen Apps 3
10. Custom Messages
S. Summary

Advanced Tutorial - Step 7: Multi-Screen Apps Print

<< Exploiting render() | Multi-Screen Apps 2 >>

There are a couple different web design schools of thought. One school believes that you should create a separate script for every component of your site. That is, if you had a message board, you might have scripts called newmesg.pl, editmesg.pl, viewmesg.pl, delmesg.pl, and so on. Using FormBuilder with this methodology is simple - you would just create a separate $form object in each component.

Another school of thought believes that you should instead just place all of your code in a single script, and use a separate CGI parameter named something like mode or action to tell you what to do. The advantage of this method is that you only have to import your modules, connect to your database, and so forth in one central place.

If you want to use this methodology, FormBuilder can handle it as well. You have two options:

Create a separate CGI.pm $query object, use it to get your params, and then create your $form objects with the params option.
Create a single $form object, and get to the other params with $form->cgi_param.

Which way you go depends on one factor: Whether or not your different application screens require different fields. If so, then you want to use the first methodology. Otherwise, use the second one.

Let's look at each alternative.

<< Exploiting render() | Multi-Screen Apps 2 >>