[TransWarp] Stream of Skin consciousness, continued...
Phillip J. Eby
pje at telecommunity.com
Wed Jul 30 20:06:16 EDT 2003
At 05:53 PM 7/30/03 -0400, Phillip J. Eby wrote:
>I've been alternating writing this, and coding what I write about, so the
>above is all basically done. What's not done, and still needs to be
>defined, is IResourceManager: do we have one or two getResource()
>methods? Do we ask for "resource package" objects and then traverse the
>rest of the way? Maybe we should split this interface into ISkin, which
>allows cached/aggregated paths, and IResourceManager, which is based
>purely on traversal.
Okay, after discussion with Ty:
* Resources will be referred to as "active" or "passive", but this will not
make any difference in the API or implementation. Thus, skins will have a
'getResource(path)' method, and there will be a 'web.bindResource(path)'
function to bind templates, images, etc. getResource() will expect a
package-prefixed path, while bindResource() will consider the package
optional and add it in if necessary.
* getResource() will be a "trusted" mechanism, which is to say that it
won't pay attention to security restrictions. But normal security will be
in effect when traversing via /++resources++.
* We will not require physical separation of different resource
types. Instead, permissions and factories will be so as to ensure that
code files in a package are not published (unless you specifically override
* Resource directories and resources will use the preTraverse() method to
perform security checks, rather than within the traverseTo() method. This
is so that direct traversal (as done by getResource()) will be "trusted",
but via-the-web traversal will be checked. Active resource classes will be
written such that their preTraverse() calls interaction.notFound(),
simulating the non-existence of the resource. (Since active resources
should only be accessed in context of a non-resource published object.)
The net result of all this is that it should be straightforward to set up
traversal of a set of layered resource sources.
In order to implement the above, though, some interesting changes were
required. InteractionPolicy has now become the pivot point for web
applications. Previously, CGIPublisher picked the interaction class, which
in turn picked the policy (by adapting the app to
IInteractionPolicy). Now, CGIPublisher does the adapting to the policy,
and the policy determines the interaction class. This is because
traversing requires an interaction object, but skin.getResource() doesn't,
so skins need to create a dummy interaction for "trusted" resource
traversal. That's rather ugly, but there's not really any way around it
that I could see.
Tomorrow, I'll start in on creating actual "layer" objects for skins. At
the current rate, I'm guessing maybe we can be actually using resources and
templates sometime next week. But, we'll have full skinnability, and in
the process of going through all this stuff I've been finding and cleaning
up all sorts of nitpicky issues and corner cases.
More information about the PEAK