[Grok-dev] towards a new publisher

[Martijn Faassen]

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