Hi all,
Skolelinux has decided to drop Plone and use eZ Publish instead, both for the project website and a recommended CMS for schools.
No final decisions made, but we are looking strongly into it.
As I understand it (from the short meeting on the topic I participated at the Skolelinux gathering in january) some reasons are political (bad support of Skolelinux from core Plone guys, promise of good support from eZ guys), and some reasons are technical.
Can anyone please help provide details on the technical shortcomings of Plone?
Excerpts from "Summary of last week's meeting with eZ", to which you replied:
First and foremost, the workflow is cumbersome. For several reasons I won't dwelve too deep in, translators of content today have to manually make a new instance of the page in question, and then send an email to one or more mailing lists to inform about the change. This, obviously, isn't optimal. It would be way better if the CMS could automatically notify the right mailing lists and inform about the changes. eZ features this.
Secondly, to edit a web page, one has to log in with the Plone webinterface. (Yes, I know of the FTP-interface. It's way too buggy.) This alone scares a lot of potential contributors -- mainly the core developers -- from doing changes on the webpage at all. While this isn't necessarily true for everyone, it is a nuicance not to be able to work with the tools they preffer, which obviously is discouraging. eZ has support for WebDAV, and B�rd Farstad is looking into adding support for Subversion in eZ, based on our request.
Thirdly, eZ has a more sane way to handle content than Plone has. Plone gives you -- by default -- three options: to save the document as plain text, as HTML or as "structured text" (Zope-thingy). Once you have chosen a format, you have to stick to it. eZ saves everything internally as XML and offers only a *subset* of the HTML-code to the user. This enables them to create various input- and output-filters, so a document first edited by Joe in OpenOffice can later be edited by Jane in HTML -- and downloaded as a PDF for the web user.
In addition, it's hard to sync the excellent documentation we have available, such as the "ICT-manual" and Klaus's great collection of notes, from DocBook in CVS to the web. Obviously, we don't want to change their working repository, so we want to be easily able to /sync/ content from one source to the other.
Since the meeting, I have been busy with exams while letting people discuss the requirement specifications[1] which I posted to the www-int-mailing list. B�rd Farstad replied and said "check" to most of the requirements listed, but was a tad vague on a few points -- mainly regarding Subversion support. I replied a few days later to clear things up, but he hasn't replied yet. He just got a daughter, so I guess (hope :) she has his priorities. :-)
I have now begun setting up a testbench to try to learn more of eZ, and to figure out in more detail what we eventually need eZ to do.
Please note that, contrary to what you have expressed several times, we have *not* ultimately decided on eZ, but they are offering their professional help with a system that seems to solve the problems we have. As mentioned earlier; if somebody else want to do so, they are free to come up with an offer.
~
[1] http://developer.skolelinux.no/dokumentasjon/requirement_specifications_ez.txt
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
