[Grok-dev] towards a new publisher

[Martijn Faassen]

Hey Chris,

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:

http://svn.zope.org/Sandbox/faassen/iface/

(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 
interesting.

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. :)

Regards,

Martijn