AW: [Zope3-dev] Re: [Checkins] SVN: z3c.form/trunk/src/z3c/form/ HTMLelement ids containing dots are not very good, because then the

[Gary Poster]

On Jun 5, 2007, at 3:28 AM, Roger Ineichen wrote:

> Hi Stephan, Gary, Marius

Hey Roger

> Agreed, we can't use different names and ids!

Cool

> We can use camel bucket names instead of dots. This
> means we can convert each first letter of a prefix to a
> uper case letter. But the first letter should be lower case.
>
> This wil give us names and ids like:
>
> formWidgetsLastname
>
> rather then:
>
> form.widgets.lastname
>
> This should also work if somebody uses already a camel
> bucket name for lastName e.g.
>
> form.widgets.lastName /formWidgetsLastName
>
> because we do not need to resolve/split the prefix based on
> the formWidgetsLastName string base. We do only split such prefixed
> strings based on the prefix parts itself.
>
> But another question is, why do we use additional dots or
> someting else between prefixes? I guess we should skip it and
> just append each prefix. This alloes us to use the pattern above
> as well by choosing our own camel bucket names if needed.
>
> Any reason for using dot prefix for our prefixes? If not
> I propose to skip the additional dots which are only beautifiers.
>
> What do you think?

In the past we have wanted the dots to effectively guarantee page  
component "namespaces".  For instance, if a widget or viewlet or  
whatever wants to draw a few form fields, or a few uniquely  
addressable ids, then it needs to know that what pattern is safe to  
use.  since our field names are Python and dots are natural  
delimiters there, a dot could guarantee that we didn't have leakage.   
For instance, we do have Python packages with camelCase attribute  
names out there; if we used your camelCase proposal, then there would  
be no way to distinguish between lastName--a field named 'lastName'-- 
and lastName--a field named last with a widget that wants to draw a  
separately addressable HTML part of "name".

Gary