> Because there are some people who would like to use a lightweight > container instead of a heavy one?
Spring is a lightweigth container. You can use as much or as little as you want. You determine the weight of the container by your needs. It's dependencies are only as extensive as your needs. The core library is very small. On 4/23/06, Mark <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
