Re: HTML_QuickForm Form Elements Error Issue
| From: | Justin Patrin | Date: | Wed, 02 Mar 2005 03:53:39 +0000 |
| Subject: | Re: HTML_QuickForm Form Elements Error Issue | ||
| References: | 1 2 3 4 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-17779@lists.php.net to get a copy of this message | ||
On Tue, 01 Mar 2005 21:51:13 -0600, Sarah Gray <sarah@fabled.net> wrote:
> >
> > >
> > > once the names rolled over so they were over 1000, the form did not treat
> > > them as required: even though they had their required properties set to
> > > true, and I could confirm this from echoing out from with QuickForm.php,
> > > they were not seen, in the following function, as required.
> >
> > Ah....ok, well I'm sure this is because everything in QF (and most of
> > PHP) is stored in assoc arrays, but when you supply a # it ends up
> > using a number as the key. I best QF doesn't convert names and such to
> > strings.
>
> Should it? Or would it be better practice for me to rename my elements? And
> finally does removing that flag, true, in QuickForm pose any problems (other than
> the obvious of being out of sync and not being to upgrade)? I'm looking for a
> quick fix, and unfortunately, the code below didn't work...
Well I would say you should just not have element names which are only
numbers. They don't mean anything and are prone to bugs such as this.
If you need this fixed *now* sure, make thw QF change. I'm not sure
what all it might affect, though. Feel free to look closer to try to
figure out why exactly this is happening. Perhaps you're also making
the addRule call with a #? Try passing in a string, as in my example.
>
> Thanks.
>
> >
> >
> > Try using (string) on your element names.
> >
> > for ($i = 990; $i < 1010; ++$i) {
> > $form->addElement('checkbox', (string)$i, 'Element '.$i);
> > }
>
> >
> > >
> > > function isElementRequired($element)
> > > {
> > > return in_array($element, $this->_required, true);
> > > } // end func isElementRequired
> > >
> > > When I changed their names randomly to start with "q" (just to try a
> > > string), the whole thing worked.
> > > This is why I had never seen this before -- we had gone through 999 test
> > > choices with it working just fine. It has something to do with the strict
> > > flag on in_array.
> > >
> > > So I either need to change all my element names to strings, or...
> > >
> > > remove the strict flag in the above function.
> > >
> > > I can do one of two things. Both work, I have tested.
> > >
> > > 1. Leave my elements named as they are and change the line in
> > > isElementRequired to:
> > > return in_array($element, $this->_required);
> > > ie, remove the strict flag
> > >
> > > OR
> > >
> > > 2. Change my element names to strings.
> > >
> > > Since we are live I would rather do the former, at least as a stop gap till
> > > I can test the latter. Can someone tell me if this is inviting any other
> > > danger I'm not considering -- if I remove the strict flag from return
> > > in_array($element, $this->_required, true); ?
> > >
> > > What would be the implications? Am I OK to do this for a few days? Does it
> > > matter if I do it for the long run? Is it bad to have named the elements
> > > numerically in the first place?
> > >
> > > Thanks very much.
> > >
> > > Sarah
> > >
> > > Sarah Gray wrote:
> > >
> > > > Hi --
> > > >
> > > > I'm having a bizarre behaviour -- I have a form which is a series of
> > > > questions, a test When creating the form, I apply the "required" rule
> > > > to every element in the form in a loop like this:
> > > >
> > > > $form->addRule($question->question_id, 'Required',
> > > > 'required');
> > > >
> > > > and when I layout the form I put an asterisk by each element, like so:
> > > >
> > > > {if $element.required}<span class="error">*</span>{/if}
> > > >
> > > > Every single element is asterisked, as it should be.
> > > >
> > > > BUT when I submit the form and printout the error array (for debugging
> > > > purposes), only the first ten elements are in it -- and you can
> > > > successfully submit the form without checking anything but the first ten
> > > > elements!
> > > > .
> > > > This didn't use to be the case -- I don't know where the bug came from
> > > > and it's come at a terribly bad time. I'm really flummoxed how
> > > > elements
> > > > could have the element.required property and not stop the browser from
> > > > submitting if they are not selected.
> > > >
> > > > Does anyone have any suggestions / hints / help? I'm pretty lost at the
> > > > moment -- and this bug came out of seemingly nowhere -- it did not use
> > > > to behave like this but I haven't changed any of my PEAR packages.
> > > >
> > > > Thanks,
> > > >
> > > > Sarah
> > > >
> > > > --
> > > > PEAR General Mailing List (http://pear.php.net/)
> > > > To unsubscribe, visit:
> > > > http://www.php.net/unsub.php
> > >
> > > --
> > > PEAR General Mailing List (http://pear.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
> > --
> > Justin Patrin
>
>
--
Justin Patrin