tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jamie Orchard-Hays <ja...@dang.com>
Subject Re: 3.1 Status / progress / thoughts
Date Wed, 06 Oct 2004 23:50:09 GMT
I'll chime in that I think abbreviating names is not a good idea.

Jamie


On Oct 5, 2004, at 7:21 PM, Eric Everman wrote:

> I like these suggestions - let me throw another into the mix:
>
> Lets keeps all names as short as possible, since these config files  
> are often hand edited.  For example:
> <bind> instead of <binding>
> param instead of parameter
> etc...
>
> I'm all for keeping these files human readable, but I'm also  
> interested in human editable :)
>
> Eric Everman
>
>
>
> On 5 Oct 2004, at 17:56, Pablo Lalloni wrote:
>
>> We use extensively the content of <binding/> to specify the ognl
>> expression since there you can use quotes freely... now how does this
>> maps to the new prefix syntax?
>>
>> This quotes thing qets specially important when we need to pass an  
>> OGNL
>> expressions as a strings to be evaluated later, which occurs often.
>>
>> I think separating the prefix from the expression would make it  
>> cleaner
>> to read & write:
>>
>> <binding name="something" type="ognl" value="some.complex.expression +
>> 'a string constant'"/>
>>
>> or
>>
>> <binding name="something" type="ognl">some.complex.expression + "a
>> string constant"</binding>
>>
>> Of course, "type" could have a sensitive default, honouring marc.f war
>> cry.
>>
>> Also, while we're on the big move, why not grab the opportunity to
>> rename the "name" attribute to "parameter" since that's what it is  
>> IMHO.
>> Newbies here doesn't associate quickly that "name" corresponds to a
>> parameter of the component being used, "name" seems like being just
>> naming the binding.
>>
>> So, we would have something like:
>>
>> <binding parameter="something" type="ognl"
>> value="some.complex.expression + 'a string constant'"/>
>>
>> or
>>
>> <binding parameter="something" type="ognl">some.complex.expression +  
>> "a
>> string constant"</binding>
>>
>>
>> El mar, 05-10-2004 a las 14:30, Howard Lewis Ship escribió:
>>
>>> I'm just about ready to check in the first interesting changes for  
>>> 3.1.
>>>
>>> Just started introducing the 3.1 DTD.
>>>
>>>
>>>
>>> <inherited-binding>, <static-binding>, <message-binding> have
gone
>>> away (still valid if you use the 3.0 DTD).
>>>
>>> <binding> is now <binding name="..." value="..."> or <binding
>>> name="..."> .... </binding>
>>>
>>> You now use prefixes in the spec exactly the same as in the HTML
>>> template. Consistency!
>>>
>>> Example:
>>>
>>> <component id="loop" type="Foreach">
>>>   <binding name="source" value='ognl:items"/>
>>>   <binding name="value" value="ognl:item"/>
>>>   <binding name="element" value="tr"/>
>>> </component>
>>>
>>> <service> has gone away; you now need to do services from inside
>>> HiveMind. 3.0 DTDs that use service will see a warning.
>>>
>>> So, you can see, that I'm trying to simplify, streamline and improve
>>> consistency in the specs.
>>>
>>> One thing I would like dearly to do is make a few broader changes:
>>>
>>> <property> (3.0) --> <meta> (3.1)  [[ for defining meta-data ]]
>>> <property-specification> (3.0) --> <property> (3.1) [[ for adding
>>> properties to a class ]]
>>>
>>> I think it's much neater, and if this was 1.0, there would be no
>>> question.  But it's 3.1 ... will this throw users too much?
>>>
>>> Perhaps we support both <property> and <property-specification> in
>>> 3.1, as a transition towards <property>?
>>
>> --  
>> Pablo I. Lalloni
>> Teléfono +54 (11) 4347-3177
>> Proyecto Pampa
>> Dirección Informática Tributaria
>> AFIP
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
>> ~~~~~~~~~
>> Military intelligence is a contradiction in terms.
>> 		-- Groucho Marx
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
>> ~~~~~~~~~
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message