[Grok-dev] towards a new publisher

[Chris McDonough]

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
>