[Bese-devel] Getting at higher-level state in contained components

[Tim Lavoie]

On Tue, Aug 30, 2005 at 05:14:53PM +0200, Marco Baringer wrote:
> >
> > What I would like to do ideally is get a reference in one component to
> > another, without manually hard-coding the path to use the appropriate
> > number of parent links. This does work, but is fragile in the face of
> > changing page structure. This allows me already to have navigation
> > links do something to the main content area as an example, or get
> > something from the profile.
> 
> at some point you're going to be forced to tell one component about
> the other component, and this is going to require, on some level, a
> hard coded path. that said it'd be easier for the nav component if you
> informed it about the body component, instead of having the nav bar's
> code littered with calls to (body (parent self)).

Yeah, that's why I asked. I had tested out the idea with some (body
(parent self)) -type code in the TAL template for the nav component,
but wasn't thrilled with it.

> 
> (defcomponent navbar ()
>   ((nav-tree)
>    (current-node)
>    (body)))
> 
> (defmethod render-on ((res response) (navbar navbar))
>   (dolist* (node nav-tree)
>     (<ucw:a :action (switch-component node (body navbar))
>             (<:as-html (title node)))))
> 
> and then in the window's shard-initialize tell the navbar what
> component it should control:
> 
> (defmethod shard-initialize :after ((foo foo-window) slot-names &rest ignore)
>   (setf (body (navbar foo)) (body foo)))
> 
> could that work? (i'm not really sure what answer you want here (and
> there are 1e20 possibilities) so i'm just guessing).


Yes, I think that should work fine, and is certainly more direct than
what I had been thinking; rather than simply coding in the reference
as you showed here, I started playing with the idea of a method to
follow the chain of (parent self) calls until either the top is
reached, or the desired component found.

I suspect I won't be doing the sort of nesting to make this approach
really needed, so I'll try your way first.


> > Is there a nice way to define this sort of find-in-parents behaviour
> > already? It seems obvious, but I didn't find anything of the sort
> > already. I think it would work well and allow arbitrary nesting
> > without changing template code, which would be quite nice. Any
> > suggestions?
> 
> could you be a bit more precise about what you want? we already have
> the parent accessor (every component knows what component its nested
> in) but something a well done navbar component would be a good idea as
> well. of course, it'd be built on top of a well done tree-view
> component...

Heh. I'll try the simple and expedient method for the time being, but
you are right, there is room for a couple of helpful widgets.

	Thanks,	
	Tim

-- 
I've finally learned what "upward compatible" means.  It means we get to
keep all our old mistakes.
                -- Dennie van Tassel