[TransWarp] Some notes on peak.web templating, etc.
Phillip J. Eby
pje at telecommunity.com
Fri Jul 18 10:29:57 EDT 2003
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
>* 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.)
More information about the PEAK