One thing that HiveMind does that Spring does not is configurations. Spring doesn't have the rich configuration facilities that HiveMind does. Don't get me wrong. I love Spring. That's why I use the Spring transaction/ORM stuff within HiveMind. To borrow a phrase from Howard, it's all just "object soup." So, it wasn't very difficult to adapt the Spring stuff, because it just relies upon dependency injection, which HiveMind does quite well. I had to write the OpenSessionInView stuff the "tapestry way." And, I had to write the SessionFactory building logic the "HiveMind way." The one thing that we need in HiveMind is support for AspectJ. I'm working on that. :)
-----Original Message----- From: Mark Arnold [mailto:[EMAIL PROTECTED] Sent: Sunday, April 23, 2006 4:44 AM To: Tapestry users Subject: Re: I have a dream... I know that HiveMind is more than the web-frontend and that you can use it through all the layers of your application. That's not what I meant to say. I probably should have said - and please note that I started this sentence with "as far as I am concerned" - "Hivemind will only be used for the web front-end", that would have been more proper. It makes absolutely perfect sense to use IoC and dependency injection and once you have gotten used to it, you don't want to live without it. What I mean is this: from what I know of Hivemind and Spring, Hivemind seems to be mainly (and "only") doing IoC, dependency injection, instanciation configuration, etc. If that is true, then it does the same thing as Spring - BUT: Spring does a lot more. It has sub-frameworks and integration mechanisms for persistence (ORM and DAO), AOP, remoting (JNDI, EJB, WebServices), web framework integration (unfortunately not for tapestry [yet?]), validation, and more. Many things that people try to add on to Hivemind for example through the HiveTranse/HiveUtil project is already there in Spring. Assuming that my perception of Hivemind is right so far, there is really nothing in Hivemind that I could not do with Spring. Secondly, I think it is fair to say that Spring has a much broader support and acceptance. Big frameworks like Acegi, ServiceMix, Mule, etc have support for Spring, use Spring internally, or the other way around, Spring has integration for them. With this perception in my mind, I really see no reason for using Hivemind, except - well, I will deal with it as much as I have to in order to be able to handle and integrate Tapestry, because I prefer Tapestry as a component-based web architecture over the alternatives (Struts, SpringMVC, etc) that Spring already supports. So if you have a web application that just needs to do a bunch of Tapestry pages and some Hibernate persistence layer, HiveMind is the way to go, because it's probably just not worth the pain of trying to get Spring involved. But for big enterprise applications it's a different story, I think these will have a huge benefit of chosing Spring over Hivemind. My entire application will be based on Spring. That's why I was saying in my previous email: as far as I am concerned, Hivemind is just used as web-frontend. I would expect that I am not the only one who thinks like this. Spring is being accepted by many (big) companies for commercial projects. Companies are paying a lot of money to hire Spring-experienced developers, consultants or send their employees to Spring training courses that cost several thousand Dollars for a 3 or 4 day class. I don't think Hivemind is anywhere near this level of popularity. There are way more resources for Spring than there are for Hivemind as far as documentation (books, tutorials, sites, forums) and tools are concerned as well. This is why I think that one of the most important things that could be done in order to gain a wider acceptance of Tapestry is have a better integration with Spring - either by Spring offering a Tapestry-bridge or by Tapestry adding a tighter integration-layer for Spring. So that's where I am coming from - hope I clarified my earlier email with this... MARK > HiveMind is not the "web front-end." HiveMind can be used in all tiers of > your application. HiveMind has nothing to do with Tapestry. Tapestry just > uses it to wire all of its pieces together and configure itself. > > > -----Original Message----- > From: Mark [mailto:[EMAIL PROTECTED] > Sent: Saturday, April 22, 2006 2:33 PM > To: Tapestry users > Subject: Re: I have a dream... > > How about tighter Spring Integration? > There is a bunch of things that exist in Spring as well - transaction > handling, validation logic, Hibernate session handling, etc, etc. > > As far as I am concerned, Tapestry and for that matter Hivemind is > really only the web front-end, not the core. > If you are building real enterprise apps, there is much more than the > web front-end. > There can be interaction via Messaging, Web-Services, etc and in that > case all the same functionality (Transactions, HibernateSessions, > Validation) is still needed. > > So in my opinion, there should be a better integration into Spring and > usage of what Spring already has today. > > And to answer one thing before somebody even brings it up: I don't > think this will degrade Tapestry, I think it will on the contrary give > Tapestry an even stronger argument why developers should use it, even > and especially for big enterprise applications. > I am just starting my first experimental project with Spring, Hibernate > and Tapestry and besides the really steep learning curve for each of > these 3 projects just by themselves, these integration issues are > exactly the problems I will be facing soon. > > > MARK > > > Andreas Bulling wrote: > >> ... that one day we have a solution to this repetitive problems with >> Hibernate/sessions/transactions/demarcations/etc. which is >> >> - flexible enough to allow different usages (with/without manual >> > demarcation, > >> session-per-request/-conversation, ...) for the people with their >> > different > >> needs >> >> - at the same time mature and stable enough to handle Exceptions and >> special cases >> >> - 100% Hivemind-/Tapestry-compatible >> >> Did I forget something? If yes just add your points, perhaps we can create >> something like a list of wishes for someone implementing this some day ;) >> >> *BIG SIGH* >> >> Andreas >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
