PHP Pear - Re: [PEAR] FB + QFC + back + linkNewValue = trouble

Author

Re: [PEAR] FB + QFC + back + linkNewValue = trouble

Justin Patrin

2005-05-26, 8:59 pm

On 5/25/05, Ken Restivo <ken@restivo.org> wrote:
> Looks like FB's linkNewValue (and the subform class too, and my own homeg=
rown stuff, which all take similar approaches) creates subordinate forms. N=
ice idea, works great.
>=20
> Until you try to use it with QFC. $controller->exportValues() iterates t=
hrough and calls exportValues() on each page of the wizard, to save its val=
ues into $_SESSION. Nice idea there too, works great.
>=20
> But when you combine the two? Trouble.
>=20
> 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 retur=
n it, and thus, neither does the QFC save it. When you click back, then nex=
t, all of your values entered into subforms are gone forever. I've found th=
at this tends to alarm and frustrate users.
>=20
> Any ideas? I might try overriding the HTML_QuickForm_Page::exportValues()=
to iterate through the cached reference to the subforms, and return the me=
rge of their results with the parent::exportValues().
>=20

Hmmm, I hadn't tried using linkNewValue or SubForms with QFC. However....

SubForms, assuming you're using
http://pear.reversefold.com/SubForm.phps, *should* work fine. I did
everything I could to make sure that this was a real element. Its
values are exported just like normal elements' values. setDefaults
(which I assume QFC uses to set the values when you come back to a
form) should also work fine with subforms. I'll do a quick test myself
to make sure of this, though.

Well, what do you know, it doesn't work. And after a bunch of fiddling
I finally figured out that QFC is setting _submitValues manually.
This, of course, wasn't being copied to the subform so the values
weren't set. I've fixed my SubForm code.

However, IMHO QFC really shouldn't be doing it that way as it breaks
all of these kind of things. IMHO it should use setDefaults or
setConstants as that would accomplish the same thing.

linkNewValue is, indeed, a problem, as I just made it work without
trying to make it a normal QF element. The linkNewValue element
(PopupSelect) does not behave like a normal QF element. It's very
tightly coupled to FB and this is why it's not working in QFC. You may
be able to hack it to make it work, but a much better solution would
be to port FB's linkNewValue to use the SubForm element.

I'll put this on my list of FB things to do.

--=20
Justin Patrin

Ken Restivo

2005-05-26, 8:59 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, May 25, 2005 at 09:18:00PM -0700, Justin Patrin wrote:
> Hmmm, I hadn't tried using linkNewValue or SubForms with QFC. However....
>
> Well, what do you know, it doesn't work. And after a bunch of fiddling
> I finally figured out that QFC is setting _submitValues manually.
> This, of course, wasn't being copied to the subform so the values
> weren't set. I've fixed my SubForm code.

Thanks. You rule! I've spent w

s fiddling with this, and had no luck finding that. I never would have even thought to look there.

>
> However, IMHO QFC really shouldn't be doing it that way as it breaks
> all of these kind of things. IMHO it should use setDefaults or
> setConstants as that would accomplish the same thing.
>

Indeed. Setting private variables == bad. Of course, I do it myself occasionally, but in a custom app where I pretty much have control over the whole thing.

> linkNewValue is, indeed, a problem, as I just made it work without
> trying to make it a normal QF element. The linkNewValue element
> (PopupSelect) does not behave like a normal QF element. It's very
> tightly coupled to FB and this is why it's not working in QFC. You may
> be able to hack it to make it work, but a much better solution would
> be to port FB's linkNewValue to use the SubForm element.
>

My approach is kind of a mix of SubForm and FB. For your amusement (and my embarassment):

class HTML_QuickForm_customselect extends HTML_QuickForm_select
{
var $CoopForm; // cache it

function toHtml()
{
list($table, $field) = explode('-', $this->getName());

// used in a few places
$qfname = sprintf("%s-subtables-%s", $table, $field);

$vars =& $this->CoopForm->form->getSubmitValues();
if(isset($vars[$qfname])){
$sub =& $this->CoopForm->addSubtable($field);

// so that it stays expanded ;-)
$sub->form->addElement('hidden',
$qfname, 'pass-through');

require_once('HTML/QuickForm/Renderer/Default.php');
$renderer = new HTML_QuickForm_Renderer_Default();
$sub->form->accept($renderer);

$res .= sprintf(
'<div id="%s">%s</div>',
$this->getName(),
preg_replace('!</?form[^>]*?>!i', '',
$renderer->toHTML()));

} else {
// the regular selectbox, but with

stuff
//TODO: add the _js stuff for showNew()!
$res .= parent::toHTML();
$res .= sprintf(
" <input type=\"submit\" onClick=\"{$this->_jsPrefix}showNew(this.form.elements['%s'])\" name=\"%s\" value=\"<< Add New\" />",
$this->getName(), $qfname);

}

return $res;
}

}

My users couldn't figure out "-- New Value --" so I gave them an "Add New" button prominently displayed next to the popup. And I have a burning passionate hate of JavaScript (my browser is w3m), so I'm doing the popup/subform switch server-side. FYI, add
SubTables() is similar to FB::_prepareLinkNewValue().

SubForm seems more anatomically-correct, so I'll probably modify my app to use it instead.

Again, thanks for tracking this down so quickly.

- -ken
- --
- ---------------
The world's most affordable web hosting.
http://www.nearlyfreespeech.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFClWx6e8HF+6xeOIcRAvmrAKDIKZr/dS+IUUGwKKh+vqAmQBZnhwCfdmHl
b7zBJXSuBZWqg9F4lBOLYL4=
=3uik
-----END PGP SIGNATURE-----

Sponsored Links