Bertrand Delacretaz wrote:
Le 7 nov. 05, à 02:05, Ezkovich Glen a écrit :
...An alternative naming would be along the lines of foo.bar.cf_input. While not following the more general convention it comes close. (I'm sure someone will confuse it for a column name ;-).)

While there remains clutter it is significantly reduced to 3 characters per id. A minimal amount considering the clarity it brings...

Same feeling here,

  foo.bar.cf_input

Looks more obvious than the punctuation-based proposals, and the increase in ID lengh is only 3 chars. I think punctuation-based rules are too easy to miss when reading the generated code (to debug it at 3AM ;-)

-1: this doesn't avoid conflicts with wiget names, which is the primary goal of this discussion.

Although it avoids the problem for fields that don't have child widgets, the problem remains for containers.

Let's consider for example a form for a digicam description. The app developer decides to use the "cf_" prefix for everything related to CompactFlash storage. He thus adds a "cf_size" field for the storage capacity.

He then puts this information in a group with a fancy styling that allows users to resize panels, and thus generates a "cf_size" element to handle the client-side interaction.

Bang! You have a name conflict! And that one is much more difficult to understand at 3AM as it impacts the definition of the form itself, and only appears with a special combination of widget and styling.

The initial "foo.bar:input" proposal *structucally* prevents name conflicts. They can *never* happen, whatever name you give to widgets and whatever styling you put around them. The only weak point of this proposal is ID selectors in CSS because of IE. Now we've seen in the discussion that it's a bad practice anyway as it links the CSS to the form model, and that changing the form model then not only requires to change the template, but also the CSS.

So I kindly ask people to carefully read and understand the rationale and motivation behind ':'.

Sylvain

--
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

Reply via email to