[Grok-dev] Re: Skinning/themeing

Sat May 19 17:11:40 EDT 2007

Martin Aspeli wrote:
>>>> class MyView(quarry.View):
>>>>    """<html metal:use-macro="context/@@master/page">
>>>>       <body metal:fill-slot="body">
>>>>       <span tal:replace="structure provider:myviewlets" />
>>>>       </body>
>>>>       </html>
>>>>      """
>>>>    template = grok.PageTemplate(__doc__)
>>> Yipes! I realise this is just an example, but the idea of using the
>>> docstring like that feels very dirty. :)
>>
>> I would submit that for short clips, what documents a view class
>> better than the code itself? :)
> 
> I completely disagree. The use of __doc__ there is illogical.
> 
> class MyView(quarry.View):
> 
>     template = grok.PageTemplate("""\
> <p>foo</p>
> """)
> 
> That makes a lot more sense, and it's a lot clearer what that HTML does. 
> In the example you gave, if I didn't realise __doc__ was being 
> overloaded as input to a page template, I'd be scratching my head as to 
> why you pasted HTML into a doc string.

Actually we already have had this from the beginning:

class MyView(grok.View):
    pass

myview = PageTemplate("""
<p>My template goes here</p>
""")

i.e. instead of putting a page template in <module>_templates you can 
always define it on module-level.

Kevin must have a reason not to use this?

[snip]
>> This does bring up a good point, where is the line drawn for
>> convention-over-configuration. I think that Martijn and Phillip have
>> done a great job of deliberating this and I certainly defer to them in
>> these aesthetic matters.
> 
> Completely. It's dangerous if we end up with a "too many cooks" feel to 
> the framework. Maybe we need some high level guidelines of what type of 
> CoC we want to have?

This work is being done in an extension. I'm glad the exploration is 
taking place at all (and glad to see Martin give feedback to it, 
something I haven't gotten around to doing yet). Rest assured we're not 
going to move this into the Grok core without some additional thought. 
We should indeed be careful in deriving configuration from conventions.

Name-based ordering is not something we've done before. We use names for 
association with templates. We also have one other case - if your 
classname ends with 'Base', you indicate you don't want it to be 
registered as it's a base class. You can also use grok.base() to 
indicate the same thing, and perhaps this means the name construct could 
actually go away here.

Um, some attempt at expressing what's being looked at now:

* base classes of classes found in a module

* classes of instances found in a module

* module name (to find templates directory)

* names of classes

* names of instances

* being in the same module as a context

* schema fields

* directives

Another aspect I'd like to be able to look at in the future for deriving 
configuration information is order of definition within a module. This 
can be used for ordering (where this is useful; I can think of viewlet 
order and perhaps menu entry order), and grouping (group a bunch of 
objects into a single context).

Regards,

Martijn