[Grok-dev] view predicates in Grok?

[Chris McDonough]

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.

> This indirection allows
> the system to interrogate the predicates to find a matching view. The
> order in which the views are evaluated depends on a pre-computed score
> that is determined by the relative importance of the predicates that
> it defines. I'm a bit vague on this at the moment though.
> 
> So a multi-view class would need to be defined, the view grokker
> revised, and some strategy for communicating predicates (for which the
> obvious choice would be martian directives).
> 
> HTH,
> Paul
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>