Team Rubber with a contribution from Netsight hosted the Sprint under the auspices of Matt Wilkes (who will soon be finishing there and becoming an independent developer).
On an unusually hot and sunny weekend, I spent three days stuck inside tapping away on a computer, surrounded by plates of half eaten food and glasses of half drunk beer. This was the Bristol Balloon Sprint, a gathering of independent developers who volunteer
their time to help contribute towards developing the Plone open source CMS.
There were attendees from Germany and Scandinavia as well as a gathering of a number of representatives of Bristol's large Plone community that help make it the UK Plone capital. The European attendees included the release manager for Plone 4, its next incarnation. We mainly worked on progressing Plone improvement proposals and fixing the automated tests that facilitate software quality assurance. Along with some work on the popular web form building addition for Plone.
Coding
The sprint was focussed on Plone 4 along with some PloneFormGen (PFG) work. I tried my hand at the former for the first day.
Working with Anreas Ziedler on plone.app.blob fixing tests for plone 4.
This package unifies blob handling for images and files and adds native file system storage for them to plone. It was useful experience
in developing / testing for plone 4 but I felt I wasnt getting a lot done.
Hence the next couple of days were spent trying out creating a save database adapter for PFG. There was some progress with a ploneformgen.sqlizer egg
that creates tables based on PFG forms and generates CRUD sql handlers. The work was partly because Netsight were interested in this, and the rest of the PFG team worked on adding optional form inputs to PFG. My interest was in trying out this as a possible future for the UOBCMS DBI document
solution moving to a PFG based one. Since PFG has quite an intututive interface for designing web forms that end users should be much more comfortable with than DBI.
Plone Futures
From what I gathered regarding the future of Plone, it looks healthy (unlike zopes!), if confusing.
Hanno Schlichting is Plone 4's release manager and is aiming to get it released by
the end of year. The main drive is refactoring the underlying code base and simplifying it so the code base is now a lot smaller, and runs on the fully eggified zope 2.12 There may also be a new skin, ie admin interface ( perhaps relevant to CofE issue) although it seems as though there is little work on that yet.
There has been a phasing of new versions of plone into 4 and 5. With a fairly movable set of deliverables for each depending on who gets stuff done by when.
Broadly there are a number of things happening wrt. the whole platform underneath plone and its long term future.
- In general everything is eggified and hence developers are now tending to pick and mix elements from all the python frameworks a lot more.
This means everything is going to use WSGI, and Plone is moving away from being 'a zope application' - Also it looks as though Zope 3 is dead - ie. the zope 3 publisher, however the Five elements of zope 2 are likely to become a standard
set of additions packaged as the zope framework 1. This would sit on zope2 that still seems to be plodding on. - Also all the ZCML stuff hasnt proved that popular and people are mooting a simplified Plone specific config language.
- Repoze looks to be gaining ground, so Plone may well move to being as commonly deployed on
repoze / WSGI (ie Apache) as on zope. - On the front end skin level deliverance seems to be gaining ground, with its capability of mixing together application's chrome.
Also KSS is much reduced and only enabled for the edit interface for plone 4 onwards. - Archetypes are being replaced by dexterity - but probably not until plone 5.
My personal take on this is dead archetypes and KSS - hurray.
Dead zope altogether also hurray, but zope3 dying and stepping back to rebadged zope2/Five for a long time until Plone is a pure WSGI / ZODB app bad, bad, bad.
The idea of all the ZCML stuff being changed, and a more pure java-like component architecture not being a Plone goal is also pretty bad in my book, since at
lot of my inspiration for getting more into Plone recently was the promise that zope2 was soon to be ditched. I guess however that I can just readjust my
view towards repoze and the idea that zope as a whole will largely be ditched eventually.
