Why Plone architecture must change


I proposed a conference on this theme but it was not keeped for PloneConf2008. Here comes a short work on its, and I will hope it create a debate.

Plone is born with a goal: make Zope 2 and CMF simple. Those two are frameworks and allowed you to create a website… a so rustic website. With Plone you only needed to fill one form to have a cool site ready to use and to custom. At that time Plone was CMFPlone, an other implementation of CMFDefault.

Some new products were inserted in the bundle like GroupUserFolder in a such way that they cannot be separated from the base implementation of Plone.

The second step was the Archetypes framework: a new manner to manage object’s attributes as schema. With all informations stored in the schema,  mutators and accessors are generated on boot time and forms are generated from schema’s widgets. It was cool, but not perfect. Then the product ATcontentTypes was created to be the glue to upgrade CMFPlone as Plone: all base types from CMF are now overloaded by a type from ATContentTypes.

So came Zope 3 and Five. Five is the glue that allows Zope 2 developpers to use component architecture from Zope 3 in their code. Plone 2.5 and Plone 3 are using Five.

Another product came from Zope ‘renegades’: PluggableAuthService and its implementation in Plone: PlonePAS. It should replace the old GroupUserFolder but users and groups management templates were never refactored.

Plone 3 introduces new component in plone.app to our greatest happiness.

What part of Plone needs CMF?
Why Plone needs to know about Archetypes storage and CMFEditions strategy?
Why GroupUserFolder is always in the bundle as PlonePAS fit is API?

Now Plone is like the linux kernel: a big monolithic Plone with a lot of modules that create a base Plone 3 site. And so much glue! GroupUserFolder is always here because nobody knows and wants to work on the portal_group replacement.
If you are following Plone4Artist or PloneGov you can see that a part of these projects needs to overload Plone base configuration.

CPS 3, an other CMF-based CMS, was conceived with the thinking that components need to be independant to be reusable and maintainable:

  • CPSSchema depends only on Zope
  • CPSCore depends only on Zope
  • CPSDocument depends only on CPSSchema
  • CPSDefault depends on CPSCore and CPSSchema, and implements the CPS site.

After 2 years it was divided into platforms:

  • CPS Legacy
  • CPS Courier
  • CPS Groupware

In front of that Plone propose at single product with a lot of glue that depends on others products or components that use their own glue and so on…
There’s no plone.core and plone.default and we cannot create a plone.artistsite or a plone.govsite.
Do you think that everyone need an openid or an ldap integration in Plone ?

Plone 4 must be a reimplementation, not only a new glue with new concepts. I don’t want any new functionality in Plone 4, I want modularity and scalability.

12 Responses to Why Plone architecture must change

  1. Paul Everitt dit :

    +1, both to your analysis and your recommendation.

  2. garbas dit :

    « Plone 4 must be a reimplementation, not only a new glue with new concepts. »
    +1

    hope will see some of your concepts in plone4. sometimes step back is actually a step foward.

  3. Hans-Peter Locher dit :

    +1
    Otherwise the confusion will extend …

  4. guy dit :

    “Plone 4 must be a reimplementation, not only a new glue with new concepts.”

    « Do you think that everyone need an openid or an ldap integration in Plone ? »

    +2

    Well said. Plone has become a clunky Behemoth. Sometimes, you just want a website.

  5. Martin Aspeli dit :

    Plone 4 is going to be a lot slimmer and have a lot more bits be optional. Take a look at what’s happening in trunk if you’re interested.

    GRUF is gone, by the way, as is most of the monkey patching in PlonePAS. Content rules, OpenID (I think), Wicked, a lot of the translation stuff… all is becoming optional and sucked out of the core.

    It will not be a re-implementation or re-write. That would be supremely stupid, and probably kill off Plone as we know it.

    Plone 4 will come with some exciting new features. Without that, we wouldn’t be able to attract new users and keep our reputation for innovation. People are still working on things that interest them, and some of those things deserve to be in future versions of Plone. Stopping those types of contributions would be counter-productive in the long run.

    Martin

  6. Thomas Massmann dit :

    Exactly my point of view.

  7. Malthe dit :

    Hehe, that’s pretty cool garnering comments from a repost. Anyway I agree with Paul that the analysis is spot on and presented in a nice, clear way.

    Since October, when this was posted, a lot of things have happened, in particular in the repoze family of no-nonsense software. I think this is a much more exciting place to be than in a proposed Plone rewrite effort, and actually, Plone benefits from repoze, too.

  8. Erik Rose dit :

    Plone 3 actually reminds me a lot of Mac OS 9: a very successful and usable system for end users that is an everloving pain to code for due to layers and layers of legacy. I would be happy even if Plone 4 took a functionality hit (like the first versions of OS X) in exchange for easier feature development later on. However, I think 4 is likely to be both more featureful and more maintainable.

  9. encolpe dit :

    I’m sorry for the repost: I added a missing keyword in several posts and some feed reader put them as new.
    For the point, I am agree with Malthe and Erik: the situation since october evolved in the good way. As usual the core developer team is doing a great job to release the 3.2 and the 3.3 will be exciting. But before all, the documentation team is doing a wonderful job reviewing two years of unapproved articles on plone.org and in refreshing all the documentation hierarchy.

  10. Hello

    Great post! +1.

    I believe we should envision Plone 5 as a Pure Zope3 application.

    Kind Regards
    r.

  11. Malthe dit :

    @robert: it’s a matter of buy-in; with Zope 3, like Plone, you need almost 100% buy-in to leverage the power of the framework. That’s difficult when the codebase is so huge.

    Perhaps repoze.bfg is a better match; it provides a small footprint and easy to understand base concepts.

    At any rate, Plone is not a moving target in the sense that it can easily be ported to a different platform. It’s a Zope 2-application through and through.

  12. David Mendez dit :

    At last! Someone makes sense of this Plone business. I’m having so much trouble making the simpliest of things, and since there is no real standard or a complete and reliable architecture reference I don’t understand part of what I’m doing. You are so right that Plone 4 should be rethought and made a lot more carefully. I applaude you!

%d blogueurs aiment cette page :