concept for future magnolia (possibly 3.5)
(MAGNOLIA-587)
|
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Sub-task | Priority: | Major |
| Reporter: | Philipp Bärfuss | Assignee: | Unassigned |
| Resolution: | Outdated | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Date of First Response: | |||||||||
| Description |
|
From time to time the community motivated us to use Spring framework as the base of magnolia. |
| Comments |
| Comment by Philipp Bracher [ 09/Dec/05 ] |
|
After introducing the FactoryUtil (commons discovery) and the MgnlContext (neutral application context) I think we can wait for this migration. With this new approach we can make magnolia adaptable very easely. All the major classes like Cache, ... should work this way and allow a custom implementation.
The implementing class is defined in the magnolia.properties. MgnlContext allows more neutral interfaces without passing the servlet objects all the time. Different implementation of the context are possible (workflow, ...). Not using Spring gives us more flexibility and does not cost us a lot. Since we will use DWR and Wicket we could not benefit enough. |
| Comment by Philipp Bracher [ 12/Jan/06 ] |
|
After looking at the PicoContainer and Spring itself, we decided to use spring core to use IOC (and as a side effect to get AOP too). We will not use other parts like spring MVC (very cool, but we need a control oriented framework like JSF) Main candidates for getting a spring bean:
We will introduce it stepwise |
| Comment by Oliver Lietz [ 12/Jan/06 ] |
|
Good to hear about Spring. If you don't want to use Spring MVC what's about Tapestry and Tacos (components and AJAX for Tapestry)? Tapestry integrates well with Spring. Spring is also a good choice because it's easy to connect Flash/Flex clients (eg with OpenAMF) to the business layer. http://jakarta.apache.org/tapestry/ |
| Comment by Alexandru Popescu [ 12/Jan/06 ] |
|
The web approach has been discussed longly (I guess you can find something under ./alex |
| Comment by Ramon Buckland [ 16/Jan/06 ] |
|
Excellent decision guys. We have been thoroughly impressed with Spring up to now. Good job! |
| Comment by Oliver Lietz [ 08/Feb/07 ] |
|
Instead of using the classic Spring Framework/IoC/DI features I suggest to evaluate Spring OSGi http://www.springframework.org/osgi or OSGi http://www.osgi.org/ in general. Magnolia is more a framework than an application. Here are some points why not Spring for frameworks: http://tapestry.apache.org/tapestry5/tapestry-ioc/index.html. The modularization capabilities of OSGi would be quite useful for Magnolia's modules. |
| Comment by Philipp Bärfuss [ 03/Dec/13 ] |
|
Today we have perfect spring support by the blossom module. |