Thomas Ferris Nicolaisen wrote:
Trim all your mails, darnit! :)
Sorry, will do so in the future. ;)
Using Spring (container) for Magnolia's internal architecture would force a huuuuge amount of refactoring (or so I can imagine), for what? Inversion of control? JSF's backing beans provide basic IoC. And does Magnolia really need IoC? Does it need AOP? Why?
You are correct, the level of effort would be substantial, but I can easily envision a Magnolia 3.0 release with a revised Spring-enabled Ioc/AOP architecture that provides a truly flexible, lightweight solution that can be deployed into any J2EE server environment and easily wired up to leverage different datasources, transaction engines, JCR implementations, logging frameworks, security mechanisms, etc..
I can really see the value of being able to plug in new datasources and be able to choose between web frameworks (that you can plug into Spring), but I'm not sure the devs are ready for such changes.
Agreed. It would represent a new foundation for Magnolia. But Magnolia has also been touting the ability to define modules that plug-and-play with the core build. HA! I don't see that this is really feasible today. Spring would make this a piece of cake.
Remember the golden rules: -Build what you know. -KISS -If it works, don't mess with it. -Don't believe the hype. -Try before you buy.
Always sound advice. Go try the other frameworks, especially Spring. IMO, it's the right answer and would enable Magnolia to gain market share and pick up speed in a huge way (insert pun about Magnolia 'springing' into the market). Although it is the *right* answer, it is by no means the easiest or most cost effective answer. In the end, it may be better to stick with KISS and the "don't mess with it" philosophy. That will have to be left up to the commiters to decide.
-KG ---------------------------------------------------------------- for list details see http://www.magnolia.info/en/magnolia/developer.html ----------------------------------------------------------------
