Re: QuickForm Best Practices
| From: | Bertrand Mansion | Date: | Tue, 04 Dec 2007 09:28:43 +0000 |
| Subject: | Re: QuickForm Best Practices | ||
| References: | 1 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-28260@lists.php.net to get a copy of this message | ||
Le 3 déc. 07 à 21:14, Hollenbeck, Dan a écrit :
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?I recommend the QuickForm_Controller package for that. I have this structure : 1. Controllers : my application logic 2. Helpers : they help setting up the forms and store repetitive code used for this task 3. Forms 3.1. Pages (QuickForm_Controller Pages): They describe and build the forms 3.2. Actions (QuickForm_Controller Actions): They deal with form submission Example: 1. AccountManager 2. function initForm(), function renderForm() 3.1. AccountForm 3.2. AccountRegisterAction, AccountDeleteAction, etc. All my form pages extend a QF Page object that initializes renderer, QFController stuff. On a 5000 visits per day site, I don't have any problems, but forms are only in admin/account/contact areas which are less visited. While heavy on duty, I don't think QF is too slow. I suggest that your controller deal with setting the default values. -- Bertrand Mansion Mamasam Work : http://www.mamasam.com Blog : http://golgote.freeflux.net