[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: [VOTE] Naming rule for HTML IDs generated by CForms
From:       Sylvain Wallez <sylvain () apache ! org>
Date:       2005-11-07 7:36:06
Message-ID: 436F03E6.709 () apache ! org
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]