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.
