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]
