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.
"IRetailRequest").
- 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
templates.
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',
api=api)
When the template needs access to "common" names, it then does e.g.
tal:content="api.something".
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
(like
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
information.
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
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
