tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamie Orchard-Hays" <ja...@dang.com>
Subject Re: 3.1 Status / progress / thoughts
Date Thu, 07 Oct 2004 21:20:45 GMT
LOL!


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


Mime
View raw message