[Grok-dev] towards a new publisher

Sebastian Ware 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.

Mvh Sebastian

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:
> 
> 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
> 
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev



More information about the Grok-dev mailing list