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

List:       xml-cocoon-dev
Subject:    Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
From:       Sylvain Wallez <sylvain () apache ! org>
Date:       2005-11-04 9:30:41
Message-ID: 436B2A41.3020409 () apache ! org
[Download RAW message or body]

Antonio Gallardo wrote:
> Joerg Heinicke wrote:
>
>> On 04.11.2005 02:09, Antonio Gallardo wrote:
>>
>>>> Yep. The "." and "/" are already checked in 
>>>> AbstractWidgetDefinition.setCommonProperties(). We just need to add 
>>>> ":".
>>>
>>> Why we need to use a symbol at any cost ? Can we use a simple word 
>>> prefix? As cform-[widgetID]?
>>
>> If you prefix the widget id with a simple word (your proposal) or 
>> suffix it with another one (Sylvain's way), with both you have to 
>> care about the validness of user-chosen ids. To check them easily you 
>> use the unique separator.
>
>
> Agreed. I think checking a prefix is often faster than checking a 
> suffix in a string. On the other side a prefix can rest code 
> readibility. IMHO, the first is better for generated (X)HTML code.
>
> The suffix is also ok. The problem was that a "-input" suffix is too 
> generic and seems to broke some javascript code somewhere. ajax is the 
> main reason for change? If yes, then we can use "-cf-input" as the 
> suffix or something like that.

You missed the essence of the problem: if you add a suffix that makes 
the generated id a valid widget name, then you have the possibility for 
someone to write a form definition where there is a widget that has the 
same name than the generated id, then leading to conflicts in the page. 
That's why I proposed a character that isn't allowed in widget names. 
That way, there is *no* possibility for conflicting ids.

> I am just afraid of adding a ":" in the name. Maybe does not make 
> sense. Here are some points:
>
> 1-It can breaks compatibility somewhere. As sample, all browsers 
> claims to support CSS standards. The point is at wich level and how 
> they interpret the word "support".

The ":" has been a valid character for ID in HTML and XML for years:
- http://www.w3.org/TR/REC-html40/types.html#type-id
- http://www.w3.org/TR/REC-xml/#id

The CSS specification says how to use '\' to escape special characters:
- http://www.w3.org/TR/REC-CSS2/syndata.html#q4

So writing a CSS rule for the input of widget "foo" should be 
"#foo\:input { .... }"

However, f*cking IE goes in the way, and although it properly escapes 
'.' (used for container widgets), it is the only one among the 4 
browsers I tested that doesn't understand '\:'. That means that the 
'\3A' unicode escape sequence must be used.

To test thoroughly with containers and Ajax, I added the following to 
datasource_chooser_template.xml:
  <style type="text/css">
    #name { background: #00FF00 }
    #name\3Ainput { background: #FF0000 }
    #datasource\.SQL\.login { background: #00FF00 }
    #datasource\.SQL\.login\3Ainput { background: #FF0000 }
  </style>

This works in IE 6, Firefox 1.5rc1, Safari 2.0, Opera 8.5.

I also added
  <a href="#" 
onclick="document.getElementById('datasource.SQL.login:input').value = 
'Yeah'; return false">Yeah</a>

Works like a charm in all tested browsers.

Now the question is: do you find the \3A quirk to be a blocking issue?

It seems to me that more often inputs in a form will be styled using 
classes, so as all inputs share the same styling rule. Also, a way to 
avoid the quirk is to use the ancestor selector, which works in all 
tested browsers:
  #datasource\.SQL\.login input { background: #FF0000 }

> 2-Being in a xpath 1.0 namespace nightmare for months. I am not sure 
> if suddenly somebody will need to give a meaning to the ":". I know it 
> is very remote, but...

There's no XPath construct that expects an ID as a litteral. They're 
always used as string: foo[@id="bar:baz"] or id("bar:baz")

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]