The argument against HiveMind is not against HiveMind, per se. It's about Tapestry adoption. Tapestry already has a battleground: the web framework space. By combining it with HM it now has two battles: web frameworks and IoC/lightweight-containers. While opting for its own built-in IoC container implies it has abandoned the entire "do one thing well" principle of most successful framework projects.
The only technical argument for HiveMind is one of features. I think that's a call to extend Spring. Technically do-able and a win-win. I think the real decision about HiveMind may be ego. That is, we all tend to start identifying with the things we create and its hard not to. As to why Tap4->Tap5 is important, simply look at Tap3. It is less "supported" -- there's less active work in terms of enhancement, etc. going on in Tap3. Yesterday we didn't want Ajax. Today we do. Tap3 works for yesterday's apps but to add today's features Tap4 (4.1, in particular) is significantly superior. Tomorrow we'll likely face the same thing, something new only being supported in Tap5. So upgrade paths are important considerations when making an adoption decision. Thanks, Ezra Epstein -----Original Message----- From: adasal [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 3:49 PM To: Tapestry users Subject: Re: Tapestry 5 Discussions Seems I am wrong in my earlier post. Emm, but there is a lot of discussion around the need for compatibility. Why is it so desirable, it seems to posit a large ongoing project that spans both 4 and 5. Why would such a project need to hook up to 5? Adam On 28/07/06, Kris Rasmussen <[EMAIL PROTECTED]> wrote: > > I actually prefer hivemind to Spring. Just my 2 cents. I find it > easier to learn and better at what it does. > > Kris > > > ----- Original Message ---- > From: Rui Pacheco <[EMAIL PROTECTED]> > To: Tapestry users <users@tapestry.apache.org> > Sent: Friday, July 28, 2006 3:23:34 PM > Subject: Re: Tapestry 5 Discussions > > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
