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

[Marco Baringer]

Tim Lavoie <tim at fractaldragon.net> writes:

> Hi all,
>
> I've got a window component defined, where there are pieces which I
> would like to use to control other components, or the top-level
> window.
>
> It starts out basically like this:
>
> (defcomponent foo-window (template-component simple-window-component)
>   ((nav1 :component side-nav1 :accessor foo-window.nav1)
>    (body :component simple-container :accessor foo-window.body)
>    (profile :component profile :accessor ww-profile))
>
>   ........
>
> The body is the main content area, nav1 would be something like the
> typical side-bar navigation area, and profile is a user profile which
> I've changed from defaults to results from an SQL query once they've
> logged in.
>
> 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)).

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

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

-- 
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen