While dojo seems a very good library, there are some serious
considerations about making tapestry really dependeant on it -
I would like to know if that is going to be the case for 4.1...
Well, as unpopular as it may sound, I find that very unacceptable -
dojo, as hip as it is, has also many disadvantages - like getting really
hard on the browser for very basic tasks - so page load time is very
long, getting high latency also when using top hardware - I don't want
to know what happens when and if using old browsers and hardware -
I think if tapestry is heading the way of being a web framework for ajax
applications, not giving the basic sleek functionality for good old web
1.0 - well - this requires some discussion from the community.
currently, all JS is clean and functions well, I hope it stays that way,
*enabling* one to use JS libraries such as Dojo, but not *imposing* one
to use a certain one...
Cheers,
Ron
Norbert Sándor wrote:
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]
