| Hollenbeck, Dan 2007-12-03, 7:06 pm |
| Hi All,
I am in need of some advice about the best practices for using QuickForm
(QF) in a large application or framework. In particular, how best to
structure the code AROUND the QF API. There are a number of very good
tutorials I have used to become very familiar with the QF API, however
none of these tutorials cover the best way to structure your QF code for
a large application. My web application has 30+ forms and 500+ form
elements.
Are you better to subclass QF or make a builder class that acts on a
passed reference of an existing QF object?
Here are my application requirements and design thoughts:
- Must be highly scalable.
- Each form code must be re-usable in different contexts with
minimum code duplication. For example, both the site visitor and the
site administrator could use the same form. The site administrator
could have additional form elements added and/or relaxed validation
rules on the form.
- The calling script must not need to know any specifics of the
form code implementation. For example, if the select element options are
pulled from the database the form class must not be dependent on
anything from the calling script to make this happen. The purpose for
this is so that I can have generic page controllers.
- I would rather the calling script handle the processing of
submitted data into the database. However, this means that both the
controller script and the form script both need to know how to access
the database.
- The calling script will determine the type of submit element
(i.e. buttons). The same form could be used as a standalone form (i.e.
simple submit "Save" button) or part of a sequence of forms chained
together to make a wizard like feature for the site administrator (i.e.
submit "Next >" or submit "Save Continue", "Skip"). Therefore, the
calling script would best determine how the form is actually being used.
- The calling script determines the render applied to the form.
In my application I use three types of renders: simple subclass of the
default render for simple forms (this allows for zero coding of the
presentation code, which is the ultimate in separation), Smarty for
complex forms or complex form presentations, and a custom XAJAX render
that allows any QF to now support AJAX functionality. The controller
script knows how the form is being used, and what renender to apply.
- Setting defaults: I would rather have the controller script
set the form default values so that we could do a security check on the
data before we $form->setDefaults($data).
Thanks, Dan
|