Em Sat, 19 Dec 2009 18:26:32 -0200, Piero Sartini <[email protected]>
escreveu:
Of course, we could invent solutions on top of tapestry-ioc that would
be as good or better..
but then, why re-invent the wheel?
I'm not advocating widespread wheel reinvention, but sometimes the
existing wheel doesn't do what we want or need.
Tapestry-IoC, as stated in its website, was created because Spring doesn't
support distributed configuration, a feature needed and used in Tapestry.
What I miss most in tapestry are remote services, transactions and
support for JPA.
I miss transactions support, the only reason I'm still using Spring.
The question is if we will bake all this ourselfe or integrate with EJB3?
It's not a good idea to force one framework (EJB3) to the users of another
framework (Tapestry, Tapestry-IoC). But it's a good idea to add support
for other frameworks.
To be honest, it does not matter what is the strategy behind this.
Fact is that both of these JSRs are part of JavaEE 6.
A nitpick: JSRs 303 and 330 are targeted at Java SE, not Java EE.
I totally agree that standards are not the solution for everything and
innovation needs to break out at times.
But.. standards are useful and important if you want to take advantage
of things you can't offer yourself.
Point taken. :)
Hey.. after all we talk about Java. And one argument for a Java Web
framework is integration with the rest of the huge Java ecosystem,
isn't it?
Yes, it is. We just need to the pros and the cons of each of this
integrations.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
