[Grok-dev] Re: RFC: Masterpage implementation without macros
faassen at startifact.com
Fri Apr 13 10:16:34 EDT 2007
Kevin Smith wrote:
> We're using grok for the base of the relaunch of our newspaper website.
Very cool! Make sure by the way that
isn't going to bother you in this. We need to do something about this
> I'm not fond of macros, so here is an alternate masterpage
> implementation that I think is fairly easy to grok. This sort of
> strategy might also apply in a template neutral environment. Please let
> me know what you think.
MasterPage in essence makes grok.View's original __call__ named
'content' instead, and then allows a template to wrap around it. Clever,
though I always think such uses of inheritance should go ahead with some
careful comment in the code. :)
I think this is an interesting approach. The advantage of macros and
slots here is that you can fill in multiple things in a macro template.
What if your master template has multiple boxes on the side? You'd want
some way to style those.
I'll also experimentally translate this example to my MatchView proposal
as described in my older post "some ideas concerning skins and theming",
just to see whether it works for this use case:
grok.skin('some_skin') # only applies to pages in this skin
grok.match('body') # match the body element of the view we're
return "Master page"
masterpage = PageTemplateFile('''\
<div tal:content="structure python:view.select('*|text()')">
return "<html><body>Some content</body></html>"
in fact, if we make sure that MatchViews add a 'select' to the namespace
of the templates, we could rewrite the tal:content above to:
The MatchView strategy also allows us to dig up the title from the
original view (and then style is the way we want). MatchViews could also
dig up their own content and stuff it into an existing page.
Of course this is currently completely theoretical. It needs to prove
itself in practice.
We need to try some implementation work. Either lxml or Genshi should
offer the tools to implement the xpath stuff. It also needs work to
define what grok.skin() actually does and then to implement it.
Meanwhile, Kevin, your approach has the major benefit in that it
actually works today. I'd suggest you try pushing it some further and
report on the list on how well it's working.
More information about the Grok-dev