Re: Using QuickForm_Controller

On 6/8/05, Ken Restivo <ken@restivo.org> wrote: > I've spent the last month or so wrestling with QuickForm_Controller. I have almost > defeated it, but it is putting up one hellacious fight. > > The biggest challenge is that no code which makes use of $_REQUEST['blah'] can ever > be expected to work with QFC. This is because QFC stores state in $_SESSION in between requests, and > looks there for everything. Of course, I stupidly had $_REQUEST crap all over my app. > > What I have had to do in order to make my application QFC-compatible is: > > 1) Replace all uses of $_REQUEST with $page->getSubmitValues(), or the various > $controller->container() access hacks that are documented in QFC's FAQ, and Actually, all QF code should really be using exportValues() as it sanitizes and only returns the values that are actually *in* the QF. This should have been expected. > > 2) Make sure that all my hidden's are actual $page->addElement('hidden', blah > blah) in the parent form, instead of hacking them in using ->toHTML() methods. Of course....if you're using raw HTML in your forms you're not using QF as it's supposed to be used. > > This has often involved slipping references to the QF into my custom elements, much as Justin > has done in his SubForm::setParentForm() method. Hopefully this shouldn't be needed often.. Remember if you're doing your own element you can always have a hidden element within it. You can even extend the group element and do it that way. If you're using a ref to the form you can most likely do it in a better way. THe only reason SubForm has that ref is because it's a hack to make a form within a form and I need to copy values from the main form. > > I'm just noting this so that it will appear in the archives; hopefully others will Google > for it and thus save themselves some pain in the future. > -- Justin Patrin