You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Andreas Hochsteger <e9...@student.tuwien.ac.at> on 2005/11/03 10:14:25 UTC
CForms widget ID naming (was Re: [Vote] Releasing on friday)
(I think this should be discussed in a separate thread)
Sylvain Wallez wrote:
> The last minute change is just about replacing "-input" with ":input"
> within two XSLs, to avoid problems later.
Isn't ":" used as separator for the namespace prefix?
I don't know if this applies to IDs too, but perhaps we should
double-check before.
If it is allowed by the XML spec, it makes me wonder, if we want to
prefix the IDs some time in the future to use some kind of "namespace"
here too?
Wouldn't this conflict with ":input" as you then cannot distinguish
between the two anymore (namespace prefix vs. ":input" suffix).
Just some random thoughts ...
Perhaps it would help to write something up which summarizes all the
IDs, names, prefixes, suffixes and namespaces involved in every part of
CForms.
Andreas.
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Bruno Dumon <br...@outerthought.org>.
On Sat, 2005-11-05 at 11:20 +0100, Ugo Cei wrote:
> Il giorno 05/nov/05, alle ore 08:46, Sylvain Wallez ha scritto:
>
> >> So let's make other proposals. Let's consider wiget
> >> "foo.bar" (e.g. a fd:field in a fd:group) and the ID of its <input>.
> >> - "foo.bar..input": the '.' is doubled, which can never conflict
> >> with a widget's full name
> >> - "foo.bar._input": generated element's name starts with a
> >> character that we can forbid as the first character of widget names
> >>
> >> I prefer the first one (double '.') which is IMO more readable
> >> than the second.
> >
> > Another one, which looks more natural: "foo.bar.input.": the
> > trailing '.' ensures it cannot conflict with a widget's full name
>
> The fact that it is not that readable might be a plus. The problem
> with double dots or a dot at the end is that it's easy to miss when
> reading the code. an extra '_' sticks out more and won't be missed as
> easily.
agreed, +1 for the underscore
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 05/nov/05, alle ore 08:46, Sylvain Wallez ha scritto:
>> So let's make other proposals. Let's consider wiget
>> "foo.bar" (e.g. a fd:field in a fd:group) and the ID of its <input>.
>> - "foo.bar..input": the '.' is doubled, which can never conflict
>> with a widget's full name
>> - "foo.bar._input": generated element's name starts with a
>> character that we can forbid as the first character of widget names
>>
>> I prefer the first one (double '.') which is IMO more readable
>> than the second.
>
> Another one, which looks more natural: "foo.bar.input.": the
> trailing '.' ensures it cannot conflict with a widget's full name
The fact that it is not that readable might be a plus. The problem
with double dots or a dot at the end is that it's easy to miss when
reading the code. an extra '_' sticks out more and won't be missed as
easily.
Ugo
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.11.2005 08:46, Sylvain Wallez wrote:
>> So let's make other proposals. Let's consider wiget "foo.bar" (e.g. a
>> fd:field in a fd:group) and the ID of its <input>.
>> - "foo.bar..input": the '.' is doubled, which can never conflict with
>> a widget's full name
>> - "foo.bar._input": generated element's name starts with a character
>> that we can forbid as the first character of widget names
>>
>> I prefer the first one (double '.') which is IMO more readable than
>> the second.
>
> Another one, which looks more natural: "foo.bar.input.": the trailing
> '.' ensures it cannot conflict with a widget's full name
I definitely prefer the ones which can not conflict with other widget's
full name instead of forbidding another character. Your last proposal
with trailing dot is the one I like most.
Jörg
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Sylvain Wallez wrote:
>> So let's make other proposals. Let's consider wiget "foo.bar" (e.g. a
>> fd:field in a fd:group) and the ID of its <input>.
>> - "foo.bar..input": the '.' is doubled, which can never conflict with
>> a widget's full name
>> - "foo.bar._input": generated element's name starts with a character
>> that we can forbid as the first character of widget names
>>
>> I prefer the first one (double '.') which is IMO more readable than
>> the second.
>
> Another one, which looks more natural: "foo.bar.input.": the trailing
> '.' ensures it cannot conflict with a widget's full name
>>
>> Other ideas?
>>
>> Let's make a choice and have 2.1.8 out!
For me the solution with a leading '_' seems more natural, since it is
easier to distinguish from other IDs (imagine user posts which describe
their problems and miss the trailing '.') and it has the common semantic
of an 'internal thing', like private variables are often named after
(e.g. C/C++ and other languages).
Andreas
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 5 nov. 05, à 08:46, Sylvain Wallez a écrit :
> ...Another one, which looks more natural: "foo.bar.input.": the
> trailing '.' ensures it cannot conflict with a widget's full name...
I also like this option better.
-Bertrand
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> Antonio Gallardo wrote:
>> Sylvain Wallez wrote:
>>> 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. ;-)
>
> Ok. Even if I don't think these CSS rules will be used often, you're
> right that the IE quirk will go in the way of people.
>
> Let's recap the various aspects of the problem:
> - generated IDs should not be valid widget full names, to avoid any
> potential conflict,
> - this isn't just about the <input>, but about a common rule for all
> generated IDs - an HTML ID can contain letters, digits, underscores
> '_', colons ':' and periods '.'.
> - because of lookup paths, a widget ID cannot contain '/' nor '.'.
> Libraries also add ':' to the forbidden characters.
>
> Since '.' is used as the combination character to build full names, I
> thought ':' was a good choice. Now it leads to some (unjustified)
> fears about namespace prefixes, and requires a weird CSS syntax.
>
> A thing that wasn't formally said up to now is that a widget name
> *must* be a valid HTML/XML identifier. XML is more permissive as it
> allows (letter | '_' | ':') as the first character, whereas HTML
> requires the first character to be a letter. So a widget name *must*
> start with a letter (top-level ones, actually).
>
> So let's make other proposals. Let's consider wiget "foo.bar" (e.g. a
> fd:field in a fd:group) and the ID of its <input>.
> - "foo.bar..input": the '.' is doubled, which can never conflict with
> a widget's full name
> - "foo.bar._input": generated element's name starts with a character
> that we can forbid as the first character of widget names
>
> I prefer the first one (double '.') which is IMO more readable than
> the second.
Another one, which looks more natural: "foo.bar.input.": the trailing
'.' ensures it cannot conflict with a widget's full name
>
> Other ideas?
>
> Let's make a choice and have 2.1.8 out!
>
>> 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! :-)
>
> Well, as I said in my answer to Jörg, my guess is that Ajax will lead
> people to use CSS rules with classes rather than IDs. But I made other
> proposals above, so let's choose one.
>
> Sylvain
>
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Other ID naming proposals (was Re: CForms widget ID naming)
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
> Sylvain Wallez wrote:
>> 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. ;-)
Ok. Even if I don't think these CSS rules will be used often, you're
right that the IE quirk will go in the way of people.
Let's recap the various aspects of the problem:
- generated IDs should not be valid widget full names, to avoid any
potential conflict,
- this isn't just about the <input>, but about a common rule for all
generated IDs
- an HTML ID can contain letters, digits, underscores '_', colons ':'
and periods '.'.
- because of lookup paths, a widget ID cannot contain '/' nor '.'.
Libraries also add ':' to the forbidden characters.
Since '.' is used as the combination character to build full names, I
thought ':' was a good choice. Now it leads to some (unjustified) fears
about namespace prefixes, and requires a weird CSS syntax.
A thing that wasn't formally said up to now is that a widget name *must*
be a valid HTML/XML identifier. XML is more permissive as it allows
(letter | '_' | ':') as the first character, whereas HTML requires the
first character to be a letter. So a widget name *must* start with a
letter (top-level ones, actually).
So let's make other proposals. Let's consider wiget "foo.bar" (e.g. a
fd:field in a fd:group) and the ID of its <input>.
- "foo.bar..input": the '.' is doubled, which can never conflict with a
widget's full name
- "foo.bar._input": generated element's name starts with a character
that we can forbid as the first character of widget names
I prefer the first one (double '.') which is IMO more readable than the
second.
Other ideas?
Let's make a choice and have 2.1.8 out!
> 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! :-)
Well, as I said in my answer to Jörg, my guess is that Ajax will lead
people to use CSS rules with classes rather than IDs. But I made other
proposals above, so let's choose one.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Antonio Gallardo <ag...@agssa.net>.
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.
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 04.11.2005 15:36, Sylvain Wallez wrote:
>> Can't follow you? What do you have in mind?
>
> This is related to the Ajax BrowserUpdateTransformer:
Ok, convinced. Your explanation sounds reasonable.
Jörg
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
> Sylvain Wallez <sylvain <at> apache.org> writes:
>
>
>>> Sorry to go back to the origin of this discussion, but wouldn't it then be
>>> better to generate an id for the ajax wrapper element instead of the input
>>> element? Nobody cares about the wrapper element, but nearly everybody about
>>> the styling of the form and so the inputs. So giving them the id they have in
>>> the form definition seems to be more than obvious.
>>>
>> So you suggest:
>> <span id="foo:container"><input name="foo" id="foo"></span> ?
>>
> Yes.
>
>> Ajax cares *alot* about the container id, as it's the element that is
>> updated.
>>
>
> Of course it does, I did not question this. But the CForms user don't care about
> which id the container has.
>
>> If the container's id isn't the widget's full name, it means
>> we'll have to take into account this special naming for HTML rendering
>> of widgets everywhere
>>
>
> Can't follow you? What do you have in mind?
>
This is related to the Ajax BrowserUpdateTransformer: that means that
the template would have to produce <bu:replace id="foo:container">
instead of <bu:replace id="foo">, and thus migrates this ":container"
suffix concern higher in the framework, in places where we don't care of
the actual markup language produced, nor if there must be a distinction
between container elements and inputs.
Also, what about container widgets such as repeater and group ? Shoud
"<ft:repeater id="bar"><div>..." produce "<div id="bar:container">..."?
This definitely doesn't look good.
>> My impression (but that's only mine) is that access to individual inputs
>> is mostly needed from JS code (to plug some additional behaviour) rather
>> than from CSS (use classes to style globally rather than individually),
>> so the unicode escape quirk is should not really be an issue.
>>
>
> The manipulated input id might be a minor issue. But if it is possible to avoid
> the manipulation at all, we should do it. So you probably just need to explain
> why the container id should be the widget id for simplicity.
>
My concern is to have consistency in the ids of "refresheable" units in
a page. By "refresheable", I mean parts of the page that can be updated
using Ajax requests. My feeling is that more and more, application that
have some client-side behaviour will make heavy use of Ajax.
Consider e.g. the following:
<div id="content">
<div id="preview">
Here comes some preview of the current foobar
</div>
<div id="news">
Here comes a periodically updated news feed
</div>
<ft:form-template id="sheet">
<ft:widget id="name"/>
<ft:repeater id="phones">
<div>
Phone numbers:
<ul>
<ft:repeater-rows>
<li>
<ft:widget id="type"/> <ft:widget id="number"/>
</li>
</ft:repeater-rows>
</ul>
</div>
</ft:repeater>
</ft:form>
</div>
In this template, you can refresh (or animate) elements in a consistent
manner using the id, i.e. "preview", "news", "sheet.phones",
"sheet.phones.1" or "sheet.phones.1.number".
The ":input" suffix is visible if you want to access an input using its
id, because that would be "sheet.phones.1.number:input". But there's
another way, which is using its name in the form:
document.getElementById("sheet")['phones.1.number'].
So, by having the container element having the widget's id we have an
overall consistent naming for elements that are manipulated with Ajax,
whereas we use widget ids (or full names, actually) in the form's input
array to access the <input> elements.
There's still the unicode quirk for CSS, but as I said my feeling is
that classes will more often be used to style a group of inputs rather
than styling each input individually.
<future-thinking>
And this feeling is strengthened by the Ajax trend, where we are more
likely to see several instances of a single form definition inserted
dynamically in a page.
Let's consider CRUD applications: why should we have to go from the list
page to an edit page? We just have to open the edit form in place in the
list. And the user could even open several of these edit forms at the
same time!
In that case, we'll have to generate form IDs dynamically, but the input
_names_ in the form won't change. That means that CSS rules based on IDs
won't be applicable anyway (you'll have to use classes), and that it
will be easier to access inputs through the form, with some JS libraries
that abstract away the dynamic ID, e.g.
"AjaxForms.getForm(currentRow).inputs.foo".
</future-thinking>
Thoughts?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Joerg Heinicke <jo...@gmx.de>.
Sylvain Wallez <sylvain <at> apache.org> writes:
> > Sorry to go back to the origin of this discussion, but wouldn't it then be
> > better to generate an id for the ajax wrapper element instead of the input
> > element? Nobody cares about the wrapper element, but nearly everybody about
> > the styling of the form and so the inputs. So giving them the id they have in
> > the form definition seems to be more than obvious.
>
> So you suggest:
> <span id="foo:container"><input name="foo" id="foo"></span> ?
Yes.
> Ajax cares *alot* about the container id, as it's the element that is
> updated.
Of course it does, I did not question this. But the CForms user don't care about
which id the container has.
> If the container's id isn't the widget's full name, it means
> we'll have to take into account this special naming for HTML rendering
> of widgets everywhere
Can't follow you? What do you have in mind?
> My impression (but that's only mine) is that access to individual inputs
> is mostly needed from JS code (to plug some additional behaviour) rather
> than from CSS (use classes to style globally rather than individually),
> so the unicode escape quirk is should not really be an issue.
The manipulated input id might be a minor issue. But if it is possible to avoid
the manipulation at all, we should do it. So you probably just need to explain
why the container id should be the widget id for simplicity.
Jörg
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
> Sylvain Wallez <sylvain <at> apache.org> writes:
>
>> 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 }
>>
>
> Sorry to go back to the origin of this discussion, but wouldn't it then be
> better to generate an id for the ajax wrapper element instead of the input
> element? Nobody cares about the wrapper element, but nearly everybody about the
> styling of the form and so the inputs. So giving them the id they have in the
> form definition seems to be more than obvious.
>
So you suggest:
<span id="foo:container"><input name="foo" id="foo"></span> ?
Ajax cares *alot* about the container id, as it's the element that is
updated. If the container's id isn't the widget's full name, it means
we'll have to take into account this special naming for HTML rendering
of widgets everywhere
My impression (but that's only mine) is that access to individual inputs
is mostly needed from JS code (to plug some additional behaviour) rather
than from CSS (use classes to style globally rather than individually),
so the unicode escape quirk is should not really be an issue.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Joerg Heinicke <jo...@gmx.de>.
Sylvain Wallez <sylvain <at> apache.org> writes:
> 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 }
Sorry to go back to the origin of this discussion, but wouldn't it then be
better to generate an id for the ajax wrapper element instead of the input
element? Nobody cares about the wrapper element, but nearly everybody about the
styling of the form and so the inputs. So giving them the id they have in the
form definition seems to be more than obvious.
Jörg
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Sylvain Wallez <sy...@apache.org>.
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
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Antonio Gallardo <ag...@agssa.net>.
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.
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".
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...
For the records, I don't have any javascript that need to be reviewed if
we change this behavior. It is just a technical comment.
Best Regards,
Antonio Gallardo.
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Joerg Heinicke <jo...@gmx.de>.
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.
Jörg
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Antonio Gallardo <ag...@agssa.net>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
>>
>>> This usage in CForms has already been introduced by the recent
>>> library stuff, which associates prefixes to libraries, thus
>>> effectively forbidding the use of ":" in widget ids (otherwise you
>>> cannot differenciate between a widget name and a composite name that
>>> references a library widget).
>>>
>>> That is why I chose this character. The "/" and "." are also
>>> forbidden (used for lookup paths). The "." cannot be used as it is
>>> used to combine widget names in the generated IDs, and thus would
>>> lead to a similar problem as the current one: "-" can conflict with
>>> siblings, and "." can conflict with children.
>>>
>>>
>>
>> Do we already validate a widget id if it does not contain all of these
>> forbidden characters? If not, we really should check this and throw an
>> exception when the model is read. Early failing is better than
>> unpredictable results later on.
>>
>
>
> Yep. The "." and "/" are already checked in
> AbstractWidgetDefinition.setCommonProperties(). We just need to add ":".
>
> BTW, I'm ready to commit the updated stylesheets, which I tested on IE
> 6, Firefox and Safari.
Why we need to use a symbol at any cost ? Can we use a simple word
prefix? As cform-[widgetID]?
I was not on GT2005, but I hear a lot about conventions was there. I
think this is good. Then let's define a fixed prefix name for cforms
names, declare it as a "cocoon keyword".
KISS rules! ;-)
WDYT?
Best Regards,
Antonio Gallardo.
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>> Sylvain Wallez wrote:
>>
>>> This usage in CForms has already been introduced by the recent
>>> library stuff, which associates prefixes to libraries, thus
>>> effectively forbidding the use of ":" in widget ids (otherwise you
>>> cannot differenciate between a widget name and a composite name that
>>> references a library widget).
>>>
>>> That is why I chose this character. The "/" and "." are also
>>> forbidden (used for lookup paths). The "." cannot be used as it is
>>> used to combine widget names in the generated IDs, and thus would
>>> lead to a similar problem as the current one: "-" can conflict with
>>> siblings, and "." can conflict with children.
>>>
>>>
>> Do we already validate a widget id if it does not contain all of these
>> forbidden characters? If not, we really should check this and throw an
>> exception when the model is read. Early failing is better than
>> unpredictable results later on.
>>
>
> Yep. The "." and "/" are already checked in
> AbstractWidgetDefinition.setCommonProperties(). We just need to add ":".
>
> BTW, I'm ready to commit the updated stylesheets, which I tested on IE
> 6, Firefox and Safari.
Ok, changes committed.
Let's get this baby 2.1.8 out!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> This usage in CForms has already been introduced by the recent library
>> stuff, which associates prefixes to libraries, thus effectively
>> forbidding the use of ":" in widget ids (otherwise you cannot
>> differenciate between a widget name and a composite name that references
>> a library widget).
>>
>> That is why I chose this character. The "/" and "." are also forbidden
>> (used for lookup paths). The "." cannot be used as it is used to combine
>> widget names in the generated IDs, and thus would lead to a similar
>> problem as the current one: "-" can conflict with siblings, and "." can
>> conflict with children.
>>
>>
> Do we already validate a widget id if it does not contain all of these
> forbidden characters? If not, we really should check this and throw an
> exception when the model is read. Early failing is better than
> unpredictable results later on.
>
Yep. The "." and "/" are already checked in
AbstractWidgetDefinition.setCommonProperties(). We just need to add ":".
BTW, I'm ready to commit the updated stylesheets, which I tested on IE
6, Firefox and Safari.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> This usage in CForms has already been introduced by the recent library
> stuff, which associates prefixes to libraries, thus effectively
> forbidding the use of ":" in widget ids (otherwise you cannot
> differenciate between a widget name and a composite name that references
> a library widget).
>
> That is why I chose this character. The "/" and "." are also forbidden
> (used for lookup paths). The "." cannot be used as it is used to combine
> widget names in the generated IDs, and thus would lead to a similar
> problem as the current one: "-" can conflict with siblings, and "." can
> conflict with children.
>
Do we already validate a widget id if it does not contain all of these
forbidden characters? If not, we really should check this and throw an
exception when the model is read. Early failing is better than
unpredictable results later on.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Posted by Sylvain Wallez <sy...@apache.org>.
Andreas Hochsteger wrote:
> (I think this should be discussed in a separate thread)
>
> Sylvain Wallez wrote:
>
>> The last minute change is just about replacing "-input" with ":input"
>> within two XSLs, to avoid problems later.
>
> Isn't ":" used as separator for the namespace prefix?
> I don't know if this applies to IDs too, but perhaps we should
> double-check before.
The ":" is a valid character in element names and ID and IDREF
attributes (they are defined using the same grammar rule).
Parsers use the ":" in a special way for element names only, when
namespace processing is activated (the default in all modern browsers)
> If it is allowed by the XML spec, it makes me wonder, if we want to
> prefix the IDs some time in the future to use some kind of "namespace"
> here too.
This usage in CForms has already been introduced by the recent library
stuff, which associates prefixes to libraries, thus effectively
forbidding the use of ":" in widget ids (otherwise you cannot
differenciate between a widget name and a composite name that references
a library widget).
That is why I chose this character. The "/" and "." are also forbidden
(used for lookup paths). The "." cannot be used as it is used to combine
widget names in the generated IDs, and thus would lead to a similar
problem as the current one: "-" can conflict with siblings, and "." can
conflict with children.
So the choice is between "/" and ":", but "/" is not allowed in XML
names. Hence the result, ":"...
> Wouldn't this conflict with ":input" as you then cannot distinguish
> between the two anymore (namespace prefix vs. ":input" suffix).
No, because as I said above, using ":" in widget names is effectively
forbidden by the library prefix notation.
Another possibility is to prefix the name of generated-ids with ":"
(this is allowed by the XML spec), e.g. ":foo-input" instead of
"foo:input". But I prefer to keep the widget ID as the prefix of all
that is related to its styling.
The rule is then: a styling stylesheed can generate whatever ID its
needs for a widget by suffixing the widget's id with ":" followed by a
name. Care should be taken of course that this name doesn't conflict
with names produced by other stylesheets.
> Just some random thoughts ...
>
> Perhaps it would help to write something up which summarizes all the
> IDs, names, prefixes, suffixes and namespaces involved in every part
> of CForms.
Yup. That should be part of the documentation of the various stylings.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director