Jason Johnston wrote:
On Mon, 2005-06-13 at 17:02 +0200, Sylvain Wallez wrote:
Hi all,
As part of the stabilization work on CForms, there are a couple of
changes I'd like to do on the naming-related methods of the Widget
interface.
Today we have:
- getId() which returns the local name of widget.
- getRequestParameterName() which returns the combination of the parent
widgdet's requestParameterName with the local name.
Working with advanced templates and Ajax stuff, I find these names
increasingly annoying and confusing:
- each widget produces an HTML element with an "id" attribute filled
with getRequestParameterName(), and not getId()!
The HTML element is also given a "name" attribute with the same value,
which is what is actually used as the parameter name when the form is
submitted. As far as the HTML form is concerned (don't know about your
Ajax work) the id attribute on the HTML element is meaningless.
Right, but CForms produces more @id's than @name's :-)
The result of getRequestParameterName() is used:
- for input/@name
- for @id of either the input or an enclosing element (for partial Ajax
updates)
- for @id of HTML elements corresponding to container widgets (also for
Ajax)
The real problem is that writing <div id="${widget.id}"> for a container
in a template is faulty as it doesn't consider upper-level containers,
and should be written <div id="${widget.fullRequestParameterName}">.
That's this pitfall I'd like to fix with this renaming.
An notice that when mixing such div's with ft:widget, this gets even worse:
<div id="${widget.fullRequestParameterName}">
<ft:widget id="foo"/>
</div>
Where the @id on ft:widget really is the local name...
So what I'd like in this end is:
<div id="${widget.id}">
<ft:widget name="foo"/>
</div>
Meaning when you see "id" it's a full id in the DTD meaning of it, and
when you see "name" on a ft:* tag it's a local name within the current
container widget (not talking about html @name's what we actually never
see in templates).
- this getRequestParameterName is really tooooo long to type, especially
in templates where we have no IDE autocompletion.
Ideally, I'd like to do the following renaming:
- getId() --> getName()
- getRequestParameterName() --> getId()
But since the meaning of getId() changes, this is likely to cause weird
things in existing code.
So I propose the following:
- getId() --> getName()
So now the method name no longer matches the form definition:
<fd:field id="theIdOfTheWidget">
^^
Yeah, I'd like to change that one also, as this id attribute isn't a
real id in the DTD meaning of it, as different widgets in different
containers can have the same name, e.g:
<fd:repeater id="foo">
<fd:widgets>
<fd:field id="duplicate"/>
</fd:widgets>
</fd:repeater>
<fd:repeater id="bar">
<fd:widgets>
<fd:field id="duplicate"/>
</fd:widgets>
</fd:repeater>
However, such a renaming causes no problem as there's no semantic change
on an existing notation (like what I'd like to do on getId()), and thus
can live in "compatibility mode" for a long time.
So now we use getName() to get the value of the id attribute? This
seems to me like you're causing a greater asymmetry in an attempt to
solve a lesser one.
With the renaming of the "id" attribute to "name", we achieve an
increased global consistency.
- getRequestParameterName() --> getFullId()
Since it seems you're wanting to tie this method more closely to the
widget's HTML styling, what about just getName()? That would match the
HTML element's 'name' attribute which is what gets sent in the request
anyway.
No, as "name" is the local name which has to be unique among siblings,
but need not to be globally unique.
- deprecate and remove later getId() and getRequestParameterName().
Once getId() will have been removed for some time, we'll be able to
reintroduce it as an equivalent to getFullId().
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
