cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: CForms: some renamings on the Widget interface
Date Mon, 13 Jun 2005 21:31:27 GMT
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


Mime
View raw message