[Grok-dev] towards a new publisher
faassen at startifact.com
Tue May 18 13:40:36 EDT 2010
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
* 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
* 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
More information about the Grok-dev