[Grok-dev] towards a new publisher
sebastian at urbantalk.se
Thu May 27 05:25:58 EDT 2010
I am probably kicking in open doors here... But it would be great if one could prioritize the new publisher to be easy to explain on a page or two even for less advanced developers. And to have that document ready from the start.
25 maj 2010 kl. 18.33 skrev 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:
> (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. :)
> Grok-dev mailing list
> Grok-dev at zope.org
More information about the Grok-dev