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

guilhermeblanco@gmail.com
Hi Matthew,

First of all I have no idea about all the ranting of people pointing that ZF2 is copying SF2 Forms.
I used ZF1 Forms a lot and all I can tell you is that I gave up using them after some serious injuries to my brain. I ended up by creating a project that was mainly JSR-303 (Bean Validation) together with Rafael Dohms, supporting not only validation, but Filtering (where are SF2 folks to tell they invented that?

After that, we came up with DMS\Filter, which was used in an internal project at MIH that uses ZF1. So we drafted JSR-303, we created a Filter library, I spent a lot of time creating a Serializer, that was able to convert from arrays to xml, yaml, URI, etc and vice-versa.

Finally, I created a Mediator, which was a conjunction of serializer, filtering and validation, which was heavily tied to Doctrine 2 entities.

The conclusion o that effort was pretty clear:
1- Accepting virtual properties actually allows you to bind not only Doctrine 2 entities, but any class that can be annotated (yes, we used Doctrine 2 Annotations)
2- It is possible to serialize, filter and even validate nicely with only a single Request data (in our case, we were using the $request->getParameters())
3- The View was so fragile that we ended up using raw HTML until we found a good solution

Now people come and say that only because they wrote a serializer and a validator you are copying things is weird.
My old company could easily prove them that SF2 copied their ZF1 application, and then we could start a cat and mouse hunting.
Also, Kyle and I have already updated most of the API he drafted, if that is any final mention. It was even before Fabien starts pointing fingers.

Anyway, my personal feeling is that ZF2 could share components with community by using SF2 ones, Doctrine ones, etc, but that's not the case we are talking here.


Sorry for my deliberately exclamation here. My comments are inline.

On Mon, Feb 27, 2012 at 3:31 PM, Matthew Weier O'Phinney <[hidden email]> wrote:
-- [hidden email] <[hidden email]> wrote
(on Monday, 27 February 2012, 12:36 PM -0500):
> On Mon, Feb 27, 2012 at 10:42 AM, Kyle S <[hidden email]> wrote:
>         The fourth change is about unique responsibilities. Passing the
>         $formType to view for rendering is far from ideal, specially because
>         you would be including rendering logic on a class that was supposed to
>         only deal with form elements mapping (not rendering). Ideally, you
>         delegate this rendering responsibility to an auxiliar class, like a
>         FormRenderer or FormView, whatever you want to name it. This class
>         would then know how to render the form.
>         Inside of Controller, you just $formType->createView() or $formType->
>         createRenderer().
>
>     I thought the idea was for view helpers to do the rendering of a form.
>
> It still is. But how each item is going to recognize what and how it
> needs to be printed is a task of FormView.  The View Helper just
> print/gorup individual sets of items from FormView and render using
> the assigned Decorators. This means the decorators are part of
> FormView, and not View Helpers.
>
> I can foresee some view helpers: form, form_errors, form_element,
> form_element_label, form_element_field, form_element_error
>
> How they are going to know what should be rendered and with which
> decorator is a task of FormView, not the Form View Helper.

Umm... I never proposed a "FormView". I proposed, in the RFC, that we
move rendering to the appropriate location -- the view layer -- and
proposed we pass the various form objects (elements, groups, what have
you) individually to view helpers in order to create markup.

Thus, "decoration" would occur in the view helpers, typically by having
a helper that aggregates output from several helpers (potentially
contributing additional markup). The specific example I provided in the
RFC is of the "WrappedElement" view helper.

In your paragraph above, you indicate you think this makes for unclear
responsibilities. However, the idea here is that the elements and
whatnot are basically value objects, and the helpers are simply pulling
information from them in order to create markup. I'm unclear how this is
an unclear separation of responsibilities, to be honest.


View Helpers would consume FormView elements in order to grab Decorators + Form Elements to be rendered.
 
Could you please elaborate on your ideas? I'm curious if they differ
that much from what I propose in the RFC, or how people want to interact
with forms at the view level.


Let me try to be more specific.
We have drafted the FormDefinition, the one responsible to map a Form. The unique responsibility of this class is a connector between a FormModel and a FormBuilder (the one that contains available element types).

By mentioning non-atomic responsibilities, I wanted to highlight you how a FormBuilder could process a FormDefinition, generating a Traversable list of elements to be rendered, with attributes and decorator pointers; the View Helper would then just grab a referred FormDecorator or FormElementDecorator and render by applying the attributes, label and extra options.
Please pay attention how different it is from having a unique class FormDefinition. The FormDefinition is a Mapper between the Model and the View. It is not Traversable (this is an important note).
By Traversable I wanted to tell you could iterate through the Form Elements, and with a single RecursiveIteratorIterator (your Form View Helper) you could print the Form smoothly. Also, FormView could even implement Countable to count the amount of Form Elements. Finally, the FormView is a result of what are the decorator subscribed, which one you should use and what should be rendered (attributed, labels, select options, extra data).

My idea come from a very simple concept. You may want to have multiple Decorators in your application, but you still want to render same form using the different ones. You should be capable of doing it by consuming like this:

class AuthenticationController
{
    public function loginAction()
    {
        $formService = $this->getLocator()->getService('form');
        $loginFormDefinition = $formService->getForm('login-form');

        return new ViewModel(array(
            'form' => $loginFormDefinition->createView('compact-decorator-style')
        ));
    }
}

So, FormView would not only hold the Form Elements already processed from FormBuilder, but also would point to which decorator are you looking for to be displayed.

Does it make sense now?



Cheers,

--
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



--
Guilherme Blanco
MSN: [hidden email]
GTalk: guilhermeblanco
Toronto - ON/Canada
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Andreas Möller
> Does it make sense now?

+1.

I like the concept of decoupling decorators - which I never understood
in the first place (as I *had* understood that with a list of
decorators, the output of one would be the input of another, which
isn't the case for ZF1 - thanks for pointing out that the *Visitor*
pattern is implemented, actually, Matthew) - from the form object.

In recent projects, I had come the point where I would have a
validation service object, which was injected an array of options (a
map of model names and contexts to names of form classes) and which
was bootstrapped much like the CacheManager but within the context of
a ServiceLocator (which is boostrapped as a reusable application
resource). Using an action helper, the service locator could be
accessed in the controller action, and from the service locator, the
validation service could be pulled. From the validation service, I
could retrieve a form, while specifying the name of a model and the
context in which I intend to use the form (see my comment on the RFC).
 Basically, in the controller action I only retrieve the form to pass
it on to the view, while I check whether it's an Ajax or a post
request, and if so, I pass on the request parameters to a service
object (again pulled from the service locator) which should handle
(*process*) request parameters, i.e., validate the parameters, with
the aforementioned form pulled from the validation service, which
rather fulfills the function of being a container for filtering and
validating, with possible error messages attached, while the rendering
actually should happen in the view.

I have do admit, though, that I prefer to use the ViewScript
decorator, as this is the easiest to understand and as I believe it's
got the least overhead.

For example, if I just need the form - in whichever way - to validate
Ajax request parameters, I don't see much sense in fully attaching
decorators.

I love (!) the annotation idea! Something that came to my mind when
first switching from Doctrine1 to Doctrine2, but I was to lazy to
figure out how to do, but would have figured out otherwise with a form
builder, that pulls out meta data indirectly and automagically
attempts to map column/property types against form element types and
caches forms.

Great job, guys!


Best regards,

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Stewart Lord
In reply to this post by weierophinney
On 2/27/12 12:31 PM, Matthew Weier O'Phinney wrote:
> Thus, "decoration" would occur in the view helpers, typically by having
> a helper that aggregates output from several helpers (potentially
> contributing additional markup). The specific example I provided in the
> RFC is of the "WrappedElement" view helper.

+1 for removing decorators and replacing them with view helpers. Many of
the form decorators today just wrap view helpers anyway. Although, we
should retain the ability to render an entire form with a single call.

As part of re-doing form rendering, can we eliminate the ID attributes?
One of the problems with forms in ZF1 is that it puts IDs on every DOM
node it outputs. This causes collisions when you have multiple forms on
a single page or if you load and reload forms via XHR.

Stew




>
> In your paragraph above, you indicate you think this makes for unclear
> responsibilities. However, the idea here is that the elements and
> whatnot are basically value objects, and the helpers are simply pulling
> information from them in order to create markup. I'm unclear how this is
> an unclear separation of responsibilities, to be honest.
>
> Could you please elaborate on your ideas? I'm curious if they differ
> that much from what I propose in the RFC, or how people want to interact
> with forms at the view level.
>

Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Andreas Möller
> Many of the form decorators today just wrap view helpers anyway.

Exactly.

> Although, we should retain the ability to render an entire form with a single call.

+1.

> As part of re-doing form rendering, can we eliminate the ID attributes? One of the problems with forms in ZF1 is that it puts IDs on every DOM node it outputs. This causes collisions when you have multiple forms on a single page or if you load and reload forms via XHR.

As far as I know, it doesn't for a form. You have to explicitly set
the id of the form.

However, this might have changed since the last time I looked.


Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Frank Brückner
In reply to this post by weierophinney
On 2/28/2012 9:00 AM, Stewart Lord wrote:
> As part of re-doing form rendering, can we eliminate the ID attributes?
> One of the problems with forms in ZF1 is that it puts IDs on every DOM
> node it outputs. This causes collisions when you have multiple forms ona  
> single page or if you load and reload forms via XHR.

This is a bad idea if you use the label element:

<label for="myId">Foo:</label>
<input type="text" name="foo" id="myId"/>

The id is needed to associate the label to the input element.

HTML 4.01 Specification - 17 Forms - 17.9.1: The LABEL element
http://www.w3.org/TR/html4/interact/forms.html#adef-for
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Frank Brückner
In reply to this post by weierophinney

 On 2/28/12 09:00 AM, Stewart Lord wrote:
> As part of re-doing form rendering, can we eliminate the ID
> attributes?
> One of the problems with forms in ZF1 is that it puts IDs on every
> DOM
> node it outputs.

 The is a bad idea if you use the label element for your inputs:

 <label for="myId">Foo:</label>
 <input type="text" name="foo" id="myId"/>

 The id is needed to associate the label to the input element.

 HTML 4.01 Specification - 17 Forms - 17.9.1 The LABEL element:
 http://www.w3.org/TR/html4/interact/forms.html#adef-for

Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Stewart Lord
In reply to this post by Frank Brückner
That's a good point. Forms should limit their use of IDs to those cases
where it is necessary. To mitigate collisions, it would be helpful if
there was a way to set a id prefix or suffix.

Stew


On 12-02-28 12:46 AM, Frank Brückner wrote:

> On 2/28/2012 9:00 AM, Stewart Lord wrote:
>> As part of re-doing form rendering, can we eliminate the ID
>> attributes?One of the problems with forms in ZF1 is that it puts IDs
>> on every DOMnode it outputs. This causes collisions when you have
>> multiple forms ona single page or if you load and reload forms via XHR.
>
> This is a bad idea if you use the label element:
>
> <label for="myId">Foo:</label>
> <input type="text" name="foo" id="myId"/>
>
> The id is needed to associate the label to the input element.
>
> HTML 4.01 Specification - 17 Forms - 17.9.1: The LABEL element
> http://www.w3.org/TR/html4/interact/forms.html#adef-for
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

BullfrogBlues
In reply to this post by Frank Brückner

I understand your issue, but removing id's is not the solution. They should be form specific so as not to introduce conflicts, e.g.

$id = get_class($this) . '-your-element-id';

I'd also like to note that maybe there should be css coding standards; dashes or underscore, etc.

Also, hidden elements should all have a "hidden" class i.e. class="hidden", which allows you to remove those nasty "<dt>&nbsp;</dt>" elements with a universal css declaration:

.hidden {
     display: none;
     }

Regards,

Gerard




> To: [hidden email]

> Date: Tue, 28 Feb 2012 10:59:19 +0100
> From: [hidden email]
> Subject: [zf-contributors] Re: Forms RFC now up
>
>
> On 2/28/12 09:00 AM, Stewart Lord wrote:
> > As part of re-doing form rendering, can we eliminate the ID
> > attributes?
> > One of the problems with forms in ZF1 is that it puts IDs on every
> > DOM
> > node it outputs.
>
> The is a bad idea if you use the label element for your inputs:
>
> <label for="myId">Foo:</label>
> <input type="text" name="foo" id="myId"/>
>
> The id is needed to associate the label to the input element.
>
> HTML 4.01 Specification - 17 Forms - 17.9.1 The LABEL element:
> http://www.w3.org/TR/html4/interact/forms.html#adef-for
>
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Stewart Lord
 > I understand your issue, but removing id's is not the solution. They
 > should be form specific so as not to introduce conflicts, e.g.

That would help, but not entirely resolve the issue. We have situations
where the same form appears multiple times in the same DOM (particularly
when using XHR).

The solution that we came up with was to provide a ID prefix facility.
This allows the caller to pass in something to make the IDs unique. In
the case of XHR, we can query the DOM first and/or increment a counter
before fetching the form passing the prefix.

That said, I would maintain that we should remove ids from dom nodes
that don't need them. In my experience using classes makes forms easier
to style and query/manipulate via JS.

Stew



On 12-02-28 4:21 PM, Gerard - wrote:

>
> I understand your issue, but removing id's is not the solution. They
> should be form specific so as not to introduce conflicts, e.g.
>
> $id = get_class($this) . '-your-element-id';
>
> I'd also like to note that maybe there should be css coding standards;
> dashes or underscore, etc.
>
> Also, hidden elements should all have a "hidden" class i.e.
> class="hidden", which allows you to remove those nasty "<dt>&nbsp;</dt>"
> elements with a universal css declaration:
>
> .hidden {
> display: none;
> }
>
> Regards,
>
> Gerard
>
>
>
>  > To: [hidden email]
>  > Date: Tue, 28 Feb 2012 10:59:19 +0100
>  > From: [hidden email]
>  > Subject: [zf-contributors] Re: Forms RFC now up
>  >
>  >
>  > On 2/28/12 09:00 AM, Stewart Lord wrote:
>  > > As part of re-doing form rendering, can we eliminate the ID
>  > > attributes?
>  > > One of the problems with forms in ZF1 is that it puts IDs on every
>  > > DOM
>  > > node it outputs.
>  >
>  > The is a bad idea if you use the label element for your inputs:
>  >
>  > <label for="myId">Foo:</label>
>  > <input type="text" name="foo" id="myId"/>
>  >
>  > The id is needed to associate the label to the input element.
>  >
>  > HTML 4.01 Specification - 17 Forms - 17.9.1 The LABEL element:
>  > http://www.w3.org/TR/html4/interact/forms.html#adef-for
>  >
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

papayasoft
>> The solution that we came up with was to provide a ID prefix facility.
>> This allows the caller to pass in something to make the IDs unique. In
>> the case of XHR, we can query the DOM first and/or increment a counter
>> before fetching the form passing the prefix.

+1 for a prefix facility.

Each PHP form class could have its own default prefix, but I'd be
uncomfortable leaking the PHP class name into the client-side DOM.
Still, as long as it is overridable, then it strikes me as flexible
enough to accommodate most use-cases.

-----------------------

David Weinraub
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Andreas Möller
In reply to this post by Stewart Lord
> That would help, but not entirely resolve the issue. We have situations where the same form appears multiple times in the same DOM (particularly when using XHR).

But, if it serves a different purpose, it's *not* the same form. If it
serves the same purpose, there's no need for the form to appear twice
in the DOM.

It seems like you're trying to solve a problem that has a different cause.


Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

BullfrogBlues
In reply to this post by Stewart Lord


> Date: Tue, 28 Feb 2012 17:03:06 -0800
> From: [hidden email]
> To: [hidden email]
> CC: [hidden email]
> Subject: Re: [zf-contributors] Re: Forms RFC now up
>
> That said, I would maintain that we should remove ids from dom nodes
> that don't need them. In my experience using classes makes forms easier
> to style and query/manipulate via JS.

I agree that there should be no classes or id's unless required, but as far as I understand an id on the element is required by a label.

http://www.w3schools.com/tags/tag_label.asp
http://www.w3schools.com/html5/tag_label.asp

Gerard
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Andreas Möller
> I agree that there should be no classes or id's unless required, but as far as I understand an id on the element is required by a label.
>
> http://www.w3schools.com/tags/tag_label.asp
> http://www.w3schools.com/html5/tag_label.asp

Hence, they are required, especially in the light of accessibility -
unless it's preferred to create a less accessible application.


Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Stewart Lord
In reply to this post by Andreas Möller
 > If it serves the same purpose, there's no need for the form to appear
 > twice in the DOM.

Perhaps it's not a problem you have encountered, but I run into it with
some regularity. Imagine I have a form to edit widgets, and I can have
one or more widget forms open at the same time...

I would add that, at least in ZF1, it doesn't have to be the same form
to have collisions, just the same element name.

Having a generic id-prefix feature would allow for a sensible default
behavior of prefixing the form-name or class-name, as well as providing
arbitrary prefixes in the event that the same form needs to appear twice.

Regards,
Stew


On 2/28/12 8:00 PM, Andreas Möller wrote:

>> That would help, but not entirely resolve the issue. We have situations where the same form appears multiple times in the same DOM (particularly when using XHR).
>
> But, if it serves a different purpose, it's *not* the same form. If it
> serves the same purpose, there's no need for the form to appear twice
> in the DOM.
>
> It seems like you're trying to solve a problem that has a different cause.
>
>
> Andreas

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
> Perhaps it's not a problem you have encountered, but I run into it with
> some regularity. Imagine I have a form to edit widgets, and I can have
> one or more widget forms open at the same time...

Yes, but you don't edit the same (!) widget, do you? Therefore, it
shouldn't be the same form.

Compare with a form that allows adding a comment to a post on Facebook.

> I would add that, at least in ZF1, it doesn't have to be the same form
> to have collisions, just the same element name.

> Having a generic id-prefix feature would allow for a sensible default
> behavior of prefixing the form-name or class-name, as well as providing
> arbitrary prefixes in the event that the same form needs to appear twice.

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.


Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Stewart Lord
On 2/28/12 10:13 PM, Andreas Möller wrote:
> Yes, but you don't edit the same (!) widget, do you? Therefore, it
> shouldn't be the same form.

It would be the same form class though and that is enough to cause
collisions.

> 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.

Stew
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Andreas Möller
> 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?

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.

>> 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.

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).


Best regards,

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

weierophinney
Administrator
In reply to this post by papayasoft
-- David Weinraub <[hidden email]> wrote
(on Wednesday, 29 February 2012, 09:48 AM +0700):
> >>The solution that we came up with was to provide a ID prefix facility.
> >>This allows the caller to pass in something to make the IDs unique. In
> >>the case of XHR, we can query the DOM first and/or increment a counter
> >>before fetching the form passing the prefix.
>
> +1 for a prefix facility.
>
> Each PHP form class could have its own default prefix, but I'd be
> uncomfortable leaking the PHP class name into the client-side DOM.

I believe he was referring to CSS classes here, actually.

> Still, as long as it is overridable, then it strikes me as flexible
> enough to accommodate most use-cases.

--
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

weierophinney
Administrator
In reply to this post by Andreas Möller
-- 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
Reply | Threaded
Open this post in threaded view
|

Re: Forms RFC now up

Derek Miranda
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.


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

123