Re: FB + QFC + back + linkNewValue = trouble
| From: | Justin Patrin | Date: | Fri, 27 May 2005 00:04:10 +0000 |
| Subject: | Re: FB + QFC + back + linkNewValue = trouble | ||
| References: | 1 2 3 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-19380@lists.php.net to get a copy of this message | ||
On 5/25/05, Ken Restivo <ken@restivo.org> wrote:
> 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 weeks fiddling with this, and had no luck finding that. I
> never would have even thought to look there.
:-) It took a while for me to find it, too. I assumed QFC would be
using setDefaults as this is what makes sense... but, alas,
HTML_QuickForm_Page extends HTML_QuickForm so they assume they can
play with internal vars... It's ok if they're protected, but those are
more private vars...
And in case you wanted to see it working:
http://pear.reversefold.com/SubFormQFC.php
>
> >
> > 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.
And, unfortunately, I do it with the SubForm element as I have no
other choice. Well, I don't set any private vars except _submitValues
in the subForm. Other than that I read a few private vars. But this is
mostly due to a lack of a public API to interact with them. I also doa
bit of "private var magic" in FormBuilder, but I plan to fix
it...eventually...when I figure out how.
>
> > 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):
>
[snip]
>
> 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,
> addSubTables() is similar to FB::_prepareLinkNewValue().
Never thought people wouldn't be able to figure that out...I could add
an option which would add a button in FormBuilder instead of making it
an option in the select. I'd also have to make it add the option to
the select and select it, though, as the value in the select is
important for making the whole system work right now...
>
> SubForm seems more anatomically-correct, so I'll probably modify my app to use it instead.
:-) go for it. Let me know if you encounter any errors.
>
> Again, thanks for tracking this down so quickly.
>
And, also, I've altered FormBuilder to use SubForm instead of the
PopupSelect element I had previously created (it was more of a hack
than SubForm and less compatible). I would really appreciate it if you
could give it a try and see if it works for you in QFC.
http://pear.reversefold.com/DB_DataObject_FormBuilder-0.16.1pre2.tgz
I did a quick test of FB with QFC here:
http://pear.reversefold.com/LinkNewValueQFC.php
Go to the second page and you can see my Movie form created by FB. The
Genre select has a --New Value -- entry and it seems to be keeping its
values if you click next then back.
--
Justin Patrin