[TransWarp] Stream of Skin consciousness, continued...

[Phillip J. Eby]

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

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