tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: 3.1 Status / progress / thoughts
Date Wed, 06 Oct 2004 16:07:30 GMT
On reflection, I agree.  <bind> vs. <binding> .... I think we should
keep <binding>, for consistency with the other tags (<component>,
<asset>, <property>) each is a noun, with an implciit "define" verb.


On Wed, 6 Oct 2004 09:44:00 -0400, Harish Krishnaswamy
<harishkswamy@gmail.com> wrote:
> I would actually like to keep verbs out of XMLs. Verbs in XML starts
> to give an impression that it is not a simple specification but rather
> a command. +1 on the rest.
> 
> -Harish
> 
> 
> 
> On Wed, 6 Oct 2004 07:18:00 -0400, Howard Lewis Ship <hlship@gmail.com> wrote:
> > I kind of like <bind> instead of <binding>.
> >
> > Now is the time to hammer out these kinds of changes, before I start
> > converting the framework specs to 3.1.
> >
> > The good thing, compatability-wise, is that you will be able to use
> > the 3.0 DTDs.
> >
> > I think it will be easier to track peoples input on this subject on the wiki:
> >
> > http://wiki.apache.org/jakarta-tapestry/SimplifiedSpecificationsProposal
> >
> > On Wed, 6 Oct 2004 14:21:58 +1000, Richard Lewis-Shell
> >
> >
> > <rlewisshell@mac.com> wrote:
> > > bind: +1 (the verb seems more natural, but perhaps less consistent)
> > > param: -1 (i'm not a fan of abbreviations)
> > >
> > > re: changes in the dtd surrounding 'property' and backwards compatibility -
> > > it will be a painful shift, but i think it is worth it.  too many hours i
> > > have spent wondering why my property wasn't working, only to find it was
> > > supposed to be declared as a property-specification.  3.1 is a pretty big
> > > change for tapestry, so i am in favour of this improvement. tapestry 5.0
> > > anyone? (joke)
> > >
> > > one thought - how about 'attribute' instead of 'meta'?  is that term more in
> > > line with java?  is that a good or a bad thing?  good as the general idea is
> > > more likely to be understood, bad as it's not an attribute in the java sense
> > > (but then the specification is not a class either).
> > >
> > > Richard
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Eric Everman" <everman@precedadesign.com>
> > > To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
> > > Sent: Wednesday, October 06, 2004 9:21 AM
> > > Subject: Re: 3.1 Status / progress / thoughts
> > >
> > > > I like these suggestions - let me throw another into the mix:
> > > >
> > > > Lets keeps all names as short as possible, since these config files are
> > > > often hand edited.  For example:
> > > > <bind> instead of <binding>
> > > > param instead of parameter
> > > > etc...
> > > >
> > > > I'm all for keeping these files human readable, but I'm also interested
> > > > in human editable :)
> > > >
> > > > Eric Everman
> > > >
> > > >
> > > >
> > > > On 5 Oct 2004, at 17:56, Pablo Lalloni wrote:
> > > >
> > > > > We use extensively the content of <binding/> to specify the
ognl
> > > > > expression since there you can use quotes freely... now how does
this
> > > > > maps to the new prefix syntax?
> > > > >
> > > > > This quotes thing qets specially important when we need to pass an
OGNL
> > > > > expressions as a strings to be evaluated later, which occurs often.
> > > > >
> > > > > I think separating the prefix from the expression would make it cleaner
> > > > > to read & write:
> > > > >
> > > > > <binding name="something" type="ognl" value="some.complex.expression
+
> > > > > 'a string constant'"/>
> > > > >
> > > > > or
> > > > >
> > > > > <binding name="something" type="ognl">some.complex.expression
+ "a
> > > > > string constant"</binding>
> > > > >
> > > > > Of course, "type" could have a sensitive default, honouring marc.f
war
> > > > > cry.
> > > > >
> > > > > Also, while we're on the big move, why not grab the opportunity to
> > > > > rename the "name" attribute to "parameter" since that's what it is
> > > > > IMHO.
> > > > > Newbies here doesn't associate quickly that "name" corresponds to
a
> > > > > parameter of the component being used, "name" seems like being just
> > > > > naming the binding.
> > > > >
> > > > > So, we would have something like:
> > > > >
> > > > > <binding parameter="something" type="ognl"
> > > > > value="some.complex.expression + 'a string constant'"/>
> > > > >
> > > > > or
> > > > >
> > > > > <binding parameter="something" type="ognl">some.complex.expression
+ "a
> > > > > string constant"</binding>
> > > > >
> > > > >
> > > > > El mar, 05-10-2004 a las 14:30, Howard Lewis Ship escribió:
> > > > >
> > > > >> I'm just about ready to check in the first interesting changes
for
> > > > >> 3.1.
> > > > >>
> > > > >> Just started introducing the 3.1 DTD.
> > > > >>
> > > > >>
> > > > >>
> > > > >> <inherited-binding>, <static-binding>, <message-binding>
have gone
> > > > >> away (still valid if you use the 3.0 DTD).
> > > > >>
> > > > >> <binding> is now <binding name="..." value="...">
or <binding
> > > > >> name="..."> .... </binding>
> > > > >>
> > > > >> You now use prefixes in the spec exactly the same as in the HTML
> > > > >> template. Consistency!
> > > > >>
> > > > >> Example:
> > > > >>
> > > > >> <component id="loop" type="Foreach">
> > > > >>   <binding name="source" value='ognl:items"/>
> > > > >>   <binding name="value" value="ognl:item"/>
> > > > >>   <binding name="element" value="tr"/>
> > > > >> </component>
> > > > >>
> > > > >> <service> has gone away; you now need to do services from
inside
> > > > >> HiveMind. 3.0 DTDs that use service will see a warning.
> > > > >>
> > > > >> So, you can see, that I'm trying to simplify, streamline and
improve
> > > > >> consistency in the specs.
> > > > >>
> > > > >> One thing I would like dearly to do is make a few broader changes:
> > > > >>
> > > > >> <property> (3.0) --> <meta> (3.1)  [[ for defining
meta-data ]]
> > > > >> <property-specification> (3.0) --> <property>
(3.1) [[ for adding
> > > > >> properties to a class ]]
> > > > >>
> > > > >> I think it's much neater, and if this was 1.0, there would be
no
> > > > >> question.  But it's 3.1 ... will this throw users too much?
> > > > >>
> > > > >> Perhaps we support both <property> and <property-specification>
in
> > > > >> 3.1, as a transition towards <property>?
> > > > >
> > > > > --
> > > > >
> > > > > Pablo I. Lalloni
> > > > > Teléfono +54 (11) 4347-3177
> > > > > Proyecto Pampa
> > > > > Dirección Informática Tributaria
> > > > > AFIP
> > > > >
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > ~~~~~~~~
> > > > > Military intelligence is a contradiction in terms.
> > > > > -- Groucho Marx
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > ~~~~~~~~
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > --
> > Howard M. Lewis Ship
> > Independent J2EE / Open-Source Java Consultant
> > Creator, Jakarta Tapestry
> > Creator, Jakarta HiveMind
> > http://howardlewisship.com
> >
> >
> > 
> > ---------------------------------------------------------------------
> 
> 
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
> 


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com

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


Mime
View raw message