[Grok-dev] Re: Skinning/themeing

[Martin Aspeli]

Martijn Faassen wrote:
> Hey,
> 
> Martin Aspeli wrote:
> [snip]
>> I think Grok should have a convention for defining something like
>> @@standard_macros, which would probably contain a macro for the standard view
>> (and maybe one for admin screens), with an associated template that defines 
>> slots.
> 
> Zope 3 has some kind of a way to aggregate macros that I never quite 
> understood the purpose of - it seemed unnecessarily complex.

Agree. I think it finally "clicked" for me when I wrote this post and 
thought about it for the n'th time. :-)

> Anyway, if you have a page template which defines some macros, put it in 
> your application's templates directory, say app_templates/mymacros.pt
> 
> Then in app.py:
> 
> class Mymacros(grok.View):
>       grok.context(Interface)
> 
> You can now access macros using:
> 
> metal:use-macro="context/@@mymacros/page"
> 
> Fairly simple pattern. We could make a grokker for this case, though 
> it's barely worth it, if at all.

I think promoting it or something like it in documentation would be a 
good idea, and sufficient.

>> This to me is the first step of promoting patterns for skinning and templating.
>> Most people who aren't used to this kind of "inversion of control" in templates
>> start trying to include a standard header and footer "include" on each page.
>> That's fine - we should (and do) support that, but in my experience it's not a
>> great way to grow an application (you end up with a "change all templates"
>> exercise at least once, probably more times, as your design evolves).
> 
> A bit in the tutorial would be helpful here to start with, then.

Yep.

> [some conditions for integrating deliverance]
>> My point was that we may eventually end up creating our own portal_skins. That
>> is, a standard component which keeps track of installed themes and lets people
>> switch between them. Maybe not in the core of Grok, but if Grok is about coming
>> up with "the way" to solve various common use cases, it's likely that something
>> like this would emerge as a "semi-supported add-on".
> 
> I think a skin switcher could be part of a Grok admin interface. The 
> problem of course is that skins should be related enough - skins only 
> work if they define the right slots.

I don't think a "live" skin switcher is that important. I mean, it's 
cool, but I don't think people care all that much unless they're 
building megrok.nuke.

I think people *do* care a lot about being able to re-brand their 
application in two year's time when the marketing guys wake up and 
decide to change everything.

> This is a limitation of the whole macro mechanism. I've never really 
> been entirely happy with macros. I hope we can fix this with an 
> in-processing post-processing approach, where you can apply views on 
> HTML generated by other views using XPath expressions (along the lines 
> of match templates in Genshi). I realize this is not the normal Grok 
> approach where we codify existing patterns, but I am not that thrilled 
> with the existing pattern here. :)

See my other post - I think this solves one part of the problem, but not 
necessarily the whole problem.

The further away we can get the logo and stylesheet and colours and 
basic page layout (three columns vs. two etc) from the bits that manage 
"functional" markup (stuff that needs to be there for the UI to make 
sense and work), the better imho.

>> Like I said, in simple applications these tasks are 
>> performed by the same person, who may not care about separation or even care that much
>> about visual look-and-feel, settling for something quite rudimentary. However,
>> when the time comes to make that leap, or even for developers who prefer to do
>> the visual fluff at the end, I think this separation would be useful.
> 
> Such a separation is indeed attractive. I'm worried about the conceptual 
> overhead it entails for the simple case. For many smaller applications 
> doing this separation isn't worth. Grok in other areas tries to bring 
> things closer together (without losing flexibility, hopefully), and 
> introducing a strong separation between theme and template pulls in the 
> other direction. Note I'm just expressing worries - I think these 
> potential problems might be overcome, we just should be aware of them.

I think it's almost a problem that overcomes itself. If you are able to 
"compose" UI pages in one way and then apply a branding to it in another 
step of the pipeline, then you can always (well, always if we design it 
right) choose to ignore the "theme" part of the pipeline and just stick 
your app-look-and-feel-and-branding markup straight into the "compose" 
templates.

Martin