Em Sat, 27 Jun 2009 05:34:09 -0300, Piero Sartini <li...@pierosartini.de> escreveu:

I expect the T5 IOC to live well beyond the web framework portion.

T5 IoC is very powerful.

Yes it is. And it's a pleasure to use.

But at this point I am not so sure if Tapestry IoC is the best answer to
flexibility. Take a look at Struts2 - they are able to switch their DI
implementation by configuration.

I would agree if Tapestry-IoC wasn't flexible enough to support integration with other IoC/DI frameworks, but it is. Hint: take a look at the T-IoC' ModuleDef interface and how it's used in tapestry-spring.

This brings them a lot of possibilities and integrations with third party
frameworks / products that I do not see for tapestry.

Could you give us some examples of what possibilities and integrations with third-party frameworks or products that you do not see for Tapestry?

One could argument that this is a much more flexible approach than relying on one DI container.

I don't think so. Look at how Spring is supported in Tapestry: it's absolutely transparent. When I need some Spring bean in my page, component, mixin or service, it is injected as if it was a Tapestry-IoC defined bean (service). My projects are built with Tapestry and transactions are handled by Spring-TX. In the future, when the Tapestry project will have it's own transaction support, my only changes my project will need are changing the Spring's @Transactional annotation for the corresponding Tapestry-TX annotations (which I guess will be the EJB 3 ones). Anything that needs my services/beans will not change.

Tapestry very flexible architecture needs an IoC framework. Otherwise, it would lose a lot of power, simplicity, convention over configuration and

--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to