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
2)
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
components
- 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
Great!
Regards,
Norbi
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
