A presentation to the Dutch Plone User Day (Gebruikersdag) in Arnhem, Netherlands in Sept 2009.
This roadmap details the current state of Plone, and the plan for the upcoming release of Plone 4 and the future Plone 5.
41. LINES OF CODE
1200000
1144322 1147545
1122261
1100000
1000000
960456
916360
887059
900000 867263
800000
3.1
)
)
)
3.0
3.2
)
-26
-17
-14
-09
-02
-03
-01
-05
09
09
09
09
20
20
20
20
k(
k(
k(
k(
n
n
n
n
Tru
Tru
Tru
Tru
Lines of Code/Tempates for Plone including the CMF and Zope stacks
42. 1,200,000 1147545
867263
800,000
400,000
0
3.0
nk
tru
68. Plone Conf
Have Fun!
➡ Meet other Plone users
➡ Chat with Plone developers
➡ Drink beer!
Editor's Notes
I’m going to take you through the vision for the next couple of major releases for Plone.
Netherlands highest number of Plone companies per capita?
Fourdigits, Pareto, Zest, Infrae, Goldmund...
Actually this talk was mainly written by these two guys, Geir Baekholt and Alex Limi
This roadmap has been presented at European Plone Symposium & Plone Symposium East
Goal of 3.x: Stability, predictability, maturity.
3.3 has shipped now
Stability comes at the cost of innovation. We cannot do innovate within the scope of Plone 3. That would break the promise of stability.
So, happy as we are with Plone 3 — time to get innovating again.
Plone 4: a cleanup/infrastructure release
Bringing in some of the great work from Plone trunk earlier than Plone 5
Will have new features, but stuff that is stable now.
Features that are too big for a 3.x release. (i,.e require migration, compatibility changes, might break addons)
Not experimental
Plone 5: Redefine how content management is done
(Until recently known as Plone 4 — confusing, we know ;)
So, let’s talk about Plone 4 first.
This is mostly a cleanup release, with some infrastructural changes.
We decided to make a Plone 4 release, goal is end of 2009
Not as radical as the work on Plone trunk
Will have new features — but stuff that has stabilized through community usage.
Features that are too big for a 3.x release. (i,.e require migration, compatibility changes, might break addons)
With release manager Eric Steele, who should take special care to make sure there are more high-resolution images of him available on the web.
This is a list of what has been PROPOSED at this point, not what will necessarily land. :)
As there is a formal proposal and review process, code to be written on a volunteer basis, and a general lot of uncertainty here — let’s see all of this as speculation, guesswork and hopes.
PLIPs
BLOB support is the big deal in 2.11
Python 2.6 if we go for Zope 2.12, which I think we should aim for (better unicode memory management in Python, eggified Zope, etc)
Bug fixes and updates
Widely used visual editor.
The new editing UI for Plone 5 will also be based on TinyMCE.
Plone integration already exists. (Four Digits)
You will still be able to use Kupu with Plone 4, of course. We’ll just switch the default. Also, we won’t change your existing setup when you upgrade — unless you want us to.
Proper support for BLOBs
Store binary objects outside the ZODB, on the filesystem
Tested. Jarn has this running in a 7000 employee intranet.
Fewer hacks like SecureMailHost.The built-in Zope mailhost is now more advanced than this one. Better for us to have less custom stuff to maintain.
plone.app.upgrade
Upgrade machinery. replaces the suboptimal reinstall button in the current add-on quickinstaller.
Makes it simple for product authors to define upgrade steps between versions.
Newbie (limited/restricted user) — possible to make adjustments to UI and otherwise for certain users.
Site admin is a not-fully-fledged admin that can do things like manage users, but not things that can affect the site configuration (ie. install add-ons).
Stuff like Gloworm
Commenting is one of the original cool features of the CMF and Plone — but it is way overdue for revision.
Currently a Google Summer of Code project.
Martin has made some interesting improvements here, ability to require a revision note, etc. Simple, non-intrusive, low risk.
Port over the typography from the new plone.org design
Make it color-neutral, so simple customization like adding a company logo always looks good
OK, time to talk about the exciting release, Plone 5
(I refuse to call this Plone trunk ;)
Release manager Hanno Schlichting
Three pillars of Plone 5:
Approachability means that it should be easy for new developers to pick up
Replacement for Archetypes.
Theming fast and simple. Write html, poke holes in it for your Plone content.
XDV is deliverance reimplemented as compiled XSLT.
Currently has less features than Deliverance, but has much better performance.
Laurence’s goal is to have it compile down to a single XSLT transform that can be placed in the pipeline. No special software required to host it. Used on current plone.org.
Nate Aune has been doing some fantastic work in this area with ‘Banjo’ a GUI for doing deliverance theming.
GROK allows ‘convention over configuration’, similar to Ruby on Rails. Does what you’d expect for 90% of your tasks, but you still have zcml if you want more power.
Most developers/integrators do the same things.
Common tasks are:
These are by far the most common tasks a developer will need to perform.
plone.grok directives for these common scenarios. No more need for zcml.
Better, more capable version of portal_properties
Split more tools into configuration and functionality
Similar to Mozilla’s about:config
So, how do we make it faster?
Reduction of lines of code from Plone 3.x to trunk (what will become Plone 5)
Templating engine — can be used for multiple syntaxes of attribute based languages like ZPT and Genshi
Quite a bit faster. Maintained.
Used by Repoze.BFG, Pylons, Plone
Improvements for anonymous page rendering…
But also substantial for logged-in users.
Collective.SOLR integrates with SOLR, an open source enterprise level search engine — much more advanced than ZCatalog.
Jarn using this in a 7000-employee intranet. It works wonderfully.
There is no way ZCatalog could have handled this kind of load/content.
CacheFu works really well for caching content, but is a bit old, and the way it works is a bit ugly.
We have better ways to do this now, 4 years later.
Simplicity for the end-users.
“Blocks” is the back-end architecture
“Deco” is the front end editing interface
Not needed anymore.
Since deco handles layout properly
no more need for “use content as default page”
This is not a haiku. ;)
No need for most content types now that we have tiles + Deco
Archetypes will still work
Dexterity will be there for those that want to switch
And if you don’t need types, you’ll not have to relate to either.
Found something interesting whilst talking to others?
Talk sparked some interest?
Then do a talk on the subject!