I completely agree with you, and I really wish Spring were up to the task. However, Howard seems to have done his homework and come to the conclusion that it can't provide the features he needs for Tap5 (see http://tapestry.apache.org/tapestry5/ioc/index.html).
In my personal ideal world, Spring would have implemented the namespacing, abstraction, visibility and distributed configuration features he needs, and we could all reuse our Spring knowledge when we find we need to extend Tap5. At this point all I can hope for is that they implement some of that stuff in time for Tap6 :-) On 7/28/06, Rui Pacheco <[EMAIL PROTECTED]> wrote:
Actually, I support the idea that leaving HiveMind is good. But not for a new IoC container. We should be using something that has more market share, like the Pico Container or the container used by Spring. Why are we writing a *new* IoC container? Why not standardise Tapestry, that does something no other framework does, on components known throughout the developer community? Its all about reuse. Reuse components, reuse examples spread through the web, reuse the knowledge you acquired on different projects.
