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 Tue, 05 Oct 2004 19:53:15 GMT
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 <pmf8@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


Mime
View raw message