• The hazy memory of me sitting, beer in hand, deciding "Yeah, I'll go multiarch, it'll all work fine I'm sure"
• That modifying LDFLAGS isn't enough, there's all sorts of magic going on in setup.py.

setup.py basically looks in hardcoded paths for libraries, and because I'd gone multiarch the library was now in /lib/x86_64-linux-gnu/libbz2.so.1. By the time mutiarch came about, python 2.4 was too old for people to want to patch it.

However, given cmmi lets you patch files before you build, I took Martijn Pieters' example off stackoverflow and came up with:

[buildout]
python = python
parts +=
    python
    pythonbin

[python]
recipe = zc.recipe.cmmi
url = http://www.python.org/ftp/python/2.4.6/Python-2.4.6.tgz
executable = ${buildout:directory}/parts/python/bin/python2.4
patch = http://files.shuttlethread.com/patches/python2.4-addmultiarch.patch
patch_options = -p1
extra_options=
    --enable-unicode
    --with-threads
    --with-readline

[pythonbin]
recipe = plone.recipe.command
command = ln -s ${python:executable} ${buildout:bin-directory}/python

Don't look too closely at the patch in question though. It's a bit ugly, and I couldn't be bothered to tidy it. You get a working Python though, which is the main thing.

Caveats

This is all a bit rough-and-ready, but I think it's got to the point that other people could try it out with their themes and see if they find it useful.

Installation

To use it, you'll need the freshly-released 1.0.3 version of Diazo, and my branch of plone.app.theming. Add the following to your buildout config:

 [sources]
 plone.app.theming = git https://github.com/lentinj/plone.app.theming.git branch=diazo-debugger

And check it out:

./bin/develop co plone.app.theming
./bin/buildout

Now, go to a themed page and add ?diazo.debug=1 to the URL. You should see an overlay containing debugging output.

What am I looking at?

The output should be your theme file, after all includes have been included.
All diazo attributes and rule tags have been coloured red and green. A green attribute means that it matched the theme/content XML, a green node means all the attributes within match. For example:

The content has a base node, but the theme doesn't have one, so this rule won't do
anything.

The content is missing the edit bar, so the rule doesn't do anything either.

Both sides do something, so this rule is green and the title should have been copied.

Here everything within the append rules match, but the rules block they are within doesn't, so they are still red.

Errors

If your theme doesn't compile at all, you have probably noticed that you get an unthemed page without any hint of what went on. Now the XML / XSLT errors that you'd otherwise have to dig out of Plone's error log are in the overlay.

xsl:message tricks

The debugger considers each rule and condition in isolation. It will tell you when a CSS condition isn't matching. However it won't tell you when the rule isn't doing anything due to other rules, for example a drop rule could remove what an append rule appends to. xsl:message and the error log helps us here though. Compare the two examples, with the drop rule working:

...and the drop rule broken:

The <xsl:message> doesn't add anything to the document, however it will add messages to the error_log, which we can now see in the debug window. Ideally we would inject similar messages for the debugger to pick up. This is how it currently works after all---special messages saying what conditions matched are put out on the error_log and then combined with the rules XML. However, this is a lot more invasive change than what has been done so far, and some rules will be trickier than others.

What else needs to be done

You probably noticed it needs more styling. But everything has a lot of classes, so hopefully this will just be CSS work.

Outputting the compiled XSLT would also be very useful for debugging. The back-end side of things is fairly easy, however the overlay needs tabs so this could be displayed on the page in a manageable fashion. With the XSLT appended to the end, the scrollbar would be very long.

Please give it a go and tell me what you think! Is there bugs with some themes? Does it make your life easier, or at least more colourful?

During the 'hallway track' of the Plone Conference I spent a little time discussing this with Alex Limi and Steve McMahon. We all thought the GUI controllers could be really helpful for those downloading and evaluating Plone, but we obviously needed a more sustainable base on which to build a controller. Given we're all web developers, HTML/CSS/Javascript seems the obvious GUI framework. But the prospect of running a special web server to run this makes me uncomfortable, especially considering some people are likely to use the official installer as the basis for production deployments.

Surely then it must be possible to deploy a web application in a dedicated browser window without running a separate web server? Over the past few days I've been investigating the possibilities. Ideally we want a cross platform solution (especially important given the few core developers running Windows.) And a development model that makes both writing the controller and GUI familiar to Python web developers and makes building the Controller application as simple as possible.

Appcelerator Titanium Desktop

Titanium Desktop is a free and Open Source framework for building applications that run in a dedicated WebKit window using HTML/CSS/Javascript with support code running behind it in Python/PHP/Ruby. Appcelerator will build packages of your application for multiple platforms (Mac/Windows/Linux) on their servers. Their model is based on building an AJAX type application with all updates happening over Javascript (or indeed Python) calls that bridge over to the backend code. This makes it difficult to reuse the Request/Response model most web application developers are used to.

Basic app bundle size: 52MB (includes WebKit, but not Python framework)

PyObjC

On the Mac, PyObjC allows Python users to build applications using a variety of APIs exposed by the operating system, including the WebKit framework. One can simply create a window containing a browser control and plug in a custom NSURLProtocol handler to handle requests. There's some simple example code that renders pydocs.

It's easy to see how this model can be extended to run requests through an embedded WSGI app, giving us a familiar development model. Creating a binary with py2app was easy, but clearly small browser part would be Mac only.

Basic app bundle size: 17MB (includes Python, but not WebKit framework)

Qt and PySide

Qt also wraps WebKit and PySide offers an equivalent wrapping to PyObjC. Looking at a couple of examples (one, two) I could quickly see how a very similar application could be built. Qt is cross platform so the same code would run on both Windows and Mac (and Linux as well if required.) Building a working .app bundle is definitely rather tricky. I had some problems running py2app, needing the dev version of it and all its dependencies. Even then it crashed on exit. The alternatives of cx_Freeze, bbfreeze and bundlebuilder also failed in one way or other for me.

Basic app bundle size: 123MB (includes Python, Qt and QtWebKit frameworks)

A tool named Hatchet may be able to help cut this down.

Various other alternatives

From the Python Wiki:

• XULRunner + PyXPCOM. As Python is subordinate in this configuration it would require learning a lot of XUL and XPCOM to get a working application.
• PyWebKitGTK. Not a good solution for the Mac as GTK runs under X11.
• PyWin32 and MSHTML. Would result in a nice small executable for windows users, though on the downside it would involve Win32 programming and using the IE layout engine. I was unable to find much documentation on writing IInternetProtocol handlers with PyWin32.

Conclusion

I think building something with PySide and Qt will be a good first step. It should be simple enough to provide alternative frontends should that be required. Maybe we even want to separate the backend application from the frontend to avoid requiring developers to rebuild the frontend while changing the controller.

Current enterprise social media tools have a major drawback: they are separate from and barely integrated with the main online tool for collaboration and information dissemination within an organisation, the corporate intranet/extranet. That's why I was so excited by the opportunity to talk with Yiorgis Gozadinos of Jarn at the recent Living Statues Sprint about the collaboration tools for Plone he's been building on top of XMPP.

The XMPP standard grew out of Jabber instant messaging project. As such it encompasses messaging, presence information and roster management. It powers Google Talk and Facebook Chat. And crucially it is able to function across HTTP, so browser based clients are available. This makes it an excellent abstraction for building real-time web applications.

At this point I expect those with long experience of Zope may have some concerns... As a threaded application server Zope is usually configured with a small number of fat threads, an architecture completely unsuitable or asynchronous, long-polling applications. Fortunately Yiorgis has an elegant solution: make the Zope server itself an XMPP client and simply offload the asynchronous long-polling requests to ejabberd.

XMPP is not just for chat. The Publish-Subscribe protocol extension (PubSub) enables a broad range of applications to be built on top of XMPP. We believe that the most compelling of these for Plone will be activity streams that could combine user status updates with notifications of activity on the content that concerns you.

Yiorgis' software currently supports microblogging, messaging, and collaborative editing (just like Google Docs!) Check out this screen cast recorded a few days ago:

Collaborative editing with Plone from Yiorgis Gozadinos on Vimeo.

Though it has a different focus, with PubSub XMPP has a lot of overlap with AMQP (RabbitMQ/ActiveMQ). It would certainly be possible to use XMPP for asynchronously executing expensive tasks such as text indexing, content conversion or multi-publishing. And as it spans all the way to the browser, users can be notified when tasks are complete.

I'm really excited about the possibilities that are opening up here. The software's available from github: jarn.xmpp.core. Please do take a look, I know Yiorgis is keen for more people to get involved.

Ack is already been discovered by quite a few people, as the URL says it's better than grep. Mostly because it does the right thing in terms of searching directories (the default is to search recursively from the current directory), and the listing formats are much clearer. If you haven't already, get it via. "aptitude install ack-grep".

Configuring to page usefully by default

If you've used ack even once or twice, you'd have noticed that doing "ack | less" is somewhat disappointing. The colour goes away and you're faced with grep style formatting, rather than the colourful ack output you were hoping for. This can be fixed by this one liner alias, which could be placed in your .bashrc.

 alias ack='ACK_PAGER_COLOR="less -x4SRFX" /usr/bin/ack-grep -a'

This does several things to make using ack more pleasant.

• Debian/Ubuntu can't call the executable ack, since something else beat it to it.
• If using ack seriously, at some point you will find out it only searches file extensions it knows about (i.e. not .zcml), and loose several clumps of hairs. -a slows ack down slightly, but lets you keep those hairs.
• The ACK_PAGER_COLOR environment variable means ack output gets paged, but is still colourful. The result of the less options means you get paged results automatically when results fill your screen, without you having to Ctrl-C and re-run through less or something.

Breaking down the options on less:-

• -x4 tells less to use 4 character tabs
• -S tells less to not fold long lines, but let them scroll off to the right.
• -R tells less to use control characters that will colour terminal output, rather than escaping them (used to be -r, thanks Dan Thomas).
• -F tells less to quit if there is less than one screen, so you don't have to decide whether to page or not beforehand.
• -X tells less to ignore an initialization termcap might tell it to do. This is useful for xterms, as they are often set up to send applications like less to a secondary screen, and then switch back afterwards. Without it, -F will cause results to appear on the screen and immediately disappear as less quits.

That's about it. Hope it's useful.

 

We were tasked with creating a corporate site for Lime Pictures, a media company based in Liverpool. They had already worked on their design internally, and come up with something very stylized, and quite unlike Plone out of the box.

As several other blog posts have already shown, transforming Plone page into something that looks entirely different is quite easy. With this site though, it behaves quite differently too. The navigation is based around a grid, each row being a different section of the site. The first row is special, and shows pages that aren't part of any particular section. This table gives an idea of where each cell in the grid goes.

/

/about-us

/contact

/hollyoaks

/hollyoaks/hollyoaks-later

/hollyoaks/hollyoaks-music-show

/conker-media

/conker-media/the-well

/conker-media/shelfstackers

As most websites start, HTML mockups were created of the various page types. We then defined some Dexterity types that had all the fields required to populate the pages, and Diazo rules to turn these into CMS powered pages. Whilst we can theme the Plone navigation to look different, there's no navigation that behaves like the above.

Weaving in custom navigation with Diazo

Whilst custom navigation can be included using portlets, registering a portlet for each page to get our navigation isn't necessary with Diazo. Normally when you theme with Diazo, you work against the HTML from Plone. However, the "href" attribute available on most directives allows us to reference any URL and include segments from that as well. For example:-

 <append css:theme="div.grid-background"
         css:content="div.grid-background div.footer"
         href="@@menu_view" />

This calls @@menu_view for the current page, and gets the contents of the footer from that. We just need to register menu_view in our product's configure.zcml and we're away. You will notice that Diazo is just selecting div.footer from @@menu_view, this is particularly handy as:-

1. We can make this view generate several bits of useful information for us, not just the footer. plone.app.theming will only fetch @@menu_view once so combining our custom logic into one view makes good sense.
2. Content not selected by the theme is never visible, so is ripe for stuffing with debug when you visit the view directly. For example, CSS classes can be pulled out with javascript and displayed below the elements.

plone.app.contentlisting

However, in throwing away existing navigation portlets we've exposed us to a lot of Python/ZPT to potentially write. There's lots of easy mistakes to make like making private content still visible by using contentValues() too. Fortunately plone.app.contentlisting takes a lot of sting out of this. This is a set of helpers to deal with the lists of objects in templates, and gives a common interface to objects regardless of if they are catalog brains or real objects.

Back to our site. @@menu_view has functions in Python to get lists of notes which the template will simply iterate through and format HTML for each. For example, the function to generate the left hand column is:-

     def getSections(self):
        """Return all sections (top level objects that go in the left-hand column)"""
        sections = [n.getObject() for n
                                   in self.navRoot.restrictedTraverse('@@folderListing')()
                                   if getattr(n,'is_special','')=='menu' and n.isVisibleInNav()]
        sections.insert(0,self.navRoot) # Navigation root is the first item
        return sections

Security is dealt with for me by plone.app.contentlisting, and isVisibleInNav() ensures that the view honours common Plone options from hiding from navigation.

Separating the logic of what is shown where to how it is shown makes for robust automated tests, which if you have a content profile to import as discussed earlier, is really easy.

In a Dexterity FTI, you can specify the schema one of three ways:-

• schema: A dotted name to an interface describing the type written in Python, as described in the developer manual.
• model_source: An XML string representing the type. This string is generated and updated by the TTW editor. When exporting the FTI, this string will be escaped XML.
• model_file: A path to an XML file representing the type.

Whilst developing sites we have found it useful to start off with TTW editing of types whilst prototyping what we want, then export the XML ("Export Schema Profiles" in the dexterity control panel) and add it to our sites' product. We can then empty the model_source property in the FTI and add a model_file property:-

<property name="model_file">shuttlethread.farmyard.models:animal.xml</property>

Plone.supermodel XML files

So what can you add into this XML document? In short, the plone.supermodel XML schema allows you to define a set of schemas, which approximate what you would be doing within a Python interface definition. Schemas can be named or anonymous, most of the time we will have a single anonymous schema in a file. Here is a simple example that defines three fields.

<?xml version="1.0"?>
<model xmlns="http://namespaces.plone.org/supermodel/schema">
  <!-- Schema for the animal type -->
  <schema>
    <field name="species" type="zope.schema.TextLine">
      <description />
      <title>Species</title>
    </field>
    <field name="feeding_notes" type="plone.app.textfield.RichText">
      <description />
      <title>Feeding Notes</title>
    </field>
    <field name="passport_photo" type="plone.namedfile.field.NamedBlobImage">
      <description />
      <title>Passport Photo</title>
    </field>
  </schema>
</model>

The doctest for plone.supermodel goes into more detail about what's possible, and is a useful read.

Customisation cookbook

The following is a collection of useful snippets that can be plonked into your model files.

Choosing different widgets

Generally the default widget for a field is enough, however in some cases there is a selection. One example is a Choice field. Normally rendered with a drop-down select box, if there are only a few options then radio buttons might be more appropriate.

<model
  xmlns="http://namespaces.plone.org/supermodel/schema"
  xmlns:form="http://namespaces.plone.org/supermodel/form"
  >
  . . . .
    <field name="work_permit" type="zope.schema.Choice"
           form:widget="z3c.form.browser.radio.RadioFieldWidget">
        <description></description>
        <title>Do you require a work permit to work in the United Kingdom?</title>
        <required>True</required>
        <values><element>Yes</element><element>No</element></values>
    </field>

Specifying a list of a field type

You may want to have a list of items, which can be created by using a zope.schema.List field like this:-

    <field name="things" type="zope.schema.List">
        <min_length>1</min_length>
        <title>Things in the field</title>
        <value_type type="zope.schema.Text">
            <title>Thing</title>
        </value_type>
    </field>

The value_type can also be a zope.schema.Object, in which case the list can group multiple fields.

<field name="employment" type="zope.schema.List">
  <required>False</required>
  <min_length>1</min_length>
  <value_type type="zope.schema.Object">
    <required>False</required>
    <title>Employment Detail</title>
    <schema>shuttlethread.farmyard.models.IApplicationEmployment</schema>
  </value_type>
</field>

Unfortunately the schema has to be a reference to a python interface, for now at least.

Using an uploaded file to name the item

If you are creating a type that is mostly a container for a file, then it may be more sensible to get the name from the file, rather than enforce users to type in a title also. Firstly you need to add the INameFromFileName behaviour within your types FTI:-

<property name="behaviors">
   . . .
  <element value="plone.app.dexterity.behaviors.filename.INameFromFileName"/>
</property>

Then you need to set one of your fields to be primary, which will be where the title is derived from. In your schema:-

<model xmlns="http://namespaces.plone.org/supermodel/schema"
       xmlns:marshal="http://namespaces.plone.org/supermodel/marshal">
  <schema>
   . . .
    <field name="image" type="plone.namedfile.field.NamedBlobImage"
           marshal:primary="true">
      <title>Background image</title>
    </field>
</model>

Arranging fields into fieldsets or tabs

When editing content, available fields are arranged into tabs (or a dropdown, if there's over a certain threshold). You can use tabs to arrange your own fields by grouping them in fieldset nodes. Either use an existing name to add them to a tab, or use a new name to create a new tab.

<model xmlns="http://namespaces.plone.org/supermodel/schema"
  <fieldset name="settings" label="Settings">
    <field> ... </field>
  </fieldset>
</model>

• Store some baseline content along with the sites custom product, which means you always have a representative set of content to develop and run integration tests against.
• Transfer content from different instances, e.g. pulling content from a shared development instance to your local instance for further investigation.
• Modify content with UNIX tools, when site structures change for example.

Using transmogrify.dexterity, we can ilmport any content from dexterity to & from a directory tree of JSON files.

We'll assume that you've already got a Plone 4.1 buildout set up, and have a custom product for your site that contains your dexterity types. Follow a guide such as this to get this going.

For this example I'll occasionally mention a shuttlethread.farmyard product, which is the custom product for a dummy site to manage our animals on the farm. The source is available on bitbucket if you'd rather read the entire thing.

Enabling transmogrify.dexterity content export/import

Firstly we need to include transmogrifier and transmogrify.dexterity. We can do this in shuttlethread.farmyard's setup.py:-

install_requires = [
           . . .     
    'quintagroup.transmogrifier',
    'transmogrify.dexterity',

We also need to define a pipeline for quintagroup.transmogrifier to use. There is an example pipeline configuration within transmogrify.dexterity that should be good enough for us:-

<configure xmlns="http://namespaces.zope.org/zope" i18n_domain="shuttlethread.farmyard">
    <include package="transmogrify.dexterity.pipelines" file="files.zcml" />
</configure>

If you needed to change it, you could use the import.cfg and export.cfg files.zcml includes as a starting point for your own.

Now start up your Plone instance with some dexterity content and go to http://localhost:8080/Plone/portal_setup/manage_exportSteps. There should be a "Content (transmogrifier)" option, select that and "Export selected steps". We get a .tar.gz (or .zip under windows) with contents similar to the following:-

structure/.objects.xml
structure/meadow/
structure/meadow/_content.json
structure/meadow/.objects.xml
structure/meadow/daisy/
structure/meadow/daisy/_content.json
structure/meadow/daisy/_field_feeding_notes.htm
structure/meadow/freda/
structure/meadow/freda/_content.json
structure/meadow/freda/_field_feeding_notes.htm

Firstly, each page has it's own directory, and contains a _content.json file. This contains all simple fields in our dexterity type. For example, here is the content of Daisy's _content.json:-

{
    "creators": ["admin"],
    "feeding_notes": {
        "contenttype": "text/html",
        "encoding": "utf-8",
        "file": "_field_feeding_notes.htm"
    },
    "species": "cow",
    "title": "Daisy"
}

"Feeding notes" is a rich text field. The values for these are put in a separate file and the JSON contains a reference to the file name. The same would happen with an image field or any other BLOB field. Finally, the meadow is a container type so it has a .objects.xml which lists the cows within it.

There is also an equivalent import option, but we're going to do something a bit neater.

Storing content in a GenericSetup profile

We can use a GenericSetup profile to import content automatically when we create a new site, and keep this in our custom product. First, define we the "testfixture" profile in shuttlethread.farmyard's configure.zcml:-

    <genericsetup:registerProfile
        name="testfixture"
        title="unittest content"
        directory="profiles/testfixture"
        description="unittest content / example content for development"
        provides="Products.GenericSetup.interfaces.EXTENSION"
        />

Then create the profile directory (i.e. "profiles/testfixture"). It makes sense to depend on the default profile, assuming that's where the types for the content we create are. So in metadata.xml:-

<metadata>
  <version>1</version>
  <dependencies>
    <dependency>profile-shuttlethread.farmyard:default</dependency>
  </dependencies>
</metadata>

And create a file quintagroup.transmogrifier-import.txt with the word "import". This file is just a marker to show the import happened, it's content is not important.

Finally, unzip/tar the export made earlier so at the end we have:-

src/shuttlethread/farmyard/profiles/testfixture/metadata.xml
src/shuttlethread/farmyard/profiles/testfixture/quintagroup.transmogrifier-import.txt
src/shuttlethread/farmyard/profiles/testfixture/structure/.objects.xml
src/shuttlethread/farmyard/profiles/testfixture/structure/meadow/.objects.xml
src/shuttlethread/farmyard/profiles/testfixture/structure/meadow/_content.json
src/shuttlethread/farmyard/profiles/testfixture/structure/meadow/daisy/_content.json
  . . .

Now we can instantly build a new site full of content. Going to @@plone-addsite?advanced=1 and choose the new "unittest content" option.

Also note that we didn't have to export the content from the same server, it could have been a staging server or production server. Run the export process on your production server, put the content in your product, recreate the site and you have all the content from your live site available locally.

If your tests use plone.app.testing then they can install GenericSetup profiles. This means integration tests can be written that refer to the test content too. I'll probably show this in another post.

More automation, more fun!

As useful as it is, updating your example content by clicking all the ZMI buttons and untarring the content in the right place quickly gets dull. We can use curl can automate this though. curl is a command-line tool for interacting with webservers, and we can combine the request to export content with an untar into the right place. For example:-

curl --user admin:admin \
     --data 'ids%3Adefault%3Atokens=' \
     --data 'ids%3Alist=content_quinta' \
     --data 'manage_exportSelectedSteps%3Amethod=+Export+selected+steps+' \
     http://localhost:8080/Plone/portal_setup \
     | tar -zxvC src/shuttlethread/farmyard/profiles/testfixture/

In our projects we have some extra bash script to empty the testfixture directory first, but this isn't ideal. I'm going to work on a buildout recipe to add a bin/exportsite script in a more reusable fashion.

Workflow caveats

We have used transmogrify.dexterity to import/export most field types without hiccups. However, one thing is the default pipelines do not know much about workflow. The export pipeline does not record the current state of content, and the import pipeline will try and transition everything to 'publish'. This works fine with the default workflow but if you have your own workflow you will need to make a copy of import.cfg and change this.

You can at least override the transitions a content item goes through. Most useful if you need to test the behaviour of an unpublished content item. Within it's _content.json add...

"_transitions": [],

...to disable the default transition to published. Note that another export will overwrite this though.

Of course there will be some themes that require supporting views or python code to work, but for the vast majority that don't, I'd like to encourage theme authors to distribute themes as zip files rather than as python packages. Uploading your theme as a simple zip file to Plone's Add-on Products section has several advantages:

• Less code. No need for a setup.py or several levels of folders containing __init__.py files.
• Previous versions of your theme will continue to be available after you update it.
• New users will often use an existing example as the basis of their own work. By keeping these examples simple we increase the probability they'll be successful in creating their own theme.
• In future we hope to create a theme gallery on plone.org and integrate it into the plone.app.theming control panel. This can only work for simple zipped themes, not python packages, so for inclusion make sure to upload them!

So with zipped themes now fully working, I don't see any reason to uploading simple themes as python packages to pypi. And please don't upload copied of your zipped theme into Plone's subversion repository, version control is intended for source code and it does not benefit from the plone.org cache server.

Diazo is a theming tool that implements a Deliverance like language using a pure XSLT engine. Diazo 1.0b1 brings a number of language simplifications when compared to XDV, for instance we now use <replace theme-children="..."> instead of the confusingly named <copy theme="..">. We have also added operations to support the copying, deletion and merging of attributes.

While Diazo is developed as part of the Plone project, there is nothing Plone specific about the package. Diazo 1.0b1 includes a WSGI middleware component which may be used as a simple proxy, see the quick start guide. Themes may alternatively be compiled down to XSLT and run in Apache or Nginx, for more information see the deployment guide.

Diazo is the successor to XDV and in most cases is able to run your existing XDV rules without changes. For more information on Diazo see the documentation at diazo.org. Download from the diazo pypi page.

To use Diazo in a Plone site, we recommend plone.app.theming. plone.app.theming is the successor to collective.xdv. It builds on the newly released plone.resource to simplify the process of theme deployment and distribution, themes are no longer required to be a python package and may be distributed as simple zip files.

plone.app.theming adds the ability to pass parameters to your theme from calculated TAL expressions, enabling conditions to be tested in a python context which is generally simpler than XPath.

To get started with plone.app.theming read the documentation. It is recommended to use with Plone 4.1b2, the package version known good set is available on good-py. It should be possible to use with 4.0.x with appropriate pins for plone.app.registry and plone.app.z3c.form and dependencies.

Special thanks to Martin Aspeli and David Glick for their work on plone.app.theming, plone.resouce and Diazo.

Jamie Lentin worked on a Diazo debugger and succeeded in building a proof of concept implementation which extracts relevant information from the transform. This now needs to be hooked into the generated pages with a javascript UI.

Laurence Rowe (with help from Andi Zeidler and Wyn Williams) worked on importing the XDV subversion history into the Plone repository. There's still a few bugs to work out, but we should be there soon.

Volodymyr Cherepanyak worked on making Sphinx documentation. This will form the basis of the Diazo website once the repository move is finalised.

Outside of the sprint, Martin Aspeli and David Glick are now working on plone.app.theming, the new collective.xdv, and plone.resource, for simpler theme integration.

This talk introduces the rules syntax; compares with Deliverance; and presents some examples of in production.

Date: Thursday, 28th October 2010. Conference site talk page.

Update: Video now available.

We've been friends since high school and have kept in touch over the years and exchanged thoughts on the technology we'd been using in our different jobs. Though it's usually been different technologies, it's often felt like we've been working at the same fundamental problems.

We were both looking for a new challenge and wanted to base ourselves in Manchester. Realising that we were after the same thing, we talked it over and decided to take the plunge and start our own company. By joining forces we will be able to offer our customers the benefit of our combined experience.

A little more about ourselves:-

Laurence Rowe

Laurence has been building Plone sites since 2002 and has since made a career of it. He is an active core contributor and serves on the Plone Framework Team, the body which provides technical direction for the Plone CMS.

He's spent a lot of time integrating Plone with other systems, either at the database or user interface level.

After working in London and Norway, he decided to move back to Manchester where he had studied for his degree in Software Engineering.

Laurence on Linked in.

Jamie Lentin

Jamie has been developing websites and associated solutions since the turn of the century. He is a multi-skilled developer, turning his hand to client-side Javascript all the way down to Linux kernel development.

He has spent 5 years at the BBC where he has been lead developer architect behind several aspects of content management, in particular the in-house XML/XSLT-based CPMS managing and producing many parts of the site. Besides this, developing AV transcoding/moderation systems and voting/comment data warehouse solutions, making much use of Oracle and MySQL.

He will now, after moving back to Manchester, be taking his Python experience and applying it to Plone.

Jamie on Linked in.