Home » HTML » HTML_QuickForm_Controller » Bug #5234

[2005-08-29 14:09 UTC] pear at david dot endeavororcomputing dot com

Description:
------------
QuickForm_Controller has great potential for modularity and code reuse. For example, the site I'm working on has a bunch of wizards that often ask for the same steps, so I've created a library of QuickForm_Controller Page objects for inclusion throughout the site.

But the built-in usefulness of these objects is limited because page objects, in several of the examples and by necessity, HAVE TO KNOW ABOUT THEIR SURROUNDING PAGES. The tabs example takes this to an absurd level, where the tabs for the pages are copied and pasted into each page object's creation function. This is a very bad thing, and the Controller object should really manage this. The only time pages should need to know about each other is for state machine style forms.

I've subclassed the controller and page classes to hack this into place by having the controller keep an inventory of friendly page names and a function that, given a page by reference, adds tab and wizard navigation to the page. The subclassed page object calls this function in its controller when it gets built for display. This allows me to use my "people picker" page on any wizard on the site without silly levels of infoming my people picker page object about the names of its surrounding pages and whether it's the first page.

Ideally, this functionality could be part of the real controller, and the implementation could be cleaner by such integration. I'd like to see, at the minimum, an integration of an "use tab buttons" and an "use wizard buttons" functionality when the controller gets constructed.

[2005-08-29 14:11 UTC] pear at david dot endeavororcomputing dot com

Probably

[2005-08-29 14:24 UTC] pear at david dot endeavororcomputing dot com

The tabs and wizard buttons function could also be implemented through functions instead of the constructor, i.e. makeTabs(bool $make = true) and makeWizard(bool $make = true).

[2005-08-30 17:27 UTC] pear at david dot endeavororcomputing dot com

I think I can address your concerns with this modified model. We can give the controller header and footer element arrays. These elements would have conditional rendering options (i.e. disabled on first page, disabled on page name $x). These rendering options would dynamically apply based on what page calls the controller::renderHeaders(&$page) function. Upon rendering, the subclassed page object would first send off the header elements from its controller, then its own elements, then its footer elements. So, the rendering would be almost exactly the same as copying and pasting the elements into every page's creation function.

This would allow, at least, easy subclassing to add tabs and wizard buttons. The programmer would only need to overload the "add page" function in the controller to update the header or footer.