Wednesday, November 7, 2007

New ideas regarding page composition

The prodigious Carlos de la Guardia wrote an intriguing article about Plone Performance and the Future of ZPT. He poses a question in the article: "I wonder if Deliverance could be useful here also?"

Short answer: yes. Longer answer: sorta, and I'd like to find out what people think. So read on, and if you have an interest in alternative thinking on how HTML UIs get generated, ping me.

As background, before I used the word "Deliverance", I was focusing only on Zope Site Themes. I view theming as distinct from skinning. A theme is only about corporate identity. There isn't really any computation, iteration, or any programmer-oriented stuff. Instead, you're just re-arranging HTML. You are probably leveraging existing artifacts.

I then got interested in splitting content management from content delivery and wanted a project that did both theming and composition. And I thought Deliverance was a hilarious name.

I keep vacillating, though, on whether one facility should do both. I still change my mind constantly on this. On one hand, I think they are very distinct audiences (site designers and templating integrators.) In the new, Repoze-oriented world of middleware, that would mean:
  • A WSGI middleware step takes the CMS output (likely semantic markup) and does "templating" to generate an HTML UI
  • The next middleware step (Deliverance) takes the mostly-done HTML and applies a corporate ID.
On the other hand, people might want it to be conceptually part of one step. For example, Ian said I should start by using the XSLT version of Deliverance and just having some custom rules that do the first step. It certainly would shave off some performance penalty you'd get by converting a tree to a string and back into a tree between middleware steps.

My instinct says that isolation, though, is better. I'll probably start on that path. (Tres gave me pointers on how to approach it.)

As Alan mentioned in a link from Carlos's article:

Enfold is working on xslt and doing page assembly outside of zope (in apache or IIS) using enfold.lxml (in our public repository).

I worked with Enfold on this for two very large projects, one of which (Open Society Institute's KARL system) was the keynote at the Plone Conference. In this, Plone generates an XML string for the information needed on a page. Something outside Plone takes that and generates a UI.

This has some interesting and positive performance implications. More importantly, it had a big consulting process impact. We were able to model every screen in the system as an XML file on disk. We then refined the UI with the customer, using templates (in our case XSLT) that didn't require a server or framework. Meaning, the customer could hack on it without screwing up "the server".

Since these same templates were used in production, there wasn't really a mockup stage. As long as the "back end" generated the same XML structure our dummy files expected, everything Just Worked.

Forget for a moment whether this uses XML/XSLT or JSON/Genshi or EBCDIC/Cobal.  Let's isolate the concept itself (moving HTML UI generation out of the framework) and see if there is interest.

I'd like to discuss using WSGI middleware for page composition and theming to achieve the following goals:
  • Separate the generation of the information (Plone) from the generation of a custom HTML UI
  • Increase performance by (insert a few reasons here)
  • Allow integrators to make more meaningful customizations without learning a component framework
  • Use schemas to increase quality by bringing a unit-test-like approach to the UI stage
If you're interested, let me know. I can start with a series of screencasts (and yes, Geir, writeups) that try to show what's been done and why it might be worth discussing, if there is interest.

11:52:01 AM   comment []   

Repoze at ZPUG last night

Last night Chris McDonough gave a presentation to the Zope/Python User Group of Washington, D.C.  I went along for the festivities and quite enjoyed myself.  Pretty good turnout.

As preparation, Chris wrote a detailed article about getting started with Repoze:

We've just created and released Developing With repoze.zope2 which is a short 10-page PDF that explains the benefits of and differences between developing Zope 2 applications using Repoze and "stock" Zope 2. It might be helpful to folks developing under Plone and CMF.

I believe we're slated to give another talk at the next ZPUG meeting in December.  I might give a walkthrough on using Deliverance to theme your Plone site.  I'll probably just play my screencast and claim I put effort into preparation. [wink]

We're also interested in getting Repoze more out and into the wild.  First, we're talking with Plone/Zope/Python user groups on the east coast, seeing if we can get our travel covered to come give more talks on WSGI and Repoze.  If you're interested and can cover our travel, drop us a line.

We also want to get more folks into Repoze, so it's bigger than us.  Both people that want to contribute, but also, people that want to start using it for real.  Drop by #repoze on and hang out with us.

10:52:28 AM   comment []   

Might we be returning to a One True Zope?

When you say Zope to someone, they may or may not hear the same thing you said.  There's Zope 2.  There's a completely different thing called Zope 3.  There's also a company, but that's a different topic.

It's thus with great relief this morning to read Baiju's At last Zope 3 releases coming to an end ! post.  It's somewhat startling, and exciting, to hear this said in public:

I won't be surprised if the term "Zope 3" itself vanish in the future.

I realize there is a small contingent that wants their Zope 3 isolated from Zope 2, never to even touch each other.  Honestly, if that was the outcome you wanted, why even call the rewrite Zope in the first place?

Next discussion, hopefully, will be whether that one Zope is an application server or a framework, or some other jargon that doesn't mean "closed world platform". [wink]

10:40:43 AM   comment []