an advantage to NOT having tapestry built on spring is that we can
drop in our legacy spring contexts where we don't want to upgrade from
1.x
I really think tapestry-ioc was designed in such a way to allow
maximum refactorability and ease of testing from the developer's
standpoint.
In a way, I kindof see what you mean. I was a little put off by T4
when I heard of this "hivemind"(the predecessor to tapestry-ioc) thing
when I had already studied up on spring.
I suppose it would really take some time to see how Spring evolves,
whether or not it would be up to the job for driving tapestry. I
believe tapestry-ioc and -core have made such a great leap forward in
terms of "pulling it all together" for streamlining web-development
with java that it wouldn't have been possible to do with Spring.
spring was ubiquitous already, but couldn't mature as fast because
they had to hold up the legacy support. Tapestry is often critized for
having too many releases with too little compatibility. This is the
price you pay for having such an excellent framework. I believe
tapestry-ioc to be very mature already and by the time it comes 'round
that Spring can do what tapestry-ioc can do, tapestry-ioc (and
tapestry-core) will probably have a big following. Those people may/
may not want to go through the hassle of switching to spring. That
depends on how appealing Spring is or becomes. maybe by that point
"Spring" might be considered "stale".
Anyway, the tapestry-spring link is exactly what this project needs.
I think the site should do a little more to distinguish between the
two and drive new tapestry-lookers to a path which makes tapestry and
spring look like best pals.
-Mike Lake
On Dec 26, 2007, at 3:50 PM, Fernando Padilla wrote:
I apologize. I didn't mean to infer that it doesn't integrate
nicely, nor that it's not good. So don't take offense, I was just
doing some uneducated guesstimates on tapestry adoption.
The IoC is actually quite good once you get used to it (except for
the Aliases mechanism which I haven't looked into enough). But I
came from the point of view of, "I like Tapestry, and I'm using
Tapestry". Then I learned what I needed to do to get tapestry to
work, and to work with my spring configuration (quite easy).
But for many people that come in with a mind of "will I like
Tapestry? should I use this or that?". Saying that you have to
learn Tapestry-Core, and Tapestry-IoC, and though it integrates with
Spring, you have to learn a whole new IoC system (to understand and
debug, etc).. well, it could, and probably does, turn a few people
away; even subconsciously. We're already asking people to try out
and trust this new fangled way of coding up their websites, why ask
them to also learn, understand and trust a new fangled way for IoC.
Spring 1.x of course was not up to the job, but it's getting closer
and closer to having all the features of Tapestry-IoC. Tapestry
could win over a few more people by saying that it's built on top of
Spring.
But like I said, I love Tapestry and will stick with it, and support
the developers decisions to get it done. Though I do wish that
there was more adoption..
Thiago H de Paula Figueiredo wrote:
On Wed, 26 Dec 2007 13:07:49 -0200, Fernando Padilla <[EMAIL PROTECTED]
> wrote:
But my guess is that using a different IoC system is really
hurting adoption of tapestry. If tapestry could really integrate
well with spring, then it could be more easily understood/picked
up/recommended by A LOT more people.
Sorry, I do not get it. Tapestry-IoC (and Tapestry the Web
framework too) integrate very easily and seamlessly with Spring.
Your page classes do not even know where the beans are coming from.
What's your problems with the Tapestry5-Spring integration?
---------------------------------------------------------------------
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]
