[Grok-dev] Re: Skinning/themeing

Sun May 20 04:03:21 EDT 2007

Quoting Martijn Faassen <faassen at startifact.com>:

> 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?

I only use this particular method in examples to keep it brief! :)

However, I feel like this is a bit of an overreaction. Putting  
templates in the __doc__ won't kill kittens, or doom one to a life of  
eternal perl programming. Even python noobs learn about __doc__.

With megrok.quarry.template, using dotted notation, any object that  
can be imported can be template, including inline pagetemplates,  
strings and unicode. So they can be put in the docstring.

For short templates, or short ajaxy stuff, I put the template right in  
the docstring of view class using quarry.template('__doc__'), that way  
everything I need to see is right there.

For shared templates, I use  
quarry.template('myproject.common.atemplate') to reference a  
basestring object.

IMO grok shouldn't be made so inflexible that it dictates how I might  
style my code, where I must stick my templates... or even what editor  
*cough*emacs*cough* should be. :)

For the masochistically curious: With the exception of the masterpage  
and a handful of pagelayouts, I keep my templates inline. Using the  
grok default inline pagetemplate method, creates a lot of dead  
chickens. Which in this case seems unnecessary since the template  
definition is plainly obvious in the module.

For development I use screen, emacs and Firefox on openvz instance  
running Debian 4.0. I keep templates in "one file" because one screen  
instance runs the server. The second screen instance runs emacs with a  
split screen of app.py in the left buffer and templates.py in the  
right buffer. C-a C-a to toggle between restarting the server and  
emacs. C-x o to "toggle" between the left and right buffer. Many  
templates mean many open buffers or many files to hunt down. Buffer  
searches waste time, toggles save time.

And for ironic amusement: The 'provider' namespace is not available  
and will raise an error in in-line pagetemplates - only  
pagetemplatefiles. Not sure if this is a bug in Grok or upstream. :)

Keep on grokking in the free world,

Kevin Smith

PS: I hope this all taken light-hearted, as it is, and should be. :)