Matthew (and others),
'Twas brillig, and Matthew Weier O'Phinney at 01/04/09 12:11 did gyre
and gimble:
-- [email protected] <[email protected]> wrote
(on Wednesday, 01 April 2009, 10:14 AM +0000):
Thanks for the response again. I just read in an issue that this is made
intentional behaviour:
http://framework.zend.com/issues/browse/ZF-277
But I strongly disagree with this. Therefor I created a new issue:
http://framework.zend.com/issues/browse/ZF-6174
I can't get to the issue tracker right now, but I can tell you now that
I'm going to deny the request.
The reason is two-fold.
First, the design of the form view helpers since the very beginning has
been to *always* create IDs. This is to make it trivial to get to the
discrete elements using JavaScript, as well as to make testing easy
(easier to select DOM elements by ID than other methods, though
Zend_Dom_Query now makes it less of an issue).
I don't want to go over old ground here, but I'm running up against a
problem with this now too.
In my case I have a dynamic javascript form, that allows users to filter
a search.
When they add a new filter, a drop down appears asking them to pick a
filter, when this is selected, it loads a further part of the form
asking them to pick a comparator (e.g. =, >=, "on", "before" etc.
depending on the search term) and a value to go with it.
So I get a form like:
[ Choice of filters (v)] [ Comparator (v)] [ value ] (-)
(+)
Clicking the plus sign gives me a new row, and a new "Choice of filters"
drop down to be displayed... picking somethign from this will fill in
the comparator and value fields etc. etc.
Now there is nothing to stop a user adding the same filter twice...
(e.g. perhaps I want to filter my data based on creation date, I may
want all items created after 1st Jan 2009 but before 1st Feb...
therefore I will be adding two versions of this form element.
Now this works fine, but the id's of the elements generated serve
absolutely no purpose here. All of my code is not based on id, but on
class (as it is dynamic and I can add/remove filters at will).
In the above example:
[ Created on (v)] [ After (v)] [ 1st Jan 2009 ] (-)
[ Created on (v)] [ Before (v)] [ 1st Feb 2009 ] (-)
(+)
1 2 3
Here element 1 is used purely in javascript, but never referenced by
it's ID. The events and bindings etc. happen when the element is added
and it works with AJAX in a purely relative fashion (e.g. manipulating
the elements with certainly classes in the same containing element as
itself). Elements 2 and 3 will be submitted with the form (both of them
as arrays to allow for multiple filtering).
This is surely a valid case for disabling the id attribute?
Currently the methods that get the elements and return them are
returning the elements directly (for direct use in ajax), so I do not
need the form itself to be returned, just the rendered elements.
So I do a:
echo str_replace('id="foo"', '', $el->setAttrib('id', 'foo'))
Which works but it's clearly very, very hick.
If there was any easy way to disable the id attribute from rendering,
then I could produce my dynamic form quite happily.
I think this is a fairly valid use case.
If this description/use case isn't clear, please just shout and I'll
clarify.
To force ids on all form elements can actually make it much worse for
working with javascript. The power of javascript can come from
manipulating the dom, adding in new parts and extending existing forms
dynamically etc. So while the premise is laudable (i.e. always generate
ids to make working with javascript easier), it is fundamentally
incompatible with some use cases.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
