[Grok-dev] towards a new publisher
faassen at startifact.com
Tue May 25 12:33:20 EDT 2010
Chris McDonough wrote:
> FTR, here's a "if I had it to do all again" list:
Thanks for the input!
> If I had to go back in time, I would make view callables
> always just accept "request". "request" would be sort of
> a garbage barge namespace; I'd attach "context" to the request
> as necessary for people to peel off and use as necessary.
Kind of the opposite of what one could do in Zope 2 (get the REQUEST
from the context). :)
What are the reasons for stuffing context in request?
> In fact, if I had it all to do over, I would probably not use
> zope.interface or zope.component to implement core BFG features
> like view lookup. Once view predicates are involved,
> view lookup is no longer ever just straight adaptation. The ZCA
> can sometimes be used to optimize one phase of the lookup
> but given that it's the outer loop, it's sort of not on
> the critical path in most apps.
I like the ZCA (or to be more precise, zope.interface's AdapterRegistry)
because it knows about subclasses. It's a bit of work to do something
like that. Earlier this year we took a stab with some of it here:
(with a data structure designed for optimization)
but so far it only solves half the problem (adapting from, but not yet
adapting to). I see marco contains bits of this too.
> - I would build BFG atop a subsystem that allowed use by frameworks
> with simpler view lookup requirements.
> http://bitbucket.org/chrism/marco is such a system. Then I'd build
> BFG atop that and try to convince other framework authors (Pylons,
> etc) to share the same subsystem.
Well, you're actually doing it, instead of would do it. That looks
I take it this factors out a bit of BFG, and you replace
zope.interface/zope.component/zope.event with local implementations. But
not the configuration system. :)
More information about the Grok-dev