[TransWarp] Some notes on peak.web templating, etc.

[Phillip J. Eby]

Current Tasks for peak.web
--------------------------

* Improved error handling: there should be an 'errorProtocol' to which 
exceptions are adapted, in order to invoke an appropriate handler.  This 
will allow us to declare that some given kind of error is ignored, logged, 
emailed, etc., for a given application.

* Location protocol revision: getSublocation() needs an optional 'forUser' 
keyword, that specifies whose access rights should be used.  If 'None', no 
security check should be done.  This is to facilitate using locations as 
"views" by the templating system, and also to facilitate using the 
Interaction as a root "model" component.

* Skins mechanism: there needs to be an InteractionPolicy.skinService, to 
determine the skin to be used by a given interaction.  The template system 
will use the skin as the root "view" namespace.  The default skin service 
will probably just use the application root for this, or whatever makes 
sense when I implement it.  Skins will use the same "location" concept for 
traversal, although it's not clear whether they should use an app-specific 
variant, and if so, whether it should be the same location protocol or a 
separate one.

* Templating: there needs to be a mechanism to use page templates as 
methods of locations or even of application classes.  They may also need to 
be usable as static methods, to be part of a skin namespace (e.g. templates 
that themselves are views for use in other templates, equivalent to ZPT 
macros).  Templates will need to maintain a view stack for views.  For the 
model namespace, templates will track their current traversed-to ('here'?) 
location, and the interaction object.  The model path '/' will refer to a 
wrapper around the Interaction, that will supply some top-level namespaces 
similar to those used by ZPT (e.g. request, response, user, app, root, 
etc.).  These top-level namespaces will not be subject to security 
controls, but all other "model" locations will be.  It is up to an 
individual view component to decide how it will handle unauthorized or 
not-found model locations.  Presumably, most views will simply skip over 
unauthorized items.

* notFound()/notAllowed() handling for traversal: we don't know what to do 
with these yet.  There needs to be a pluggable mechanism for this, that 
should go in the InteractionPolicy.  But the details of how and what aren't 
clear yet.

* Static Resources: there needs to be a way to map static filesystem 
resources into locations/views.

* Layerable locations: there needs to be a way to layer locations together 
to allow creation of skins from layers.  (Note that if we are using the 
same location protocol for the model space, we can lay applications atop 
one another as well, although I don't see many uses for that.)

* "Smart" locations: the IWebLocation protocol may need to expand later to 
include URL knowledge and/or URL manipulation methods.



Future Directions
-----------------

These are technically not part of peak.web, but will affect how easily one 
can create applications for it:

* storage.DMFor() or something like it, to easily link to DM's.  Perhaps 
also an extension of the concept for query DM's, unless the query DM's are 
always going to be available as subcomponents of the main DM.  (This needs 
more thought.)

* Tabular data store API: we could do with developing an API for tabular 
data stores, that allows 'findOne()'/'findMany()' calls with keyword 
arguments that supply criteria for the "table"'s fields.  Criteria values 
would be adapted to a criteria interface (with the default interpretation 
that the value was a literal to be used with '=').  This would let us 
encapsulate views, tables, joins, and even LDAP subtrees/queries behind a 
simple interface.  In principle, one could also implement adapters that 
implemented things like renaming of columns, joins across multiple tables, 
etc.  The API part of this effort is deceptively simple; implementing 
useful backends will be more complex.  We might be able to leverage one of 
the many existing Python SQL mappers, for implementation ideas if nothing else.

* Event system: peak.security's security rule adaptation framework 
demonstrates how easy it is to use PyProtocols to set up a dispatch 
mechanism for "business rules".  We should investigate whether this can be 
extended as a general purpose rules mechanism for peak.model objects, 
possibly up to and including using them as a persistence mechanism.