[PEAK] sitemaps: <content> in non-root <location>
rk at dat.cz
Fri Jan 7 12:50:44 EST 2005
On Fri, Jan 07, 2005 at 11:38:48AM -0500, Phillip J. Eby wrote:
> >> I think there's a simpler solution than either; the 'clone()' operation
> >> called inside Location.traverseTo() should simply become:
> >> context = ctx.clone(current=cont,
> >> 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.
> >It works except one special case when container itself implements
> Yeah, I thought about that, but I don't think I care about supporting that
> case. If you have that scenario you should use <location
> class="containerclass"> instead of tacking the item on as a container to
> the location. Containers are supposed to be pure containers.
Yes, it wouldn't be a good practice to mix such things.
> >> A fix (with tests) is now in CVS.
> >Then the same fix should be applied to sitemaps.addHelper too.
> >Again, helper can implement IViewService directly.
> If the helper wants to add names, it can do so directly, it doesn't need to
> offer them as views. I don't see much use for it being a view service.
I am not sure if you understand me wholly. When you use helper for some
view in non-root location, this non-root location is not in context
stack. There is cloned context for helper in the stack instead of
context for non-root location. So sitemaps.addHelper should be fixed
def helped_handler(ctx, ob, namespace, name, qname, default=NOT_GIVEN):
ob = helper(ob)
<view name='index_html' resource='...' helper='Help'/>
If you traverse '/sub/@@index_html', context stack looks like this:
ctx.current == <Help>
ctx.current == <Location place_url=/>
I agree that there is no use case for using helper that implements
> Of course, if you have actual use cases for these things, please explain
> them to me and maybe I'll be convinced otherwise. At the moment they both
> seem quite YAGNI.
More information about the PEAK