Ok, I see you point.
So then it would have to be done in a way that lets you chose which way
to go. Which would really cause additional work...
But it would be cool if there would be interfaces for certain
functionality and then you could configure whether you want to use the
hivemind implementation that comes with Tapestry, or the Spring-based
implementation that requires the spring jars.
Or it should really be Spring providing the integration of Tapestry into
their Web layer support...
Andreas Bulling wrote:
| The other thing is - instead of adding new things from scratch, why not
| use Spring, for example the way James says he has done for Transactions
| and ORM (I haven't seen his code yet).
Because there are some people out there (including me) who don't want to
put the whole spring stuff with it's dependencies into their application?
Because there are some people who would like to use a lightweight
container instead of a heavy one?
And so on, and so on...
| It will save the people who do the implementation a lot of time and it
| will save the user from having to learn yet another different way of
| doing something using a Hivemind add-on that he already has or knows how
| to do in Spring.
Well, I don't think so. ;)
What I can tell from other OpenSource experiences (from the Linux environment)
on the contrary it's most of the time very_ good to have at least two
different/competing implementations to allow the people to _choose_.
IMHO this is one of the greates strengths of OpenSource software:
That it allows people to choose which software fits them best even if
they have to learn several ways of doing things (its the same with
JSF, Tapestry, Struts by the way).
You are right that one would have to reimplement already available code
but perhaps some day the Spring code is missing some interesting feature
related to Tapestry and no one of them is willing to implement it or
they don't want it at all. Then you will be happy to have an
alternative which fits your needs and which has been developed
by people who are probably more interested of getting things done
for you then the Spring people are. You never know ;)
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]
