FB + QFC + back + linkNewValue = trouble
| From: | Ken Restivo | Date: | Wed, 25 May 2005 22:00:25 +0000 |
| Subject: | FB + QFC + back + linkNewValue = trouble | ||
| Groups: | php.pear.general | ||
| Request: | Send a blank email to pear-general+get-19371@lists.php.net to get a copy of this message | ||
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Looks like FB's linkNewValue (and the subform class too, and my own homegrown stuff, which all
take similar approaches) creates subordinate forms. Nice idea, works great.
Until you try to use it with QFC. $controller->exportValues() iterates through and calls
exportValues() on each page of the wizard, to save its values into $_SESSION. Nice idea there too,
works great.
But when you combine the two? Trouble.
QFC doesn't know about subordinate forms that were created by FB (or the subform class, or my
own stuff). So the $page->exportValues() doesn't return it, and thus, neither does the QFC
save it. When you click back, then next, all of your values entered into subforms are gone forever.
I've found that this tends to alarm and frustrate users.
Any ideas? I might try overriding the HTML_QuickForm_Page::exportValues() to iterate through the
cached reference to the subforms, and return the merge of their results with the
parent::exportValues().
- -ken
- --
- ---------------
The world's most affordable web hosting.
http://www.nearlyfreespeech.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFClPV5e8HF+6xeOIcRAgMSAJ4gft0jjNZwrvp7T9Ha0FnweLtffACfalSy
yt8taS8NZL4TrljSHieQeYc=
=2H5B
-----END PGP SIGNATURE-----