[Grok-dev] Re: Skinning/themeing
kevin at mcweekly.com
kevin at mcweekly.com
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" />
>>>>> 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("""\
>> 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):
> 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
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,
PS: I hope this all taken light-hearted, as it is, and should be. :)
More information about the Grok-dev