Plone front end other front end

by Carlos A de la Guardia

Why Plone?

  • all the great features
  • built on python

Problems with Plone

  • Complex
  • Hard to extend
  • Can be slow
  • Plone does a lot of things
  • Forced to use caching
  • Caching is not always the answer to traffic
  • Sometimes we are asked to add a couple of features that are Plone-y
  • Easy to end up with Frankenplone
    • Becomes very hard to extend and maintain

Content Mirror

  • Developed by Kapil
  • Serializes plone content into a relational database
  • Supports 3rd party / custom archetupes content
  • Simple to set up
  • completely automated
  • Works currently with 3.1
  • Configure the database via ZCML
  • Works with Oracle, PostGreSQL, and MySQL. I guess anything that SQLAlchemy
  • easily extended
    • CouchDB anyone?
    • GAPE!

Now we can

  • Use plone to manage content and manage workflow
  • Serve plone content fast

How does it work?

  • Integrates into the Plone event stream
  • Uses SQLAlchemy to turn Plone schemas into tables
  • Each Plone content type gets its own table
  • Each custom content type gets its own table
  • Once set up, content changes are sent synchronously to the database

Several created front ends

  • Repoze.bfg
    • Lots of Zope styles
    • Much lighterthan-Zope infrastructure
  • Plango uses Django to generate Plone content