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

[Phillip J. Eby]

At 08:28 PM 7/14/03 -0400, Phillip J. Eby wrote:
>Current Tasks for peak.web
>--------------------------
>
>* 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.

I just realized that a (possibly significant) part of my plans for peak.web 
templates is based on some bogus assumptions.

I've been thinking that templates would be used as methods on 
locations.  However, this doesn't really work.  First, if a template is on 
a location, this means it is not part of a skin, so it can't access any 
views.  Second, the template itself obviously can't be different from one 
skin to another, since it is bound to the location!  Third, if templates 
are not on the location, but instead are linked by some kind of binding 
from the location to a part of the skin, this leads to namespace management 
difficulties, because bundles of components will want a namespace of their 
own in which to find their pages and views.

So...  I need to work out another way to handle this.

One of the first things that comes to mind is protocols.  Perhaps skins 
could be treated as variations of the locationProtocol.  In fact, we could 
ditch the concept of a skin altogether and replace it with the 
locationProtocol.  This would let us permit different skins to have 
different behavior and/or navigation.

In practice, though, we don't really want different skins to behave so 
differently.  Really, we just want to substitute certain values or 
components in each skin.  Parameterize, more than anything else.  This 
sounds more like a job for configuration properties.  In that case, a skin 
would just be a component on which properties are looked up!  Pluses: one 
could define a skin or layer using an .ini file, and layer them together 
via inclusion.  Properties could also supply values (e.g. "items per page") 
as well as pages and views.  Minuses: it's not clear to me just yet how to 
do view paths or a view stack for a page, or how to ensure that a page only 
has to be compiled once within a given skin.  It's possible the latter can 
be accomplished by "load-on-demand" rules, but my memory of their 
capabilities is a bit fuzzy at the moment.

Another issue that would have to be resolved is how to set up reasonable 
defaults and conventions for organizing the property namespace.  Ideally, 
it should be easy to refer to a page in code, especially using a page 
bundled in the code's package directory as a default value.  There needs to 
be a way to load properties by reference to a directory of static resources.

I'll have to think about this some more.


>* 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.)