[PEAK] sitemaps: <content> in non-root <location>
Phillip J. Eby
pje at telecommunity.com
Thu Jan 6 00:42:36 EST 2005
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
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
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.
More information about the PEAK