[PEAK] sitemaps: <content> in non-root <location>

[Phillip J. Eby]

At 03:27 PM 1/5/05 +0100, Radek Kanovsky wrote:
>I could see two solutions:
>
>     1. Location.traverseTo leaves context for 'self' in context stack
>        instead of cloned context for container.
>
>     2. Context.viewHandler algorithm will count with context clones.
>
>Variant 1 is better if one relies on some location helper defined via
>'class' attribute. Containers could remain accessible for example by
>names from location:
>
>     <container name='numbers' object='....'/>
>
>Although, there is question, if anybody need multiple containers in one
>location. Such special cases could be implemented by Location subclass
>specified in 'class' attribute of location tag and container mechanism
>can be simplified.
>
>Variant 2 works now. It is necessary to keep 'clone_from' attribute in
>Context instances:

I think there's a simpler solution than either; the 'clone()' operation 
called inside Location.traverseTo() should simply become:

             context = ctx.clone(current=cont, viewHandler=self.viewHandler)

This should do the right thing in the specific circumstances; i.e. ensure 
that the traversal into the container and beneath includes the current 
location's view definitions.

A fix (with tests) is now in CVS.  Sorry I didn't get to it sooner, but 
I've been a bit distracted with a variety of other things, such as 
negotiating some paying work, and helping to do year-end inventory at my 
wife's store.  As you may have also noticed, I just finished the 
peak.security rewrite, and hope soon to do a comparable refactoring of 
peak.web's internals.

I don't expect templates to change, except as needed to accomodate the 
internals changes.  The sitemap system will remain largely intact, except 
there will be some added features and how the view system works internally 
will probably get switched to using generic functions.

The main visible change is that I need to restructure the balance between 
IInteractionPolicy, IInteraction, and ITraversalContext (at least).  The 
current IInteraction includes a 'user' attribute, and I want to move that 
away and into an aspect of the traversal context or the request 
'environ'.  I'm also concerned that there are far too many things hanging 
off the side of traversal context objects, and yet applications need to 
have their own special objects too, like shopping carts or preferences or 
other such things.

So, I'd really like to have a means whereby all but a few absolutely 
critical context attributes are dynamically computed via a property 
namespace, so that you can extend the '/' namespace that's used by 
templates to include whatever specialty properties you want.  Ideally, 
there would be ones that are context-specific, and ones that are 
request-global, but I'm still thinking through how that will all fit 
together, and how to make it reasonably efficient.  I'll probably write 
another post sometime soon to work out the details.