You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2005/06/13 17:02:40 UTC
CForms: some renamings on the Widget interface
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()!
- 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()
- getRequestParameterName() --> getFullId()
- 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().
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms: some renamings on the Widget interface
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> 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()!
>> - 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()
>> - getRequestParameterName() --> getFullId()
>> - 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().
>
>
> +1
>
> In order to be consistent (and as already proposed from somebody else
> we change from <fd:widget id="foo"/> to <fd:widget name="foo"/>, right?
Yes. And as proposed by Ralph, that will be the better-looking
getFullName() instead of getFullId().
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms: some renamings on the Widget interface
Posted by Reinhard Poetz <re...@apache.org>.
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()!
> - 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()
> - getRequestParameterName() --> getFullId()
> - 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().
+1
In order to be consistent (and as already proposed from somebody else we change
from <fd:widget id="foo"/> to <fd:widget name="foo"/>, right?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: CForms: some renamings on the Widget interface
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
>
> A problem though: these names are good for methods, but what about
> attributes?
>
> <fd:field localName="bar"> leading to a <fi:field fullName="foo.bar">?
>
> Hmm... doesn't look that good...
>
> Sylvain
Very true. A name attribute on both would look better, but then you'd
need to be able to distinguish them. This all seems kind of arbitrary
and forced. I mean, it would be better if it was
<fd:field name="bar"> and <fi:field name="foo">
with getName() and getParent().getName(). getFullName() would then
return getName() + "." + getParent().getName().
but since apparently that can't be done I would settle on
<fd:field name="bar"> and <fi:field fullName="foo.bar">
and getName() and getFullName().
Re: CForms: some renamings on the Widget interface
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> Ralph Goers wrote:
>> I can see you're set on doing it this way say I'm not sure why I'm
>> posting. Well, yes I am....
>>
>> It would probably be easier for everyone if getId() just went away
>> never to be seen again. Just pick some other name that doesn't
>> conflict. That is why I suggested getLocalName() and getFullName().
>> Or whatever.
>
>
>
> Hmm... localName and fullName have no ambiguity that id and name may
> have, and aren't that long enough to type. And don't require that
> two-steps approach. Lots of advantages...
>
> I'll sleep on this, but I think I finally like fullName and localName :-)
A problem though: these names are good for methods, but what about
attributes?
<fd:field localName="bar"> leading to a <fi:field fullName="foo.bar">?
Hmm... doesn't look that good...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms: some renamings on the Widget interface
Posted by Sylvain Wallez <sy...@apache.org>.
Ralph Goers wrote:
> Sylvain Wallez wrote:
>
>> Glen Ezkovich wrote:
>>
>>
>> Yes, changes are possible, and each time some have occured we have
>> made sure that existing code will either run in compatibility mode
>> (with the appropriate deprectation logs) or fail hard by explaining
>> what's happening.
>>
>> The problem here is that the semantics of an existing method changes,
>> and existing code will still compile and run, but with the wrong
>> data. Hence these two steps.
>>
>> Sylvain
>
>
> I can see you're set on doing it this way say I'm not sure why I'm
> posting. Well, yes I am....
>
> It would probably be easier for everyone if getId() just went away
> never to be seen again. Just pick some other name that doesn't
> conflict. That is why I suggested getLocalName() and getFullName().
> Or whatever.
Hmm... localName and fullName have no ambiguity that id and name may
have, and aren't that long enough to type. And don't require that
two-steps approach. Lots of advantages...
I'll sleep on this, but I think I finally like fullName and localName :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms: some renamings on the Widget interface
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ralph Goers wrote:
> Sylvain Wallez wrote:
>
>> Yes, changes are possible, and each time some have occured we have
>> made sure that existing code will either run in compatibility mode
>> (with the appropriate deprectation logs) or fail hard by explaining
>> what's happening.
>>
>> The problem here is that the semantics of an existing method changes,
>> and existing code will still compile and run, but with the wrong data.
>> Hence these two steps.
>
>
> I can see you're set on doing it this way say I'm not sure why I'm
> posting. Well, yes I am....
>
> It would probably be easier for everyone if getId() just went away never
> to be seen again. Just pick some other name that doesn't conflict.
> That is why I suggested getLocalName() and getFullName(). Or whatever.
+1, reduces confusion and count of changes.
Vadim
Re: CForms: some renamings on the Widget interface
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
> Glen Ezkovich wrote:
>
>
> Yes, changes are possible, and each time some have occured we have
> made sure that existing code will either run in compatibility mode
> (with the appropriate deprectation logs) or fail hard by explaining
> what's happening.
>
> The problem here is that the semantics of an existing method changes,
> and existing code will still compile and run, but with the wrong data.
> Hence these two steps.
>
> Sylvain
I can see you're set on doing it this way say I'm not sure why I'm
posting. Well, yes I am....
It would probably be easier for everyone if getId() just went away never
to be seen again. Just pick some other name that doesn't conflict.
That is why I suggested getLocalName() and getFullName(). Or whatever.
Ralph
Re: CForms: some renamings on the Widget interface
Posted by Sylvain Wallez <sy...@apache.org>.
Glen Ezkovich wrote:
>
> On Jun 14, 2005, at 12:46 PM, Sylvain Wallez wrote:
>> I see your point. However, this "fullId" name is part of a two-step
>> renaming strategy, where getRequestParameterName() will end being
>> renamed getId(), an therefore getId() will have its current meaning
>> changed.
>>
>> The first step is:
>> - rename getRequestParameterName() to getFullId()
>> - rename getId() to getName()
>>
>> The second step, once we consider that the migration above has been
>> achieved is to deprecate getFullId() in favor of getId() with its
>> new meaning.
>>
>> So "fullId" should be considered as an interim name on the way to "id".
>
>
> As I understand it CForms is unstable. Why not just change the name
> and meaning now. I understand the desire for back compatibility but
> everyone has been warned. What you are proposing will require two
> changes to stay current.
Yes, changes are possible, and each time some have occured we have made
sure that existing code will either run in compatibility mode (with the
appropriate deprectation logs) or fail hard by explaining what's happening.
The problem here is that the semantics of an existing method changes,
and existing code will still compile and run, but with the wrong data.
Hence these two steps.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms: some renamings on the Widget interface
Posted by Glen Ezkovich <ge...@cox.net>.
On Jun 14, 2005, at 12:46 PM, Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>
>> Ralph Goers wrote:
>>
>>
>>> Sylvain Wallez wrote:
>>>
>>>
>>>> So I propose the following:
>>>> - getId() --> getName()
>>>> - getRequestParameterName() --> getFullId()
>>>>
>>>
>>>
>>>
>>> I'm not familiar with this stuff at all, but from your
>>> description it appears that getFullName() would be better. You
>>> could also use getLocalName() instead of getName(), but I like
>>> getName() as its shorter.
>>>
>>
>>
>> I don't like getFullId too. Here are two other options:
>>
>> - getId() --> getName()
>> - getRequestParameterName() --> getCanonicalName()
>>
>> Or:
>>
>> - getId() --> getLocalName()
>> - getRequestParameterName() --> getName()
>>
>>
>> Both are names, but one is "local" and another is "global" (or
>> "canonical").
>>
>
>
> I see your point. However, this "fullId" name is part of a two-step
> renaming strategy, where getRequestParameterName() will end being
> renamed getId(), an therefore getId() will have its current meaning
> changed.
>
> The first step is:
> - rename getRequestParameterName() to getFullId()
> - rename getId() to getName()
>
> The second step, once we consider that the migration above has been
> achieved is to deprecate getFullId() in favor of getId() with its
> new meaning.
>
> So "fullId" should be considered as an interim name on the way to
> "id".
As I understand it CForms is unstable. Why not just change the name
and meaning now. I understand the desire for back compatibility but
everyone has been warned. What you are proposing will require two
changes to stay current.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: CForms: some renamings on the Widget interface
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Ralph Goers wrote:
>
>> Sylvain Wallez wrote:
>>
>>> So I propose the following:
>>> - getId() --> getName()
>>> - getRequestParameterName() --> getFullId()
>>
>>
>>
>> I'm not familiar with this stuff at all, but from your description it
>> appears that getFullName() would be better. You could also use
>> getLocalName() instead of getName(), but I like getName() as its
>> shorter.
>
>
> I don't like getFullId too. Here are two other options:
>
> - getId() --> getName()
> - getRequestParameterName() --> getCanonicalName()
>
> Or:
>
> - getId() --> getLocalName()
> - getRequestParameterName() --> getName()
>
>
> Both are names, but one is "local" and another is "global" (or
> "canonical").
I see your point. However, this "fullId" name is part of a two-step
renaming strategy, where getRequestParameterName() will end being
renamed getId(), an therefore getId() will have its current meaning changed.
The first step is:
- rename getRequestParameterName() to getFullId()
- rename getId() to getName()
The second step, once we consider that the migration above has been
achieved is to deprecate getFullId() in favor of getId() with its new
meaning.
So "fullId" should be considered as an interim name on the way to "id".
Also, a purpose of this renaming along with some clarification is to
save keystroke in templates, and "canonicalName" isn't much better than
"requestParameterName" :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms: some renamings on the Widget interface
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ralph Goers wrote:
> Sylvain Wallez wrote:
>
>> So I propose the following:
>> - getId() --> getName()
>> - getRequestParameterName() --> getFullId()
>
>
> I'm not familiar with this stuff at all, but from your description it
> appears that getFullName() would be better. You could also use
> getLocalName() instead of getName(), but I like getName() as its shorter.
I don't like getFullId too. Here are two other options:
- getId() --> getName()
- getRequestParameterName() --> getCanonicalName()
Or:
- getId() --> getLocalName()
- getRequestParameterName() --> getName()
Both are names, but one is "local" and another is "global" (or "canonical").
Vadim
Re: CForms: some renamings on the Widget interface
Posted by Ralph Goers <Ra...@dslextreme.com>.
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()!
> - 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()
> - getRequestParameterName() --> getFullId()
I'm not familiar with this stuff at all, but from your description it
appears that getFullName() would be better. You could also use
getLocalName() instead of getName(), but I like getName() as its shorter.
> - 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().
>
> WDYT?
>
> Sylvain
Ralph
Re: CForms: some renamings on the Widget interface
Posted by Sylvain Wallez <sy...@apache.org>.
Jason Johnston wrote:
>On Mon, 2005-06-13 at 23:31 +0200, Sylvain Wallez wrote:
>
>
>>Jason Johnston wrote:
>>
>>>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. ;-)
>
>
Hmmm... neither XForms <input> nor XUL's <textbox> have an @name :-)
>>>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. :-)
>
>
Yeah, I should have explained that second part also. Sorry for that.
>Now that I understand your motives correctly, it makes sense. I think
>your deprecation strategy is reasonable.
>
>
Great!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms: some renamings on the Widget interface
Posted by Jason Johnston <ja...@Intrado.com>.
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
>
Re: CForms: some renamings on the Widget interface
Posted by Sylvain Wallez <sy...@apache.org>.
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
Re: CForms: some renamings on the Widget interface
Posted by Jason Johnston <ja...@Intrado.com>.
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.
> - 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">
^^
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.
> - 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.
> - 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().
>
> WDYT?
>
> Sylvain
Re: CForms: some renamings on the Widget interface
Posted by Antonio Gallardo <ag...@agssa.net>.
On Lun, 13 de Junio de 2005, 10:02, Sylvain Wallez dijo:
> So I propose the following:
> - getId() --> getName()
> - getRequestParameterName() --> getFullId()
> - 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().
+1
Best Regards,
Antonio Gallardo