Forms RFC now up

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

weierophinney
Administrator
-- Derek Miranda <[hidden email]> wrote
(on Wednesday, 29 February 2012, 09:27 AM -0500):
> The beauty of Zend Framework in general is that it is easy to modify
> and extend. I, too, had the same problem with forms as Stew. However,
> I always extend some base classes of Zend so I can easily plug in my
> own functions without touching the Framework itself. Of note, I
> extended Zend_Form and Zend_Form_Element_Xhtml to add the custom
> prefixing operations I wanted. Easy as 1-2-3. I don't see where the
> problem lies here. The framework will _never_ solve all of a
> developers problems and it is up to the developer to wrap solutions.

This last sentence struck a chord -- it's exactly the approach I'm
trying to take in components I develop for ZF2. With ZF1, I think we
tried to hard to accommodate too many use cases, when many of these were
highly project- or situation-specific. If we develop components
correctly, users can extend them, or develop alternate implementations
based on the interfaces we provide, in order to provide those features.
Additionally, with the new module system, they can make those solutions
available easily to other users.

> On Feb 29, 2012, at 9:12 AM, Matthew Weier O'Phinney wrote:
>
> > -- Andreas Möller <[hidden email]> wrote
> > (on Wednesday, 29 February 2012, 08:51 AM +0100):
> >>> It would be the same form class though and that is enough to cause collisions.
> >>
> >> How could that happen?
> >>
> >> The point of classes is for you to specify a selector for styling
> >> classes of elements, isn't it?
> >
> > Yes and no. Most modern JS libraries use CSS selectors to query for DOM
> > elements -- jQuery's $(), Dojo's dojo.query(), etc. Most UI/UX folks
> > prefer using CSS selectors over explicit IDs as it makes the markup
> > semantic.
> >
> >> A collision would only occur if you use an inappropriate selector in
> >> the context of JavaScript, e.g., when you meant to attach behaviour to
> >> a *specific* element, but instead used a selector which would attach
> >> aforementioned behavior to a *class* of elements.
> >
> > If you have a class specific to a given form, you can specify individual
> > elements of that form very easily; for example, ".myform input.email".
> >
> >>>> I see, the prefix would then namespace the form and the elements' ids
> >>>> in it, but would have to be prefixed for both the form and the
> >>>> elements.
> >>>
> >>> That's correct, and further I am suggesting that we should limit our
> >>> use of IDs to cases where they are required (e.g. labels/inputs) and
> >>> favor classes elsewhere.
> >>
> >> But not for specifying a concrete element. That's what ids are for, at
> >> least from my understanding.
> >
> > Um, that's exactly what Stew is suggesting -- IDs for specific form
> > elements and labels -- but not necessarily for the other markup
> > generated when outputting them (such as the wrapping <div>, <dt>, <li>,
> > etc.), nor necessarily for the form itself.
> >
> >> A second thought concerning the issue of prefixing - it probably makes
> >> more sense to suffix, depending on the circumstances, especially as
> >> you can easily suffix with a hash, which is not true for prefixes (as
> >> you can't start with a number).
> >
> > Both are equally challenging from an implementation perspective. I know
> > this... because Zend_Form in ZF1 actually _does_ attempt to do ID
> > prefixing, and succeeds to an extent.
> >
> > --
> > Matthew Weier O'Phinney
> > Project Lead            | [hidden email]
> > Zend Framework          | http://framework.zend.com/
> > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Derek Miranda

On Feb 29, 2012, at 10:09 AM, Matthew Weier O'Phinney wrote:

> -- Derek Miranda <[hidden email]> wrote
> (on Wednesday, 29 February 2012, 09:27 AM -0500):
>> The beauty of Zend Framework in general is that it is easy to modify
>> and extend. I, too, had the same problem with forms as Stew. However,
>> I always extend some base classes of Zend so I can easily plug in my
>> own functions without touching the Framework itself. Of note, I
>> extended Zend_Form and Zend_Form_Element_Xhtml to add the custom
>> prefixing operations I wanted. Easy as 1-2-3. I don't see where the
>> problem lies here. The framework will _never_ solve all of a
>> developers problems and it is up to the developer to wrap solutions.
>
> This last sentence struck a chord -- it's exactly the approach I'm
> trying to take in components I develop for ZF2. With ZF1, I think we
> tried to hard to accommodate too many use cases, when many of these were
> highly project- or situation-specific. If we develop components
> correctly, users can extend them, or develop alternate implementations
> based on the interfaces we provide, in order to provide those features.
> Additionally, with the new module system, they can make those solutions
> available easily to other users.

Matthew: I whole heartedly agree and it is the right approach in my opinion.

>
>> On Feb 29, 2012, at 9:12 AM, Matthew Weier O'Phinney wrote:
>>
>>> -- Andreas Möller <[hidden email]> wrote
>>> (on Wednesday, 29 February 2012, 08:51 AM +0100):
>>>>> It would be the same form class though and that is enough to cause collisions.
>>>>
>>>> How could that happen?
>>>>
>>>> The point of classes is for you to specify a selector for styling
>>>> classes of elements, isn't it?
>>>
>>> Yes and no. Most modern JS libraries use CSS selectors to query for DOM
>>> elements -- jQuery's $(), Dojo's dojo.query(), etc. Most UI/UX folks
>>> prefer using CSS selectors over explicit IDs as it makes the markup
>>> semantic.
>>>
>>>> A collision would only occur if you use an inappropriate selector in
>>>> the context of JavaScript, e.g., when you meant to attach behaviour to
>>>> a *specific* element, but instead used a selector which would attach
>>>> aforementioned behavior to a *class* of elements.
>>>
>>> If you have a class specific to a given form, you can specify individual
>>> elements of that form very easily; for example, ".myform input.email".
>>>
>>>>>> I see, the prefix would then namespace the form and the elements' ids
>>>>>> in it, but would have to be prefixed for both the form and the
>>>>>> elements.
>>>>>
>>>>> That's correct, and further I am suggesting that we should limit our
>>>>> use of IDs to cases where they are required (e.g. labels/inputs) and
>>>>> favor classes elsewhere.
>>>>
>>>> But not for specifying a concrete element. That's what ids are for, at
>>>> least from my understanding.
>>>
>>> Um, that's exactly what Stew is suggesting -- IDs for specific form
>>> elements and labels -- but not necessarily for the other markup
>>> generated when outputting them (such as the wrapping <div>, <dt>, <li>,
>>> etc.), nor necessarily for the form itself.
>>>
>>>> A second thought concerning the issue of prefixing - it probably makes
>>>> more sense to suffix, depending on the circumstances, especially as
>>>> you can easily suffix with a hash, which is not true for prefixes (as
>>>> you can't start with a number).
>>>
>>> Both are equally challenging from an implementation perspective. I know
>>> this... because Zend_Form in ZF1 actually _does_ attempt to do ID
>>> prefixing, and succeeds to an extent.
>>>
>>> --
>>> Matthew Weier O'Phinney
>>> Project Lead            | [hidden email]
>>> Zend Framework          | http://framework.zend.com/
>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Stewart Lord
In reply to this post by weierophinney
On 12-02-29 7:09 AM, Matthew Weier O'Phinney wrote:
> This last sentence struck a chord -- it's exactly the approach I'm
> trying to take in components I develop for ZF2. With ZF1, I think we
> tried to hard to accommodate too many use cases, when many of these were
> highly project- or situation-specific. If we develop components
> correctly, users can extend them, or develop alternate implementations
> based on the interfaces we provide, in order to provide those features.
> Additionally, with the new module system, they can make those solutions
> available easily to other users.

Indeed, and even in ZF1 we were able to extend Zend_Form to provide a
prefix facility. It was a bit tedious and is not as robust as it
could/should be.

I just mention it because it bites us with some regularity. Definitely
one of my top gripes with forms in ZF1.

Cheers,
Stew
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Stewart Lord
In reply to this post by Andreas Möller
> A collision would only occur if you use an inappropriate selector in the context of JavaScript, e.g., when you meant to attach behaviour to a *specific* element, but instead used a selector which would attach aforementioned behavior to a *class* of elements.

When the same element id appears twice in the DOM, form labels and JS
DOM queries will behave poorly. Some JS libraries, such as Dojo will
throw errors loudly (e.g. if the collision occurs on a 'dijit'.)

> A second thought concerning the issue of prefixing - it probably makes more sense to suffix, depending on the circumstances, especially as you can easily suffix with a hash, which is not true for prefixes (as you can't start with a number).

Suffixing would work great too.

Cheers,
Stew
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Andreas Möller
> When the same element id appears twice in the DOM, form labels and JS DOM queries will behave poorly. Some JS libraries, such as Dojo will throw errors loudly (e.g. if the collision occurs on a 'dijit'.)

That's what I said.


Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Andreas Möller
In reply to this post by weierophinney
> Yes and no. Most modern JS libraries use CSS selectors to query for DOM
> elements -- jQuery's $(), Dojo's dojo.query(), etc. Most UI/UX folks
> prefer using CSS selectors over explicit IDs as it makes the markup
> semantic.

I believe you can have a perfectly valid and semantic markup that
doesn't become less semantic if you attach IDs where it's appropriate
and necessary.

If it's appropriate, because an ID is required for a for form element
so a label element can refer to it, it makes the markup even more
accessible, which is a good thing and also necessary.

If you need IDs because you can not otherwise identify a node in the
DOM - as there's no way for you to create a selector that selects
equal children of a specific or a class of nodes in the context of
JavaScript, it's perfectly valid and doesn't make your markup less
semantic.

All you're saying is: this node (with whatever children it has and
whatever content it has) exists only once in the DOM.

Think of a representation of a table in a database, marked up with
table, tr, th, td, etc. elements to which you want to attach
behaviour, e.g. "delete a corresponding row in the database and on
success, from the markup, too".

There's no way to to this without IDs, still it doesn't make the
markup less semantic.

It's only a bad thing to use IDs when they are used for presentational
purposes. Then, indeed, your markup may become less semantic.

But, as we were talking about forms / widgets, it never occurred to me
that we were talking about presentational issues, but more about
behavioural aspects.

>> A collision would only occur if you use an inappropriate selector in
>> the context of JavaScript, e.g., when you meant to attach behaviour to
>> a *specific* element, but instead used a selector which would attach
>> aforementioned behavior to a *class* of elements.
>
> If you have a class specific to a given form, you can specify individual
> elements of that form very easily; for example, ".myform input.email".

But not to the needed extent, possibly (see above). Applying a class
to identify an element in a *set* would be a misuse of classes.

> Um, that's exactly what Stew is suggesting -- IDs for specific form
> elements and labels -- but not necessarily for the other markup
> generated when outputting them (such as the wrapping <div>, <dt>, <li>,
> etc.), nor necessarily for the form itself.

But it would be needed for the form if you need to identify which
element in a set of similar, but not equal forms was submitted,
wouldn't you? Unless you started inspecting the elements in it ("find
a hidden input with an id in it").

In HTML5 one would rarely use divs anyway.

And, depending on the behaviour, you may need IDs, see above.

> Both are equally challenging from an implementation perspective. I know
> this... because Zend_Form in ZF1 actually _does_ attempt to do ID
> prefixing, and succeeds to an extent.

Good.


Best regards,

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Stewart Lord
On 2/29/12 9:00 PM, Andreas Möller wrote:
 > All you're saying is: this node (with whatever children it has and
 > whatever content it has) exists only once in the DOM.

Exactly, and unfortunately ZF1 forms make it hard not to violate the
'only once' rule if you have multiple forms on the same page.

> But it would be needed for the form if you need to identify which
> element in a set of similar, but not equal forms was submitted,
> wouldn't you?

What do you mean by 'submitted'?

Stew
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Andreas Möller
In reply to this post by Andreas Möller
> What do you mean by 'submitted'?

POSTed or GETed.

In the context of your example where you have form widgets, I assumed
they were submitted via XmlHttpRequest and the required JavaScript
tied to an input element (the submit button) by using a selector that
contains the id of the form.


Best regards,

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Stewart Lord
On 2/29/12 11:02 PM, Andreas Möller wrote:
>> What do you mean by 'submitted'?
>
> POSTed or GETed.
>
> In the context of your example where you have form widgets, I assumed
> they were submitted via XmlHttpRequest and the required JavaScript
> tied to an input element (the submit button) by using a selector that
> contains the id of the form.


Thanks for clarifying. Actually, most of our forms are loaded via
xhr-get into a dialog (namely dijit.Dialog). On load, we can find
specific elements in the form by scoping our query to the dialog's dom
node. For the specific case of catching submits, dijit dialogs have a
special onExecute() method that gets invoked.

As an alternative, let's suppose the form is in the page already. I
would be inclined to query for 'form.widget-form input[type=submit]' as
opposed to '#widget-form input[type=submit]' because the former will
work for every instance of widget-form on the page.

Regards,
Stew
123