tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norbert Sándor <develo...@erinors.com>
Subject Re: Tapestry 5 thoughts
Date Wed, 01 Feb 2006 08:15:57 GMT
> I agree that <service> was easier than the HM approach, which is
> (infinitely) flexible.
I think that the most perfect solution is if Hivemind supports annotations 
therefore engine service implementations can define their dependencies using 
annotations. (+ autowiring)

> 1) Keep backwards compatibility and evolve the code base (give or take)
> 2) Sacrifice backwards compatibility, but create the simpler, less
> ambiguous (easier to learn) framework people want

> My current vision is that the 4.1 code base will be about creating new
> components, including Ajax integration. Most of the innovation is
Will 4.1 based on DOJO? (= Tacos and Tapestry 4 will be merged?)
I think it is very important to fully support DOJO (now both Tapestry and 
DOJO are stable):
- some unified (documented) way to convert DOJO components to Tapestry 
- make them working in case of "partial" refresh
- etc (more active dojo/tacos users may continue the list)

> - Annotations based.  JDK 1.5.
Great, I would love generics in the API methods as well. (Currently my code 
is full of warnings because of lack of java5 support.)

> - No XML for pages and components.  Just HTML and Annotations.
I don't like this, separating layout and component defs is a very good thing 
in tapestry!
I define components only in the .jwc/.page file, even in case of the most 
simple RenderBody. And I think @Component is not a clean solution especially 
when the component has many subcomponents, the class file becomes "ugly".

> ... others


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

View raw message