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:54:23 GMT
I'll also throw in the controversial notion (at least for Howard!) that  
this really should be called Tapestry 4.0!

Jamie


On Oct 6, 2004, at 12:07 PM, Howard Lewis Ship wrote:

> On reflection, I agree.  <bind> vs. <binding> .... I think we should
> keep <binding>, for consistency with the other tags (<component>,
> <asset>, <property>) each is a noun, with an implciit "define" verb.
>
>
> On Wed, 6 Oct 2004 09:44:00 -0400, Harish Krishnaswamy
> <harishkswamy@gmail.com> wrote:
>> I would actually like to keep verbs out of XMLs. Verbs in XML starts
>> to give an impression that it is not a simple specification but rather
>> a command. +1 on the rest.
>>
>> -Harish
>>
>>
>>
>> On Wed, 6 Oct 2004 07:18:00 -0400, Howard Lewis Ship  
>> <hlship@gmail.com> wrote:
>>> I kind of like <bind> instead of <binding>.
>>>
>>> Now is the time to hammer out these kinds of changes, before I start
>>> converting the framework specs to 3.1.
>>>
>>> The good thing, compatability-wise, is that you will be able to use
>>> the 3.0 DTDs.
>>>
>>> I think it will be easier to track peoples input on this subject on  
>>> the wiki:
>>>
>>> http://wiki.apache.org/jakarta-tapestry/ 
>>> SimplifiedSpecificationsProposal
>>>
>>> On Wed, 6 Oct 2004 14:21:58 +1000, Richard Lewis-Shell
>>>
>>>
>>> <rlewisshell@mac.com> wrote:
>>>> bind: +1 (the verb seems more natural, but perhaps less consistent)
>>>> param: -1 (i'm not a fan of abbreviations)
>>>>
>>>> re: changes in the dtd surrounding 'property' and backwards  
>>>> compatibility -
>>>> it will be a painful shift, but i think it is worth it.  too many  
>>>> hours i
>>>> have spent wondering why my property wasn't working, only to find  
>>>> it was
>>>> supposed to be declared as a property-specification.  3.1 is a  
>>>> pretty big
>>>> change for tapestry, so i am in favour of this improvement.  
>>>> tapestry 5.0
>>>> anyone? (joke)
>>>>
>>>> one thought - how about 'attribute' instead of 'meta'?  is that  
>>>> term more in
>>>> line with java?  is that a good or a bad thing?  good as the  
>>>> general idea is
>>>> more likely to be understood, bad as it's not an attribute in the  
>>>> java sense
>>>> (but then the specification is not a class either).
>>>>
>>>> Richard
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Eric Everman" <everman@precedadesign.com>
>>>> To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
>>>> Sent: Wednesday, October 06, 2004 9:21 AM
>>>> Subject: Re: 3.1 Status / progress / thoughts
>>>>
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Howard M. Lewis Ship
>>> Independent J2EE / Open-Source Java Consultant
>>> Creator, Jakarta Tapestry
>>> Creator, Jakarta HiveMind
>>> http://howardlewisship.com
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>
>>
>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>
>>>
>>
>
>
> -- 
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> 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