You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2004/10/05 19:30:51 UTC
3.1 Status / progress / thoughts
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>?
--
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
Re: 3.1 Status / progress / thoughts
Posted by Paul Ferraro <pm...@columbia.edu>.
Howard Lewis Ship wrote:
>Tapestry uses a validating parser; the public id selects the DTD which
>is validated. The SpecificationParser knows which DTD and makes
>descisions about how to procede at certain points based on that.
>
>I don't think you could do the version approach you specified ... and
>if you could, I don't see what it buys on top of choosing the correct
>DTD version.
>
>I have thought about doing some big refactoring to allow the DTD to
>choose a kind of handler to do the rest of the work. Hasn't been a big
>need for it yet.
>
>
>
That's what I had in mind, i.e. choosing a content handler based on
version - It should have been obvious to a less tired person that the
DTD already indicates this. :)
>On Tue, 05 Oct 2004 11:57:05 -0700, Paul Ferraro <pm...@columbia.edu> wrote:
>
>
>>Howard Lewis Ship wrote:
>>
>>
>>
>>>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>
>>>
>>>
>>>
>>>
>>>
>>I like it.
>>
>>
>>
>>><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?
>>>
>>>
>>>
>>>
>>>
>>Since this there's going to be a new DTD anyway, I have no issues with
>>additional nomenclature changes.
>>
>>
>>
>>>Perhaps we support both <property> and <property-specification> in
>>>3.1, as a transition towards <property>?
>>>
>>>
>>>
>>>
>>>
>>As an alternative to the deprecation approach, how about
>>version-specific configuration parsers?
>>e.g.
>>
>><!DOCTYPE page-specification PUBLIC "-//Apache Software
>>Foundation//Tapestry Specification 3.0//EN"
>>"http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd">
>><page-specification version="3.0">
>> <property name="role" value="admin"/>
>> <page-property name="item" type="java.lang.Object"/>
>> <component id="loop" type="Foreach">
>> <binding name="source" expression="items"/>
>> <binding name="value" expression="item"/>
>> <static-binding name="element" value="tr"/>
>> </component>
>></page-specification>
>>
>><!DOCTYPE page-specification PUBLIC "-//Apache Software
>>Foundation//Tapestry Specification 3.1//EN"
>>"http://jakarta.apache.org/tapestry/dtd/Tapestry_3_1.dtd">
>><page-specification version="3.1">
>> <meta name="role" value="admin"/>
>> <property name="item" type="java.lang.Object"/>
>> <component id="loop" type="Foreach">
>> <binding name="source" value="ognl:items"/>
>> <binding name="value" value="ognl:item"/>
>> <binding name="element" value="tr"/>
>> </component>
>></page-specification>
>>
>>A factory would responsible for returning an appropriate specification
>>content handler based on the version attribute. There might be a better
>>place to specify the version identifier (e.g. system property,
>>application property, etc.).
>>I realize that this would get ugly - but the ugliness might be worth the
>>ability to soften the impact of these types of changes.
>>Is this just absurd? Thoughts?
>>
>>Paul
>>
>>---------------------------------------------------------------------
>>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
Re: 3.1 Status / progress / thoughts
Posted by Howard Lewis Ship <hl...@gmail.com>.
Tapestry uses a validating parser; the public id selects the DTD which
is validated. The SpecificationParser knows which DTD and makes
descisions about how to procede at certain points based on that.
I don't think you could do the version approach you specified ... and
if you could, I don't see what it buys on top of choosing the correct
DTD version.
I have thought about doing some big refactoring to allow the DTD to
choose a kind of handler to do the rest of the work. Hasn't been a big
need for it yet.
On Tue, 05 Oct 2004 11:57:05 -0700, Paul Ferraro <pm...@columbia.edu> wrote:
> Howard Lewis Ship wrote:
>
> >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>
> >
> >
> >
> I like it.
>
> ><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?
> >
> >
> >
> Since this there's going to be a new DTD anyway, I have no issues with
> additional nomenclature changes.
>
> >Perhaps we support both <property> and <property-specification> in
> >3.1, as a transition towards <property>?
> >
> >
> >
> As an alternative to the deprecation approach, how about
> version-specific configuration parsers?
> e.g.
>
> <!DOCTYPE page-specification PUBLIC "-//Apache Software
> Foundation//Tapestry Specification 3.0//EN"
> "http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd">
> <page-specification version="3.0">
> <property name="role" value="admin"/>
> <page-property name="item" type="java.lang.Object"/>
> <component id="loop" type="Foreach">
> <binding name="source" expression="items"/>
> <binding name="value" expression="item"/>
> <static-binding name="element" value="tr"/>
> </component>
> </page-specification>
>
> <!DOCTYPE page-specification PUBLIC "-//Apache Software
> Foundation//Tapestry Specification 3.1//EN"
> "http://jakarta.apache.org/tapestry/dtd/Tapestry_3_1.dtd">
> <page-specification version="3.1">
> <meta name="role" value="admin"/>
> <property name="item" type="java.lang.Object"/>
> <component id="loop" type="Foreach">
> <binding name="source" value="ognl:items"/>
> <binding name="value" value="ognl:item"/>
> <binding name="element" value="tr"/>
> </component>
> </page-specification>
>
> A factory would responsible for returning an appropriate specification
> content handler based on the version attribute. There might be a better
> place to specify the version identifier (e.g. system property,
> application property, etc.).
> I realize that this would get ugly - but the ugliness might be worth the
> ability to soften the impact of these types of changes.
> Is this just absurd? Thoughts?
>
> Paul
>
> ---------------------------------------------------------------------
> 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
Re: 3.1 Status / progress / thoughts
Posted by Howard Lewis Ship <hl...@gmail.com>.
Also, your example is 100% valid except for the version attribute on
the <page-specification> element. The DTD identifies a version, and
that's used when parsing. Old 3.0 DTDs are still valid and will (with
noted exceptions) still work as expected.
On Tue, 05 Oct 2004 11:57:05 -0700, Paul Ferraro <pm...@columbia.edu> wrote:
> Howard Lewis Ship wrote:
>
> >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>
> >
> >
> >
> I like it.
>
> ><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?
> >
> >
> >
> Since this there's going to be a new DTD anyway, I have no issues with
> additional nomenclature changes.
>
> >Perhaps we support both <property> and <property-specification> in
> >3.1, as a transition towards <property>?
> >
> >
> >
> As an alternative to the deprecation approach, how about
> version-specific configuration parsers?
> e.g.
>
> <!DOCTYPE page-specification PUBLIC "-//Apache Software
> Foundation//Tapestry Specification 3.0//EN"
> "http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd">
> <page-specification version="3.0">
> <property name="role" value="admin"/>
> <page-property name="item" type="java.lang.Object"/>
> <component id="loop" type="Foreach">
> <binding name="source" expression="items"/>
> <binding name="value" expression="item"/>
> <static-binding name="element" value="tr"/>
> </component>
> </page-specification>
>
> <!DOCTYPE page-specification PUBLIC "-//Apache Software
> Foundation//Tapestry Specification 3.1//EN"
> "http://jakarta.apache.org/tapestry/dtd/Tapestry_3_1.dtd">
> <page-specification version="3.1">
> <meta name="role" value="admin"/>
> <property name="item" type="java.lang.Object"/>
> <component id="loop" type="Foreach">
> <binding name="source" value="ognl:items"/>
> <binding name="value" value="ognl:item"/>
> <binding name="element" value="tr"/>
> </component>
> </page-specification>
>
> A factory would responsible for returning an appropriate specification
> content handler based on the version attribute. There might be a better
> place to specify the version identifier (e.g. system property,
> application property, etc.).
> I realize that this would get ugly - but the ugliness might be worth the
> ability to soften the impact of these types of changes.
> Is this just absurd? Thoughts?
>
> Paul
>
> ---------------------------------------------------------------------
> 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
Re: 3.1 Status / progress / thoughts
Posted by Paul Ferraro <pm...@columbia.edu>.
Howard Lewis Ship wrote:
>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>
>
>
>
I like it.
><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?
>
>
>
Since this there's going to be a new DTD anyway, I have no issues with
additional nomenclature changes.
>Perhaps we support both <property> and <property-specification> in
>3.1, as a transition towards <property>?
>
>
>
As an alternative to the deprecation approach, how about
version-specific configuration parsers?
e.g.
<!DOCTYPE page-specification PUBLIC "-//Apache Software
Foundation//Tapestry Specification 3.0//EN"
"http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd">
<page-specification version="3.0">
<property name="role" value="admin"/>
<page-property name="item" type="java.lang.Object"/>
<component id="loop" type="Foreach">
<binding name="source" expression="items"/>
<binding name="value" expression="item"/>
<static-binding name="element" value="tr"/>
</component>
</page-specification>
<!DOCTYPE page-specification PUBLIC "-//Apache Software
Foundation//Tapestry Specification 3.1//EN"
"http://jakarta.apache.org/tapestry/dtd/Tapestry_3_1.dtd">
<page-specification version="3.1">
<meta name="role" value="admin"/>
<property name="item" type="java.lang.Object"/>
<component id="loop" type="Foreach">
<binding name="source" value="ognl:items"/>
<binding name="value" value="ognl:item"/>
<binding name="element" value="tr"/>
</component>
</page-specification>
A factory would responsible for returning an appropriate specification
content handler based on the version attribute. There might be a better
place to specify the version identifier (e.g. system property,
application property, etc.).
I realize that this would get ugly - but the ugliness might be worth the
ability to soften the impact of these types of changes.
Is this just absurd? Thoughts?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: 3.1 Status / progress / thoughts
Posted by Alex <al...@gmail.com>.
Hope we will get a change list soon.
On Thu, 7 Oct 2004 17:20:45 -0400, Jamie Orchard-Hays <ja...@dang.com> wrote:
> LOL!
>
>
>
>
> ----- Original Message -----
> From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Thursday, October 07, 2004 4:59 PM
> Subject: Re: 3.1 Status / progress / thoughts
>
> I figure, Tapestry will be finished just about when the last person
> closes their web browser for the last time.
>
> On Thu, 7 Oct 2004 14:30:33 -0400, Jamie Orchard-Hays <ja...@dang.com>
> wrote:
> > Aha! There's yet more on the horizon!
> >
> > Jamie
> >
> >
> > ----- Original Message -----
> > From: "Howard Lewis Ship" <hl...@gmail.com>
> > To: "Tapestry development" <ta...@jakarta.apache.org>
> > Sent: Thursday, October 07, 2004 10:31 AM
> > Subject: Re: 3.1 Status / progress / thoughts
> >
> > What I'm calling "Tapestry 4.0" is *much* more radical! I should
> > document my thoughts on the wiki ....
> >
> > Tapestry 3.1 will not be 100% backwards compatible to Tapestry 3.0,
> > but the changes will only affect a small amount of code that the most
> > advanced users care about.
> >
> > Tapestry 4.0 will not be backwards compatible; it will be much more of
> > a clean sweep.
> >
> > On Wed, 6 Oct 2004 19:54:23 -0400, Jamie Orchard-Hays <ja...@dang.com>
> > wrote:
> > > 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
> > > > <ha...@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
> > > >> <hl...@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
> > > >>>
> > > >>>
> > > >>> <rl...@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" <ev...@precedadesign.com>
> > > >>>> To: "Tapestry development" <ta...@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
> > >
> > >
> >
> > --
> > 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
> >
> >
>
> --
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: 3.1 Status / progress / thoughts
Posted by Jamie Orchard-Hays <ja...@dang.com>.
LOL!
----- Original Message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Thursday, October 07, 2004 4:59 PM
Subject: Re: 3.1 Status / progress / thoughts
I figure, Tapestry will be finished just about when the last person
closes their web browser for the last time.
On Thu, 7 Oct 2004 14:30:33 -0400, Jamie Orchard-Hays <ja...@dang.com>
wrote:
> Aha! There's yet more on the horizon!
>
> Jamie
>
>
> ----- Original Message -----
> From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Thursday, October 07, 2004 10:31 AM
> Subject: Re: 3.1 Status / progress / thoughts
>
> What I'm calling "Tapestry 4.0" is *much* more radical! I should
> document my thoughts on the wiki ....
>
> Tapestry 3.1 will not be 100% backwards compatible to Tapestry 3.0,
> but the changes will only affect a small amount of code that the most
> advanced users care about.
>
> Tapestry 4.0 will not be backwards compatible; it will be much more of
> a clean sweep.
>
> On Wed, 6 Oct 2004 19:54:23 -0400, Jamie Orchard-Hays <ja...@dang.com>
> wrote:
> > 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
> > > <ha...@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
> > >> <hl...@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
> > >>>
> > >>>
> > >>> <rl...@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" <ev...@precedadesign.com>
> > >>>> To: "Tapestry development" <ta...@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
> >
> >
>
> --
> 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
>
>
--
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
Re: 3.1 Status / progress / thoughts
Posted by Howard Lewis Ship <hl...@gmail.com>.
I figure, Tapestry will be finished just about when the last person
closes their web browser for the last time.
On Thu, 7 Oct 2004 14:30:33 -0400, Jamie Orchard-Hays <ja...@dang.com> wrote:
> Aha! There's yet more on the horizon!
>
> Jamie
>
>
> ----- Original Message -----
> From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Thursday, October 07, 2004 10:31 AM
> Subject: Re: 3.1 Status / progress / thoughts
>
> What I'm calling "Tapestry 4.0" is *much* more radical! I should
> document my thoughts on the wiki ....
>
> Tapestry 3.1 will not be 100% backwards compatible to Tapestry 3.0,
> but the changes will only affect a small amount of code that the most
> advanced users care about.
>
> Tapestry 4.0 will not be backwards compatible; it will be much more of
> a clean sweep.
>
> On Wed, 6 Oct 2004 19:54:23 -0400, Jamie Orchard-Hays <ja...@dang.com>
> wrote:
> > 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
> > > <ha...@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
> > >> <hl...@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
> > >>>
> > >>>
> > >>> <rl...@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" <ev...@precedadesign.com>
> > >>>> To: "Tapestry development" <ta...@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
> >
> >
>
> --
> 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
>
>
--
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
Re: 3.1 Status / progress / thoughts
Posted by Jamie Orchard-Hays <ja...@dang.com>.
Aha! There's yet more on the horizon!
Jamie
----- Original Message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Thursday, October 07, 2004 10:31 AM
Subject: Re: 3.1 Status / progress / thoughts
What I'm calling "Tapestry 4.0" is *much* more radical! I should
document my thoughts on the wiki ....
Tapestry 3.1 will not be 100% backwards compatible to Tapestry 3.0,
but the changes will only affect a small amount of code that the most
advanced users care about.
Tapestry 4.0 will not be backwards compatible; it will be much more of
a clean sweep.
On Wed, 6 Oct 2004 19:54:23 -0400, Jamie Orchard-Hays <ja...@dang.com>
wrote:
> 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
> > <ha...@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
> >> <hl...@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
> >>>
> >>>
> >>> <rl...@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" <ev...@precedadesign.com>
> >>>> To: "Tapestry development" <ta...@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
>
>
--
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
Re: 3.1 Status / progress / thoughts
Posted by Howard Lewis Ship <hl...@gmail.com>.
What I'm calling "Tapestry 4.0" is *much* more radical! I should
document my thoughts on the wiki ....
Tapestry 3.1 will not be 100% backwards compatible to Tapestry 3.0,
but the changes will only affect a small amount of code that the most
advanced users care about.
Tapestry 4.0 will not be backwards compatible; it will be much more of
a clean sweep.
On Wed, 6 Oct 2004 19:54:23 -0400, Jamie Orchard-Hays <ja...@dang.com> wrote:
> 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
> > <ha...@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
> >> <hl...@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
> >>>
> >>>
> >>> <rl...@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" <ev...@precedadesign.com>
> >>>> To: "Tapestry development" <ta...@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
>
>
--
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
Re: 3.1 Status / progress / thoughts
Posted by Jamie Orchard-Hays <ja...@dang.com>.
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
> <ha...@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
>> <hl...@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
>>>
>>>
>>> <rl...@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" <ev...@precedadesign.com>
>>>> To: "Tapestry development" <ta...@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
Re: 3.1 Status / progress / thoughts
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<ha...@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 <hl...@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
> >
> >
> > <rl...@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" <ev...@precedadesign.com>
> > > To: "Tapestry development" <ta...@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
Re: 3.1 Status / progress / thoughts
Posted by Harish Krishnaswamy <ha...@gmail.com>.
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 <hl...@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
>
>
> <rl...@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" <ev...@precedadesign.com>
> > To: "Tapestry development" <ta...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: 3.1 Status / progress / thoughts
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<rl...@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" <ev...@precedadesign.com>
> To: "Tapestry development" <ta...@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
Re: 3.1 Status / progress / thoughts
Posted by Richard Lewis-Shell <rl...@mac.com>.
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" <ev...@precedadesign.com>
To: "Tapestry development" <ta...@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
Re: 3.1 Status / progress / thoughts
Posted by Jamie Orchard-Hays <ja...@dang.com>.
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
Re: 3.1 Status / progress / thoughts
Posted by Eric Everman <ev...@precedadesign.com>.
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
Re: 3.1 Status / progress / thoughts
Posted by Pablo Lalloni <pl...@afip.gov.ar>.
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: 3.1 Status / progress / thoughts
Posted by Geoff Longman <gl...@gmail.com>.
Looks like these changes are going to be fairly easy to support in Spindle..
Yah!
Geoff
On Tue, 5 Oct 2004 13:30:51 -0400, Howard Lewis Ship <hl...@gmail.com> wrote:
> 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>?
>
> --
> 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