Jamie Orchard-Hays wrote:
I'm curious how you would have components with integrated AJAX and
DHTML but have the javascript libraries they use as optional.
You just don't.
I do understand why poeple want tacos to come into tapestry, maybe in
the contrib library, but I don't think its the right thing for tapestry
to do.
Why do this merge? is it just in one line with the HLS centralizing -
making also the tapestry framework home for all high quality components?
IMO its important that tacos stays there as tacos, thats it reaches
maturity on its own, and that it interacts (and jesse will sureley take
care of that...) , but does not merge into the codebase of tapestry.
Ofcause, the middle way could be, after tapestry is an direct Apache
project, add an Ajax subproject with all kind of firework and music.
It is also a sign of a framework evolvement - that many different
independant "repositories" are contributing to it -
Cheers,
Ron
And what
would the point be? If the components work why does it matter what
javascript library they use? People can always write their own custom
components with different javascript libraries if they want, but I
don't see any advantage to what you're suggesting.
Jamie
On Feb 1, 2006, at 6:22 AM, Ron Piterman wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
