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
