[Grok-dev] view-no-view Was: Grok 1.0 final?
optilude+lists at gmail.com
Thu Apr 16 11:27:49 EDT 2009
Jan-Wijbrand Kolman wrote:
> Martin Aspeli wrote:
>> For the record, I need a view-with-no-rendering-at-all component. I want
>> to be able to define a "utility" view that I can traverse to and invoke
>> methods on from templates.
>>> For backwards compatibility the first will keep the name "View" and the
>>> latter will be called "CodeView".
>> Sure. What will you call the one with no 'render' or default __call__? ;-)
> (I vaguely remember you mentioned this before, can you point me to the
> right thread?)
I can't remember either. ;-)
> Not sure what mean to accomplish. Would it be something like this?
> import grok
> class Viewnoview(grok.Application, grok.Container):
> class Index(grok.View):
> pass # see app_templates/index.pt
> from zope.interface import Interface
> class NotReallyAView(grok.MultiAdapter):
> grok.adapts(Viewnoview, grok.IBrowserRequest)
> def __init__(self, context, request):
> self.context = context
> self.request = request
> def just_do_something(self):
> return "Something!"
> <tal:block replace="context/@@notreally"/>
> <tal:block replace="context/@@notreally/just_do_something"/>
Yes, but using grok.MultiAdapter won't work, because views get
additional stuff like security applied. At least in Zope 2, you need a
fair amount of majik normally provided by the browser:view/page directives.
I'd also like to avoid having to add the boilerplate __init__, and I'd
like the same context/layer semantics as a regular view to skip the
IBrowserRequest boilerplate and the provides(Interface).
> I'd like to note though that the mechanism for pagetemplates to be able
> to "traverse" to "context/@@notreally" is more or less the same as going
> to the URL "http://localhost/myapp/@@notreally".
Almost, but not quite, indeed. They're more divergent (annoyingly) in
> In other words, I do not think it would be easy for Grok to have a
> "view-ish" component available in ZPT paths, but not accessible through
You don't need to do any magic here. If the view class doesn't have a
__call__ it won't render when you traverse to it. Security still needs
to be applied to methods, of course. Security applies on URL traversal,
but not on path traversal. In most cases, you don't need the equivalent
of ZCML's allowed_atributes, then, but it'd be important to be able to
do this too.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Grok-dev