Tim Hoffman wrote:
> HI Chris
>
> I a way you describing something simliar to what we have in zope2, in
> that from a tal expression we have access to
> (via acquisition) all of the portal tools etc...
>
> I wonder if a couple of hi level functions could be put into the
> namespace, (or the view for instance) that allow you
> to lookup adapters and utilities in a simpler way, or alternately use
> a view class and push the view handle into the template
> and hang all of the extra api you need there. I have taken to useing
> view classes most of the time and
> always providing "view" as well as context and request.
That's another way to think of it, yep.
BFG views can be classes, but aren't necessarily classes, so I'd like to
try to find some solution that would take this into account.
I suppose that we could come up with a "page" directive that wrapped a
callable which always returned a dictionary:
<page
callable=".pages.my_page"
template="templates/mytemplate.pt"
/>
The callable referenced by the directive would be something that
promised to returne a dictionary, e.g.:
def my_page(context, request):
return {'a':1}
The BFG view wrapper created by the "page" ZCML definition would look
more or less like so:
from webob import Response
class Page:
def __init__(self, callable, template):
self.callable = callable
self.template = template
def __call__(self, context, request):
dictionary = self.callable(context, request)
dictionary.setdefault('page', self)
return Response(self.template(**dictionary))
view = Page()
But having "page" in the template namespace won't help us too much
unless we can vary the page view wrapper implementation, adding methods
and such, at least on a per-application basis, ala:
<pageview
implementation=".page.MyPageView"/>
Seems a little clunky though, eh?
- C
>
> T
>
>
> On Sun, Sep 13, 2009 at 5:43 AM, Chris McDonough <chr...@plope.com> wrote:
>> So I've been trying to puzzle out some issues, which might or might not
>> be related to this topic.
>>
>> In KARL, we currently write all of our views something in the form of:
>>
>> def myview(context, request):
>> [ do stuff ]
>> api = TemplateAPI(context, request) # a utility class
>> return render_template_to_response('atemplate.pt', api=api,
>> foo=1, bar=2)
>>
>> In the template, we do things like "tal:replace="href api.context_url"
>> and so on. Basically, the KARL "api" object is a "garbage barge" of
>> utility attributes and functions totally specific to the application
>> itself. There is nothing general about it.
>>
>> What I'd like to do is to be able to write a KARL view like this:
>>
>> def myview(context, request):
>> [ do stuff ]
>> return render_template_to_response('atemplate.pt', foo=1, bar=2)
>>
>> ... but still have some way of accessing the KARL "api" in the template.
>> In essence, I'd like to put the BFG templating system in charge of
>> adding one or more globals that is accessible within the template.
>>
>> There's a half step towards this that's simple. It'd be relatively easy
>> to put both "context" and "request" into the names passed to all
>> templates. But this doesn't help us very much in the common case,
>> because then we'd need to write a lot of hairy expressions to compute
>> things based on those values. Basically the template would assume the
>> job of our current "API", which is not ideal.
>>
>> It'd be better if we could add some configuration that would one or more
>> globals to a template's namespace. For example, one configuration might
>> look like (via ZCML):
>>
>> <templatename name="api" component=".api.TemplateAPI"/>
>>
>> The ".api.TemplateAPI" class would accept, say, a context and a request
>> (or just a request, as requests already have a context attribute), ala:
>>
>> class TemplateAPI(object):
>> def __init__(self, context, request):
>> self.context = context
>> self.request = request
>> self.context_url = model_url(context)
>>
>> At this point the name "api" would just be jammed into the template
>> names on each template rendering and it could have both attributes and
>> methods accessible via "api.whatever".
>>
>> At some point I had considered using a Chameleon expression prefix to
>> separate these sorts of "builtin" names from the main template namespace
>> names. For example, instead of "tal:replace="href api.context_url",
>> you'd access builtins via an expression type, e.g. "tal:replace="href
>> api:context_url". That bugged Malthe because it's essentially a "second
>> "python:" expression type that happens to not use the "main" template
>> namespace. I'm not sure about it either, because it's obvious that
>> you'll want to use the names passed to the template explicitly in those
>> expressions too, and the semantics and implementation could get pretty
>> confusing if you need to make that possible.
>>
>> Can anyone think of a better way of achieving this goal? If we don't
>> collectively come up with something better, I am apt to just allow folks
>> to register factories via ZCML that produce something that is jamed into
>> the main template namespace, ala the "templatename" ZCML directive
>> above. Any number of them will be registerable. A conflict will occur
>> during ZCML processing if two share the same name. These functions, if
>> they exist, will be called on each template rendering and their results
>> will be jammed into the top-level namespace.
>>
>> Robert Marianski wrote:
>>> On Mon, Aug 24, 2009 at 10:11:04PM -0400, Chris McDonough wrote:
>>>> 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").
>>> Good idea. I'll go ahead and add this in.
>>>
>>>> - If IOWrap can't be adapted, just return the result of the view (instead
>>>> of
>>>> throwing a component lookup error).
>>> I'm kind of torn on this. On the one hand, I like that a specific
>>> exception would get thrown, so it's easy to know when there's a
>>> configuration problem and how to fix it. On the other, getting no wrap
>>> is obvious itself, and may be better for users to initially see an
>>> unwrapped page rather than seeing their applications explode.
>>>
>>> I'd expect that there would typically be a catch-all owrap defined
>>> anyway, so it's unlikely that this will be much of an issue in practice.
>>> But in retrospect again, I think it's better to fail more gracefully by
>>> showing an unwrapped view instead of an exception. I'll go ahead and
>>> make this change too.
>>>
>>>> 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):
>>> Can you give an example use case for this? For the cases in my mind, I'd
>>> prefer to push as much logic out into the owrap as possible, so that the
>>> actual views don't need to worry about it. I can potentially see a lot
>>> more ui reuse if this is possible. For example, I can write management
>>> views against a dublin core interface, and this can be used in any
>>> application now because it's not tied to any owrap macro.
>>>
>>> The fuzzy area in my mind is a dynamic sidebar. I often have cases where
>>> there's *always* a sidebar in the theme, maybe save for a couple of
>>> pages, but the contents change depending on the view. It comes down to
>>> whether you want to manage the contents of the sidebar as part of the
>>> view, or part of the owrap, and I think this depends on how drastic the
>>> changes themselves are.
>>>
>>> I think having the owrap do some sort of lookup to figure out what goes
>>> in the sidebar is more flexible. But in practice, I've found it more
>>> annoying to work with it this way, because it's more convenient to
>>> handle it in the view's template/logic, especially if it's varied on a
>>> view to view basis.
>>>
>>> Is this the sort of thing you have in mind?
>>>
>>>> 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".
>>> I guess I don't exactly follow what the top level common names are. Are
>>> they things like topnav, header, footer, where those are calculated
>>> based on context and security?
>>>
>>>> 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.
>>> I personally like this sort of thing. With zpt in a grok/plone setting,
>>> I've found myself writing traversal adapters for things like checking
>>> security, or application wide custom template "filters". It's much
>>> easier to be able to use these in a template by using this sort of
>>> syntax rather than passing them on through the view. For example:
>>>
>>> <a tal:attributes="href model_url(context, request, 'edit')"
>>> tal:condition="context/has_permission:edit">Edit</a>
>>>
>>> Maybe some sort of syntax for model_url would be convenient too :)
>>> What do you guys typically do?
>>>
>>>> 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.
>>> That sounds reasonable to me.
>>>
>>>> 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.
>>> For cases where the owrap varies a lot from view to view, I think the
>>> metal approach works well. But for times when the dynamicness of the
>>> owrap can be easily calculated from the owrap, I think pushing it to the
>>> owrap makes sense.
>>>
>>>> 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.
>>> Definitely. Although imho, if you're using macros for the wrapping in
>>> all your views, then you have less to gain by using an adapted owrap.
>>>
>>> Robert
>>>
>>>> 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
>> _______________________________________________
>> 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
