[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:       Antonio Gallardo <agallardo () agssa ! net>
Date:       2005-11-04 17:04:16
Message-ID: 436B9490.3050701 () agssa ! net
[Download RAW message or body]

Sylvain Wallez wrote:

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


Happens to be that the 1 of the 4 tested, the IE is btw, the one with 
more than 90% of the market share! :-)

Reading the above, I realized it directly affect the cocoon learning 
curve. If we imlement this way a cocoon newbie will need to know that 
when they want to code '\:' as '\3A'. I can see a lot of wasted hours 
dedicated to debug this. And this directly impact the overall user 
perception of cocoon.

Seems to be like "another brick" in the "cocoon learning" wall. ;-)

Is there another solution? I like AJAX. I want to have AJAX. I know your 
are a brilliant programmer. For this reason I am pretty sure you can 
come with a more elegant solution! :-)

WDYT?

Best Regards,

Antonio Gallardo.


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