cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Johnston <jason.johns...@Intrado.com>
Subject Re: CForms: some renamings on the Widget interface
Date Mon, 13 Jun 2005 22:31:53 GMT
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
> 

Mime
View raw message