Sometimes missing features is not a bad thing. If you want people to use your framework, you need to implement something they can use. Maybe losing some features and gaining some compatibility isn't such a bad thing. The rest could come later. This is not a race.
On 7/28/06, D&J Gredler <[EMAIL PROTECTED]> wrote:
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. >
-- Cumprimentos, Rui Pacheco
