QuickForm Best Practices

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