[Grok-dev] view predicates in Grok?

[Chris McDonough]

Chris McDonough wrote:
> Paul Wilson wrote:
>> 2010/1/1 Martijn Faassen <faassen at startifact.com>:
>>> * investigate how BFG's implementation works, and whether it can reused
>>> and/or extracted somehow. (if extracted we'll need to figure out where
>>> we can maintain the extracted bits, i.e. what are the possible rights
>>> issues around importing this into svn.zope.org?).
>> Its interesting, at a high level:.
>>
>> It looks like their scanning procedure finds views and groups them by
>> (context, request, name). Since a collection of views may share such a
>> type-tuple, there is a one-to-many relationship between them:
>>
>> (ContextA, RequestA, 'some_name') ------> [ViewA, ViewB, ViewC]
>>
>> and the various views differ only by their predicates only. The list
>> of views is modeled as a 'MultiView' class, which is what actually
>> gets registered. (My initial thought was that subscription adapters
>> must be at work - but apparently not.)
>>
>> During the scanning phase, the type tuple of a view is found, and
>> looked up in the component registry, If no such MultiView exists for
>> it, one is created and the view is added to it. This wouldn't fit with
>> Grok btw, because the grokker only registers a configuration *action*
>> - a callable - and doesn't play with the registry until after all
>> views have been found, as far as I'm aware. The view grokker would
>> need to keep track of what's going on here.... This shouldn't be too
>> difficult because at this stage we don't care about type-relationships
>> between the tuple-types.
>>
>> So, when a request comes in, the component registry resolves to a
>> multiview (rather than directly to a view).
> 
> All of what you're saying is true (nice work), except really BFG does resolve a 
> request to a view  It may happen to be a multiview, but BFG as the caller, 
> doesn't really care.  This is because we don't actually register a multiview 
> until more than one view is registered for the same 
> request_type/context_type/name triad; only an actual view is registered til 
> more than one view wants to claim this.

I should probably also mention that this implied a change in the way we thought 
about security.  Before we had multiviews, when a view was found, the 
*publishing logic* did an authorization check before invoking the view; if the 
authorization check passed, the view was invoked.

With the introduction of multiviews, it became obvious that this wouldn't work, 
because the result of the adaptation didn't match a single view.

Instead, we made *views themselves* responsible for doing authorization 
checking.  This kept the view invocation logic simple.  Every view registered 
is now responsible for providing its own authorization checking.  Even views 
that are part of a multiview are security-wrapped in this way, if an 
authorization policy is in effect.

This isn't a problem in practice, because all views registered via every 
supported configuration method (ZCML, scanning, imperative config) get wrapped 
in security checking logic before they are registered if an authorization 
policy is in effect.

- C