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

[Phillip J. Eby]

At 10:29 AM 7/18/03 -0400, Phillip J. Eby wrote:
>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.

Okay, so it looks like the skin is now going to be computed before 
traversal begins, as it will be used as the parent component for the start 
location.  This means that all locations will be able to receive properties 
from the skin.  Templates will then be accessed using bindToProperty or 
some equivalent thereof.  Most likely, there will be some sort of shortcut, 
so you don't have to spell out your module's full name in every binding.

In peak.ini, and in whatever configuration is loaded for a skin component, 
there will be a default rule that maps these template property names to a 
lookup for a template (or other resource) bundled with the module.  Any 
such resources will be instantiated with the skin (or top-level app root, 
if no skins are present) as their parent component.  Thus, they will be 
able to access any other part of the skin via bindToProperty() or 
equivalents.  Resources will also be cached in the property map where they 
are found, which again means the skin, or the top-level app root.

The net result is that it should be trivial to refer to a template file 
from code, just using a binding.  But, it will also be trivial to override 
such a template via the config system, or define multiple skins that 
replace the template differently.

To take further advantage of skin-specific properties, the template design 
for the 'view="list"' attributes is now different.  Instead of following 
Woven's approach of view paths and a view stack, view names will be dotted 
property names, looked up in the skin, under a property namespace like 
'peak.web.views' or some such.  So 'view="list"' looks up 
'peak.web.views.list' in the skin to get a view (view factory?).  I'm going 
to call YAGNI on Woven's "view stack", and just figure that all view names 
should be fully qualified.  If we end up later needing a view stack, so be 
it.  It may also be that instead of having an actual stack, we just have 
tags use their parent tags as parent components, and thus allow tags to 
offer property overrides to their children.


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

It's too early to deal with these in the larger context just yet.  We'll 
start with simple components to deal with low-level issues, like referring 
to a static icon image, and setting them up to be usable as 
properties.  Later, we'll figure out how to configure and compose larger 
structures.  (Note that skins won't be composed of locations, any more, so 
we don't need to create a layering mechanism for locations.  Also, the 
'forUser' argument I added to 'getSublocation()' the other day is now 
unneeded, and should be backed out.)

Whew.  I think I now know enough to be able to actually begin developing 
peak.web.templates.  Thanks to everyone who's helped me work all this out.