I like this.

Some variations:

- Have IOWrap be a multiadapter on context and request, so we can vary the 
o-wrap based on request type too (e.g. "IManagementRequest" vs. 

- If IOWrap can't be adapted, just return the result of the view (instead of 
throwing a component lookup error).

Please forgive the digression, but this is physically sort of tied in: we still 
need a good way to allow a set of "top level names" to be supplied to 
  So far, the best we could do for that pattern has been something like ("api" 
is not a good name, I can't think of anything better, though):

class TemplateAPI:
    def __init__(self, context, request):
        ... do stuff ...

Then in a view:

api = TemplateAPI(context, request)
return render_template_to_response('templates/mytemplate.pt',

When the template needs access to "common" names, it then does e.g. 

Malthe said it might be possible to register one or more new TAL expression 
types (each of which might represent a namespace) so templates could do 
something like tal:content="api:something" (note colon instead of dot) to get 
top-level names instead.  The view would no longer need to pass an "api" to 
provide the template with access to very common top-level names.

However, computing the values for the top-level names often requires access to 
stuff in the request or the context, and the current "render_template" APIs 
don't require that you pass either in to the view.

I guess we could provide an alternate implementation of the template* APIs 
render_template_to_response and get_template, etc) that must be passed the 
request (the request has access to the context too as request.context) as the 
first argument if values for names needed to be computed based on those bits of 

If views had access to top-level names like this, we could also just do owraps 
the more traditional way (using METAL), if one of the names was e.g. 
"main_template".  I suppose the names would be computed via an adapter lookup 
just like the rm.owrap stuff does now.

That said, I don't think that approach is mutually exclusive with the pagelet 
approach.  The pagelet approach is more generic: any templating language could 
be used for the owrap or the wrapped view; the same can't be said for the 
top-level-name way.  Maybe some combination of both.

On 8/24/09 2:14 AM, Robert Marianski wrote:
> I was thinking about different ways to apply the owrap theme that's
> typical for most applications.
> I like the way that z3c.pagelet does it:
> http://svn.zope.org/z3c.pagelet/trunk/
> To summarize, views are registered through a different directive, and
> then a layout is applied with a special directive. The advantage here is
> that the views no longer specify their master template. It's configured
> externally through zcml. This, theoretically anyway, allows more view
> reuse since they can be registered with a separate owrap in a different
> application without modification to the view code.
> Anyway, I have a simple poc implementation for repoze.bfg.
> $ svn co http://svn.repoze.org/playground/rmarianski/rm.owrap/trunk/ rm.owrap
> $ cd rm.owrap
> $ python bootstrap.py
> $ bin/buildout
> $ bin/test
> $ bin/paster serve src/dummyapp/dummyapp.ini
> Like z3c.pagelet, it adds a new directive for view registration. But
> instead of a new directive for the layout, it just uses a plain adapter
> to get the owrap. A new directive might be better because it would stand
> out more in the zcml, but it was easier to do this way for a poc.
> Robert
> _______________________________________________
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org
> http://lists.repoze.org/listinfo/repoze-dev

Repoze-dev mailing list

Reply via email to