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.

Probably

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).

I fear such things are too application-specific to include in the package. Consider this: people will need custom templates to output the buttons, some CSS and whatever, they'll need to place them in different places in the form, etc. So you'll have to add an insane amount of configuration to be able to place the buttons in whatever place you want and with whatever look you want.

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.

The programmer may easily create a subclass of QF_Page that will contain all necessary headers, footers and whatever and will serve as a base class for all Pages in the application. I'll redo the tabbed.php example to show this. There is no need to pollute the generic base class with presentation details, especially since most of presentation stuff will be done in 'display' action handler based on the renderer used.