On Mon, 2005-06-13 at 23:31 +0200, Sylvain Wallez wrote:
> 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 :-)
At least in the HTML styling... no telling what future stylings will
produce. ;-)
> 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.
Ah, OK. The (important!) missing piece in your original message was
that this is a global change to methods *and* attributes, to achieve
more "correct" and convenient semantics. It sounded before like you
were just trying to match the methods to the styling, which rubbed me
wrong. :-)
Now that I understand your motives correctly, it makes sense. I think
your deprecation strategy is reasonable.
>
> >>- 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
>
