[Grok-dev] towards a new publisher

[Chris McDonough]

One other very important thing... I would make the base system work
without any need for thread locals.  If I continued to use the ZCA, this
change would imply that there would always be a "registry" (ZCA registry
object) attached to the request and programmers would be expected to use
it; the global ZCA API would not work.

- C

On Fri, 2010-05-21 at 12:19 -0400, Chris McDonough wrote:
> FTR, here's a "if I had it to do all again" list:
> 
> - I would totally decouple the call signature of view callables from 
>   the adaptation arguments used to find the callable.  This is
>   the case in BFG right now: the code which finds a BFG view callable
>   is actually a named adapter with three provides arguments
>   at the moment, but we don't use getMultiAdapter to both find
>   and call the view; we just use adapters.lookup to find one, then
>   call it with arguments that make more sense.  The view callables
>   themselves accept either (context, request) or just (request,).
> 
>   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.
> 
>   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 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.
> 
> On Tue, 2010-05-18 at 19:40 +0200, Martijn Faassen wrote:
> > Hi there,
> > 
> > Souheil CHELFOUH wrote:
> > > I'm very enthousiastic about that.
> > > My only thought is that, we should start designing it and, if we find,
> > > along the way that it looks like things we can take from other
> > > projects, so be it.
> > 
> > Here are some of my design thoughts:
> > 
> > * no need to support the APIs of the current publisher
> > 
> > * retain model/view separation
> > 
> > * should it be adaptation of (request, context) instead of (context, 
> > request)? (see ChrisM's blog)
> > 
> > * expand views with predicates
> > 
> > * explore functions as views
> > 
> > * support traversing and routing (traject)
> > 
> > * still be location-aware (__parent__ and __name__)
> > 
> > * URLs can be automatically constructed for models (like they are now)
> > 
> > * Use WebOb's request and response implementation
> > 
> > * everything in a reusable package. This is enough to create web apps.
> > 
> > * everything to support Grok-ish things in another package that builds 
> > on this. This would teach the system about specific objects that are 
> > traversable, etc.
> > 
> > * trigger per view whether new or old system of traversal is in use for 
> > looking it up? (by a different base class, or a directive?)
> > 
> > * concept of "path consumption", where a traverser consumes a path step 
> > by step, where a consumer like traject might consume multiple steps at once
> > 
> > * consumption all the way to the last model, then look up either index 
> > if no more path segment is available, or otherwise look up the view.
> > 
> > * nested views (views on views) would be nice, but aren't essential.
> > 
> > * We need to support things like @@ at the very least to support 
> > backwards compatibility.
> > 
> > * path steps are in a namespace (with a default). So, 
> > foo/bar/++view++baz decomposes into the follow namespace, name tuples 
> > ('default', 'foo'), ('default', 'bar'), ('view', 'baz').
> > 
> > * support layers and permissions on views. Perhaps these can be 
> > interpreted as specialization of the predicate system.
> > 
> > * exception views should be supported
> > 
> > * let's produce the more clear and helpful error messages we can do
> > 
> > * we might be able to build things on zope.interface.AdapterRegistry 
> > sidestepping zope.component. traject already had to do this. This way 
> > it's easier to do non-global registries that are attached to the 
> > application or the wsgi environment or the request or something. There 
> > are drawbacks to this too (people might not think to look there for 
> > introspection).
> > 
> > Regards,
> > 
> > Martijn
> > 
> > _______________________________________________
> > Grok-dev mailing list
> > Grok-dev at zope.org
> > https://mail.zope.org/mailman/listinfo/grok-dev
> > 
> 
> 
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>