Grok-sprint report on Theming
There was a good Grok-sprint at EuroPython. A whole set of people who didn’t have time to stay for the whole sprint and was new to Grok was been in tutorial-mode and learned Grok, and some people was working on enhancing Grokstar, Groks blog-application, and some on improving the admin-UI, and possibly more stuff I don’t remember.
Phillip von Weitershausen finished his work on moving Grok over to the eggified Zope 3.4, and thereby killed the instance. Meanwhile, Martijn Faassen helped everyone.
I, on the other hand, got stuck on trying to add theming to Grok. During the sprint the scope of what I wanted to do gradually became smaller and smaller, and it took me two days to get up to speed on the new martian-based grokkers, and the eggified Grok buildout and loads of things that changed recently. Grok is very bleeding edge, and it’s noticeable.
Basically I was too tired and stressed to concentrate, and also made the mistake of doing the theming even though nobody else wanted to work on it. DON’T DO THAT! Don’t sit by yourself at a sprint. Worst thing you can do, ALWAYS team up. Except if what you actually are doing is using the sprint as an excuse to finish something you already have half-done, but then you aren’t really sprinting at all.
But the sprint was not completely useless for me. I formulated a more exact plan on how to implement the theming in Grok. A plan that will be useable also in Zope 3 without Grok, and will be generic enough to support even Paul Everitts wild plans of doing it all with XProc and XSLT.
How I want to do it
In Zope3 you have a Publication object. It’s responsable for a lot of things, but for this case what is interesting is that the Publication object is what finally calls the object that should be published, in a method called callObject. In the most typical case, this means calling a template or a method that generates text that gets returned to the publisher, which gives it to the webserver.
What I want to do here is to replace this callObject call with a hook, where you can hook in whatever you want. I suggest doing this by letting callObject look up a IPublicationObjectCaller adapter with the request and the object. This IPublicationObjectCaller could then implement whatever it wants. By default there would be just a standard replacement for what callObject does today, of course, but you can simply replace that with your own hook.
The next step is to make a hook that implements a pipeline of some sort, where you can hook in different steps in that pipeline. And this section is unclear. I’m planning to have a pipeline that is made up of two separate steps. The first step would be the page composition, where you plug in page composers, possibly by viewlets. The second step would then be shugging that through some sort of transformation that applied a pretty design to the composed page, a la deliverance.
So, why am I blogging about this sprint now, several months later? Because I finally finished writing the test for the hook. Yes, there is now a module, z3c.themehook, that replaces the current Zope 3 publisher with a publisher that has a theme-hook. It would probably be a good idea to actually merge this product directly into the zope.publisher, because it’s honestly quite trivial, and the current situation mean I have to write another implementation of it for Grok, as Grok has it’s own publisher.
What to do next
Implement a IPublicationObjectCaller that somehow has a configurable pipeline of that you can fill with objects that apply themes in one way or another. I have no idea of how to do that, but I hope to get closer during the Neandertal-sprint next week.