[Grok-dev] towards a new publisher

[Chris McDonough]

> 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?

It's a natural result of this calling convention:

def aview(request):
    return Response('OK')

With that calling convention, we end up treating the request object as a
namespace that represents more than the HTTP request parameters; it also
must provide access to everything else a developer might need (the
context, in Zope-style apps at least, being an important inclusion).

Desiring this calling convention rather than (context, request) or
(request, context) etc is mostly a result of wanting to be able to share a
common view calling convention with other similar frameworks like Pylons. 
Settling on a shared view calling convention is eminently doable as long
as it's sufficently general.  But Pylons and other similar frameworks
don't have any concept of context, so asking them to include context in
the view args is not realistic.  However, I think it is very realistic to
ask Zope-y developers to obtain the context from the request (e.g.
"context = request.context") instead of asking for it to be passed in.

Here's a document explaining the view (aka "controller" in their world)
calling conventions that I believe that Pylons 2.X (unreleased) will
settle on:  http://bitbucket.org/chrism/marco/src/tip/sharing.rst .  These
happen to be compatible with the current set of calling conventions used
by BFG.

>>   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 was really just talking about doing view lookup without ZCA, because
we've sort of outgrown it there.  Other lookups (hooks, such as replacing
policy) may still fit the ZCA sweet spot.

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

It's a bit of a mishmash currently.  I don't know that there's anything of
lasting value in that particular code, it's mostly just a place to try to
work out collaboration ideas.

- C