Hi-
Thought I'd throw in my 2 cents as well. ;-)
Changing the frontend framework would certainly be a major effort.
If you don't want to loose usability, whatever gets chosen as a
framework, has to provide the same tight JavaScript integration and
dynamic cofiguration options we have today. AFAIK none of the
frameworks that have been proposed here, can do this out of the box.
For example AJAX Renderkits for JSF will probably be available sooner
or later, but I'm not aware of one that is feature rich and mature
enough to be a viable substitute for what we have now.
The main reason for dumping what is currently there has been that
developers don't want to learn Yet Another Framework. As none of the
frameworks around currently has the features already in Magnolia, a lot
of new code will have to be written. Code you will have to know if you
want to modify the frontend, so in the end developers will have know,
say JSF plus the ins and out of the Magnolia RenderKit plus all the
other additions necessary to emulate the current behavior. I wouldn't
be surprised if in the end the learning curve for getting into
devolpement would be even steeper than it is today.
Rather than changing to another framework, maybe just adding more
documentation on the existing framework could help.
As far as changing the core to spring is concerned. Why would you want
to do it? Again this means a major rewrite of Magnolia. And what for?
Extensibility of Magnolia would be a good reason. But so I'd rather
like to see the requirements for a module interface specified first. If
it then turns out that it requires a complete redesign of the core and
using spring as a framework makes things easier, let's use it.
Both steps mean major efforts, binding lots of developer resources,
probably cause a lot of instability for the next releases (both API
wise and in terms of runtime stability, as mature, well tested code
gets replaced by new code). On the other hand, Magnolia still lacks in
important features. The publishing mechanism still needs transaction
capabilities, there is no content locking, no versioning, no link
management, etc. All important features of a content management system,
and in my experience the main reasons why people opt against using
Magnolia.
All in all what would be interesting to hear are the experiences with
creating the currently existing modules. The DMS was supposed to be
using JSF, for example.
The refactoring to support workflow will probably help as well. Once
all cms functionality is clearly factored out, you should be able to
change the frontend to whatever suits your needs.
What I would definitely like so see is more discussion on how to add
your own modules to Magnolia. Again documentation on the module API
would be a step in that direction.
Both JSF and Spring are great frameworks. But don't forget that
Magnolia is first of all a Content Management system for people to use
and not a showroom for the latest and greatest in Java Enterprise
technology.
-markus
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
