[Zope3-dev] Re: Zope 3 web root

[Wade Leftwich]

Shane Hathaway wrote:
> Wade Leftwich wrote:
> 
>> Shane Hathaway wrote:
>> [snip]
>>
>>
>>> Yes, that's a valid point.  I also stopped myself from listing folders,
>>> since a folder is a general organizational tool.  Let's just talk about
>>> templates and scripts.
>>>
>>
>> [snip]
>>
>> I think I've got a decent use case for templates in the ZODB, but I
>> could be wrong. I work for a large publishing company, and typically one
>> of our applications will get installed on 40 or 50 sites within the same
>> Zope instance, differing only in cosmetic ways. It seems like the
>> logical thing to do here is to treat the templates as data and let them
>> be edited TTW, limiting the coding level to 'presentation  only'.
> 
> 
> That can work, but be aware of the customers who customize more than you
> expect.  They'll push the limits of the templates, and some of them
> might push so hard that they wind up creating a whole new framework
> based on your template API.  You'll have to help them migrate their
> templates to new versions of your software, you'll have to put their
> templates under version control, you'll have to test new versions of
> your system with their templates, etc.
> 
> I saw this pattern emerge several times at Zope Corporation, and I don't
> think it's specific to Zope 2.  Maybe you can design a system that
> exposes a perfect, unchanging API to templates, but I'm pretty sure I
> can't.
> 
> Shane
> 
> 

We're supporting corporate users, so s/customers/coworkers/, but I see
your point, and am interested in some of the less featureful templating
alternatives being discussed -- meld3 et al. In Zope 2 our group follows
the approach described by Stefan Holek in the "tal:define considered
harmful" thread earlier today, and we put all the data the template is
going to need into the "options" namespace.

>From Stefan's post:
"""
My take is that it's not the TAL features (tal:define, python:,
whatever) that invite misuse, but the available namespaces.

I have ported ZPT to Django [1][2] and found the experience
surprisingly refreshing. Django naturally does not have anything like
"container" or "context" in the Zope sense. And by Django policy,
templates don't even get to see the "request". The namespace Zope PTs
call "options" becomes the sole, top-level namespace in Django PTs.

This very effectively keeps me from pulling-in anything not provided  by
the view in the first place. Everything -- even functions I want  to
call in, say, conditions -- has to be added by the view. The  result is
clean and fast templates.
"""

-- Wade