cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Date Fri, 04 Nov 2005 14:36:13 GMT
Joerg Heinicke wrote:
> Sylvain Wallez <sylvain <at>> 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 id="news">
    Here comes a periodically updated news feed
  <ft:form-template id="sheet">
    <ft:widget id="name"/>
    <ft:repeater id="phones">
        Phone numbers:
              <ft:widget id="type"/> <ft:widget id="number"/>

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:

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.

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. 



Sylvain Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

View raw message