[Seaside] Menu building pattern?

[Avi Bryant]

On Aug 4, 2004, at 12:13 AM, C. David Shaffer wrote:

> I have been working on a generic menu component and I'm stumbling on 
> managing children.  What I'd like to do is after callback processing 
> is complete (and the component tree is finalized for the next 
> rendering pass), traverse the tree and ask each visible presenter for 
> its menu items.  The menu items themselves are components so they have 
> to appear in the menu's response to #children during the next render 
> loop iteration.

Well, there's a potential infinite recursion here - if you're really 
starting at the top of the tree, that means you're including the menu 
when searching for menu items, which means you're including its items, 
and if any of *those* components has menu items...

But assuming that's not happening, this shouldn't be a problem, at 
least not unless you're worried about efficiency.  Just have a 
#menuItems method that rebuilds the list of components on the fly, and 
use it from both #children and #renderContentOn:.  Don't worry about 
the callback processing phase, or which render loop you're in. just 
make sure that #children and #renderContentOn: are in agreement about 
what the children are at any given time.

Now, it sounds like maybe you're trying to cache these components 
between those two calls.  If so, why?  If it's for efficiency, then 
profile and make sure it's actually worth it first (I'd be surprised).  
If it's because new instances of the menu item components are created 
each time you ask for them, then you don't want components at all - use 
some other objects that respond to #renderOn:, that aren't expecting to 
have persistent state the way a component is, and don't need to be 
included in #children at all.

Avi