[Bese-devel] nav bars and place-slots oh my! [Was: different tyes of components]

[Marco Baringer]

Drew Crampsie - Software Developer <drew at tech.coop> writes:

> All it ever did was set up the place-slot automatically. I had a bunch 
> of hacks in there specific to what i was doing, but basically they just 
> generated headers, navigation lists and the like. In the end, i didn't 
> find it all that usefull as a general tool, and havn't been using it.

On Place-Slots:

place-slot allowed you to do a CALL on some component and what you'd
actually be CALL'ing was a particular slot of that component. If we
take a step back and look at what we (i) were trying to accomplish
we'll discover that this is Just Plain Wrong (TM).

Let's take UCW's example app and study it a bit: We want index.ucw to
take us to some "home page" type thingy with a brief introduction and
provide a header, a footer and a set of navigation links. 

Up until now you'd have an 'application' component and the entry-point
would (by using the GOTO macro) setup an instance of your application
component in the first frame's root-component slot. the application
component's links would create instance of various other components
and swap those in and out of it's place-slot based on the user's
navigation, it would do this by CALL'ing itself whenever the user
clicked on a link. if you look at things this way (and you shoe horn
into everything into the call/answer paradigm) then the implementation
is fine, but issues arise: 1) what if i want to have two navigation
bars controlling two different parts of the screen? 2) what happens
when one of the call'd componets answers?  3) if i'm call'ing a
component how come it doesn't get replaced by something else?

basically we're putting a square peg into a round hole and wondering
why it's so difficult. if you have one component which wraps "stuff"
around some other component, and the wrapping component doesn't
changed based on the wrapped component then you should say so, and not
pretend you're call'ing when you're not.

so here's what you'd do now: create a component class with one slot
for every nav-bar in the page. when creating these components create
the nav bar component as well and pass it all the components it will
manage. the component should render the wrapping html and then render
the nav-bar (the actual rendering of the nav bar should be done by
some method on the nav-bar component) then place the body and render
the current-component of the navbar (whatever the user selected last
or some defalut component object). when the user clicks on a link the
nav-bar component should do nothing more than (setf current-component
whatever-the-user-chose). that's it, no call'ing, no place slots,
nothing. this has the added advantage of maintainng the component
state should the user jump back and forth between items on the nav
bar. should you want a fresh component for every click that's easy to
do too.

the new container class should make doing this stuff easy. (and
provide hints on how to do it should you ant to do it on your own).

in summary:

1) CALL is an extremly cool hammer, don't forget that not
   everything's a nail.

1b) only use CALL if you plan to ANSWER

2) use container components.

3) this mail is just a very, very long way of announcing that the
   place-slot slot in standard-component-class is being removed.

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