[Grok-dev] view predicates in Grok?
chrism at plope.com
Fri Jan 1 21:59:26 EST 2010
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).
> Grok-dev mailing list
> Grok-dev at zope.org
More information about the Grok-dev