Louvain La Neuve Sprint Trip Report

Godefroid Chapelle hosted a Zope 3 sprint at his BubbleNet office in Belgium, April 8-11. This is a brief trip report.

Summary: Meaningful XML was checked in, plus Jim and Godefroid reached consensus on some important issues for assembling user interfaces. We all greatly enjoyed what Godefroid put together. Thanks go out to the Chapelle family!

Tuesday morning started with typical sprint-logistics problems. A couple of people took longer than they had planned to arrive. Also, my well-known hardware-anti-karma struck Philipp's laptop and Jim's Airport hub. By the middle of the afternoon we had everyone setup and working productively.

The two sprint topics were XML and i18n. On Tuesday evening and Wednesday morning, Jim, Philipp, and Pierre-Julien went through the newly-updated version of the Zope 3 tutorial. On Wednesday, Godefroid and Pierre-Julien worked on i18n, beginning to add needed code to Python modules and page templates in the zope/app/browser region.

Also, on a side note, Pierre-Julien gave me a demo of his "SkinMI" project. It's incredible, but also hard to explain. I'll start with the benefit. Imagine a skinnable ZMI without frames that works with existing DTML views in Zope 2. He does it through a small patch that allows him to use skins, such as the Plone look. In fact, in his demo he has the Plone navigation box replacing the ZMI navigation tree.

I prepared a brief presentation in advance. The presentation was at a high-level and tried to set the scene for the motivations and a broad proposal. The main part of the presentation: describing "Joe Professional Programmer" (JPP) as an archetypical developer, and prepare a Zope 3 + XML story that appeals to such a person. JPP was the touchstone referred to during the sprint.

The basic idea I suggested was an "XML-CA" (XML Content Architecture). We don't want to replace CA (component architecture) machinery with XML machinery, thus forcing CA developers to use XML. But we also don't want XML to be a sideshow that languishes. Instead, we want the XML story connected to the CA story, so the XML story can leverage the CA and provide CA benefits to the XML content developer.

I was very surprised at how quickly things came together. The discussion took a couple of twists-and-turns, but Martijn/Philipp/Jim had a really neat architecture planned by the morning of the second day.

Rather than giving a bad interpretation of the results of the discussion, I'll simply point at their nice Zope 3 XML Architecture in the Zope3/src/zope/app/xml package. Also, take a look at the example application. As Godefroid said it: We can define XML schema interfaces in ZCML, as follows:

    <zopexml:schemaInterface
        uri="http://xml.zope.org/hypothetical/invoice.xsd"
    />

...and those interfaces would be called URI interfaces.

I'll also note that I nearly obeyed my week-long vow of silence on RDF. :^)

On Thursday afternoon they gave a demo that showed adding an XML document, recognizing that it was well-formed, parsing the schema declaration, and mapping the schema declaration to a Zope 3 interface from the (previously loaded) schema. Since the XML document looked like an instance of a component, they could then use ZCML to give views to XML documents that were instances of that schema.

Another topic that popped up repeatedly, mostly because I sounded like a broken record about it, was the pipeline architecture of Cocoon, AxKit, and Sean McGrath's work. It's an interesting and sometimes-useful pattern. More on pipelines can be found in the Cocoon wiki and an AxKit article. oreillynet.com also has some articles. In particular, take a look at "Why Pipelines" from the AxKit article. We also had a brief discussion about XForms.

For other topics, I worked a bit with Godefroid on some user interface tweaks to Rotterdam. We started eliminating some placeholders in the UI that were distracting. We also added a new widget for better editing support in Rotterdam. Namely, this widget will allow background saving, though right now all it does is give you a wider textarea. We hope to write up some documentation on to add widgets.

On Thursday, Godefroid and Jim had a big pow-wow about standard macros and establishing/documenting some conventions on usage. This led to a discussion of the "usage" proposal that Godefroid and Alex discussed after the Paris sprint. From this, Godefroid and I wrote a draft proposal that happens to document some of the ideas of skins and layers. (Note: as you can see, it's certainly a work-in-progress.) There is also a quick diagram. (Jeffrey will note the use of OmniGraffle. :^)

After I left Friday morning, Martijn and Philipp kept working. Philipp told me later: "Martijn and I also worked on a xslt product. It's 99% done, all unit tests pass as they should. We just experienced strange problems Friday evening. Martijn had to catch his train, so we didn't finish. Once all issues are solved with my iBook and the code, I'll make the checkin of xslt and xslt_examples."

Jim and I also had a discussion on making Zope 3 easier for template authors to figure out. When I sit down in front of a view and want to know where something on the screen came from, it's currently quite a goose-chase involving grep and a few questions on IRC.

Imagine a "Design" view which would tell you where things came from. The discussion turned to changes we could make in the ZPT processor to insert URLs to the source that rendered a block, as well as the TAL that went with the block. We could then build a Design tab/view in the interface that showed you the blocks, let you click on them and inspect the TAL that generated the block, and click on the link to visit the macro page. We could also keep track of every object that had an attribute lookup during rendering, allowing you to browse the relevant objects.

The first step would be fairly simple: just leave some breadcrumbs in the rendered markup and let a tool like Mozilla's DOM Inspector be the tool you use for introspection.

On Thursday, Jim gave me a demo of the current state of Site Development in site folders. Although it's still a little bit rough cosmetically, it's far farther along than I expected. I filmed his walkthrough. I'll try later to put up a QuickTime version.

Basically, here's what you can do: create a folder, turn it into a site, add a view service, put a page folder in there to hold view templates, create views that are bound to an interface, association them with a permission, create a Persistent Module containing a class, associate that class with an interface, then call a method on the class from the page template. When you visit a piece of content, you get a new view that makes a call to the class method in the persistent module.

Friday was XSLT day for Martijn and Philipp. They created an XSLT Transformer utility that can be used as a basis for an adapter from a URI interface to any other interface (another URI interface or a module dotted interface). They later checked in a way to view OpenOffice files.

Jim and Godefroid did work on almost finishing usage implementation for views. FYI, the usage top level variable in templates is there to allow you to maintain a unique template for a whole application. By testing usage, you can decide which parts of the templates should be shown or hidden.

Having a unique template eases to enforce a coherent UI by ensuring that structural elements do not move too much on the screen. A template gets its usage value from the menu it is registered to (actually from the usage value set on the menu through its ZCML directive).

A menu is a set of conceptually related links to pages. When you click on one of those links, you should arrive to about the same type of UI with identical (or at least similar) information available. Getting usage from the menu will enforce (we hope) the coherence of the UI. Anyway, usage can be overridden by initializing it through the page configuration (ZCML directive).

Yes, that's a rough treatment. :^) I hope to writeup something better and make a movie of Jim's site folders walkthrough. For now, simply remember this: Jim's TTW Dev vision is solid and it is starting to work.