At some future date I think the community could choose to make a radical change like that — and even call the result “Plone” — but it will be easy only if Plone is a CMS and not a platform for building entire web sites. Which is why I suggest this path to making Plone into more of a CMS and less of a platform. And ultimately that question of how to make a complete website must be answered — another part of Plone’s success is that it answers that question. So right now recreating just the CMS of Plone wouldn’t be sufficient to really recreate Plone.

But at the same time, I’d probably avoid taking this route for new customer projects. Content management features aren’t too hard to create in any of the new crops of Python web frameworks. Writing a form, even auto-generating that form using some framework, accepting input from users, showing errors, managing users, etc: for any given project, satisfying these types of requirements tends to be pretty easy without Plone. It’s often much harder to remove unnecessary features from Plone than it is to create the necessary ones from scratch. It would take a heck of a lot of intersection between a random customer’s requirements and the feature set that Plone provides out of the box for me to use Plone as the “CMS”, and delegate other tasks to a simpler system. I’d tend to just use the simpler system for everything, left to my own devices. That said, for legacy systems that already use Plone, I’d likely go with Content Mirror.

IMO, the killer feature of Plone that no other “framework” has is that it does something out of the box. Folks who install and use it can quickly get a frame of reference quickly, and they can describe (to themselves or others) requirements in terms of modifications to that out of the box experience. And for better or worse, people tend to do those modifications to Plone to satisfy the requirements. So it drives a good deal of consulting business.

So how do we square the circle? I’m not sure. But I don’t think too many tears would be shed if something else were created that was materially simpler and offered some similar set of features out of the box. I suspect that a phoenix-from-the-flames project that aimed to recreate a Plone-ish out-of-the-box experience, but which ditched backwards compatibility would probably be most successful in the long run. There are of course Plone add-ons and such, and these are important, but even without those, an alternative could probably support a healthy community. It shouldn’t be called Plone, obviously. This of course mirrors what we’re doing with bfg vs. Zope, so I suppose my saying any of that is not very surprising.

The first is, that adaptation is overused. A portlet is a five-way adapter and there’s no way to change the adaptation order. This rules out a swift solution for most of the more advanced use-cases, simply because you’d have to work very hard with the system to get the adaptation pattern you really want. Adaptation as we know it is simply not a very good multiplexer.

The second issue is that we can’t really ever strike the right balance between explosion and coherence in defining the scope of a component. The best example I know of this is the navigation machinery. This is implemented as a collection of components that each have some scope and function and they’re glued together using the component registry. However, in most cases, I’ve wanted to simply provide a replacement wholesale, and in this case, the exploded code chain is counterproductive and needlessly complex.

To recap, I believe the correct usage of components is to adapt on small specifications, with one-way or two-way being standard, avoid adaptation for multiplexing where possible and finally to avoid exploding our software into too many components. We still have object-oriented programming and Python is still a dynamic language.

As Carlos suggests, I think ContentMirror could be part of that story. The more formally “correct” solution might be web services of some sort, but I think a relational database mirror is probably better understood and less likely to cause performance problems due to its implicitly async design.

I personally believe that Repoze and Grok are both key to Plone’s future. Roughly, I think the roadmap should look something like this:

• Rip out things we no longer need (already happening on trunk).

• Where two ways exist to do something, choose one way and remove all other ways (starting to happen on trunk).

• Target key use cases for extending Plone-the-application and focus on making these as easy and friendly for integrators as possible (this is where I think Grok conventions and patterns will be beneficial). This includes things like:

  • Making new content types
  • Writing new UI components (e.g. views, viewlets, portlets, or some unification thereof)
  • Customising templates
  • Customising the security/workflow model
  • Writing events-based things, e.g. code that executes when objects are modified or whatever

• Push services that could cross-cut applications out into WSGI middleware so that they become reusable (this is where Repoze comes in)

• Promote the use of other, WSGI-enabled frameworks for non-CMS tasks (be that repoze.bfg or Grok or something else)

• Promote a way to unify look-and-feel/theming (this is what Deliverance promises).

I whole-heartedly agree with Martijn’s point about evolution. Developers have a strong tendency to favour a rewrite or a clean break, but that’s a sure way to lose those who’ve already invested in the platform. We’re only just now coming to the point where the feature set and the available tools and frameworks cover what I’d consider the basic CMS needs (with a few exceptions), and there’s a real drive in the community now to focus on simplification and the integrator experience.

At the same time, we need to be very careful about throwing the baby out with the bathwater. The Zope 3 CA has an important part to play in making Plone a productive, usable and flexible system. People may not be clamoring for more power, because they have power now. We’d like to unify the way in which that power is provided (e.g. by removing some things that still rely on acquisition when it should rely on components), not take it away.

We also need to be better at indicating what extension points and APIs are aimed at integrators/developers and what things are really just the concern of Plone’s core developers. Right now, “the API” is kind of the whole application, in that you can customise and change anywhere. We need to ring-fence that with something a bit more obvious that gets people started quickly, and only require them to get into that level of detail if they really need to.

Cheers,

Martin

Granted, this is not an approach that can be used for all kinds of projects, but there are many use cases where separating the content production from its delivery would be a very good idea. Plone is a very good CMS, so I think it would be great if people not willing to use it as a framework can still benefit from it as a piece of software. That would make Plone, the community, even bigger.

Grok’s busy extracting useful bits of code from itself and both Martian as well as grokcore.component are reusable in random Python projects. The rest of the grokcore.* stuff is reusable in Zope 2 and in fact reuse in Zope 2 is driving this process.

You say the use of the component architecture is a step in the wrong direction, but could you be more explicit about why this would be so? What if you use it in moderation? Some form of customization machinery is needed and sticking to the (well-engineered, much used, battle-tested) devil we know seems like the right idea to me.

It’s important for any scenario to move forward is to have a way to evolve from A to B. You can take risks in this evolution, and perhaps larger risks should be taken, but it still will have to be an evolutionary step.

The word “simple” means different things to people. Simple in implementation? Simple in use? Simple to change? Assembly language is simple in implementation and Python adds huge amounts of abstraction and automation over a machine. Yet, Python’s a lot simpler in use than assembly language, even though assembly is so much simpler in implementation. So, of course automation and abstraction can be added to a system to make things simpler! That said, implementation simplicity can increase usage simplicity as a system can become easier to understand and predict, but it’s hardly clear-cut. Simplicity in implementation is valuable when it increases simplicity of development, and simplicity of use.

So, I’ll grant there is value in simplicity in implementation. I also believe Plone’s implementation can be significantly simpler. It’ll still be complex no matter what, though, just less complex than it is now. Any move to simplify Plone will run the risk of trading off one form of complexity for another. There is also value in sticking to the complexity the community knows about.

I believe Plone’s best road to simplification takes two paths:

• Towards simplicity of implementation: removing some of the old ways of doing things permanently. Hopefully a point in evolution has been reached that old things can be removed. The removal of acquisition from the system would be a good, though big example. Allow content types that are truly simple and don’t rely on SimpleItem and a whole bunch of other things would be another good step.

• Towards simplicity of use: adding easier ways to do things that are too hard right now. Using Grok technology to help with the wiring of the inevitable configuration machinery is a good example.

The alternative would be writing a new CMS taking into account the lessons learned from Plone. That’s an interesting project. Is it the Plone project?