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.
We will not use JSF or it's brothers for the admin interface (the trees
..). AJAX does not really fit into those frameworks. But for this we
would use DWR (JSON-RPC, XML-RPC) to standardize this mechanism. JSF
would be used for the dialogs only.
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.
Definitely something we must think about.
Rather than changing to another framework, maybe just adding more
documentation on the existing framework could help.
;-)
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.
The question is:
Can we implement those features easier within a refactored Magnolia?
Where is the lack?
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.
No, I used 100% magnolia. At least this shows what would be possible.
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.
Documentation! Our problem is the time and cost, but we know the need
for this. There is a new commiter doing only some documentation (I hope
he finds the time to improve the current).
Philipp Bracher
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
