Hi list
After two months of background thinking and after reading this
article (http://www.theserverside.com/articles/content/
ManagingSourceCode/article.html) today, I think I have finally
understood the current structure.
Good text!
A bit of IoC in there would actually make the dependencies easier
to manager, and if you had 100 engineers to work on the project
it'd be good. :P
Here a good text about IoC (and alternatives): http://
www.martinfowler.com/articles/injection.html
Also, a 20 lines introduction on how to build magnolia using maven
2 and why it's done this way before the next release could boost
your sales (hum maybe..) and the number of contributors !!
This is already documented in the 2.2 branch documentation (more
details are needed but the main steps are pointed out). The 2.2
documentation is available under http://magnolia.sf.net/22 (default
is still 21)
Notes about IoC in Magnolia
===========================
A lot of people in our community pointed us to the Spring framework
about exactly that reason. And I agree that magnolia is not flexible
enough for a lot of issues. Perhaps we do not move to Spring but
could follow some simple principle to do that same thing.
Configure Implementaiton
------------------------
- core components are defined by interfaces
- the implementing class is defined in the magnolia.properties
- therefore we use commons discovery (FactoryUtil) to get instances
Context instead of Servlet API
------------------------------
- as the service locater we use in general the MgnlContext
- MgnlContext is a subclass of the WebContext provided by commons chain
- MgnlContext will NOT provide getRequest(), ...
- MgnlContext.getUser(), MgnlContext.getLanguage(),
MgnlContext.getHierarchyManager(name) are used
- If a component writes output we pass a Writer and NOT the request
Injection (Dynamic Configuration)
-------------------------
- we don't use injection
- the components are implemented so, that those could be used for
injection by setters (providing setters)
- no instantiating of concrete classes in the component
- the beans encapsulates fields (using get and set in the class
instead of the field, all fields are private)
- the getter checks if the field is present, if not it gets the
needed component from the service locator (MgnlContext in general)
- Configuration is then done due subclassing and overriding the
getter method and registering the new implementing class in the
magnolia.properties
Following this easy principles we gain extra power for magnolia with
a minimal of coding.
PicoContainer as an Alternative
-------------------------------
Perhaps it would be easier to use the slim PicoContainer to achieve
our goals, but still we would use the MgnlContext
I hope that I will find some time in the next week to update the 3.0
Concept, since a lot of things are consolidated and clear now.
Regards,
Philipp Bracher
obinary ltd.
-----------------------------------------------------
[EMAIL PROTECTED] http://obinary.com
magnolia content management http://magnolia.info
-----------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
