[Seaside] Question about nested menu handling..

[Richard E. Flower]

Good morning...

I've got an existing app that I've been working on in my 'off' time  
and one area is starting to show the
ugliness of the design and I was hoping I could rewrite that over the  
coming days if I could find a
better alternative over what I've currently got..

In general this application has the concept of a 'currentComponent' at  
the top-level in which the
#renderContentOn: method can ask that currentComponent to render  
itself.  In the list of possible
menu options, when the user presses a new menu item to view, it  
changes that currentComponent
to point to the new one and all is good.

Now, the problem comes in for admin users where you need to handle  
nested menu and still
have things flow properly..  Take the idea of a admin page -- this  
component will be set into the
above mentioned currentComponent but this component can have 2 level  
deep menus below it
such as the following (I'm only showing one relevant path for this  
discussion and will use PDL instead
of actual ST code) :

currentComponent>>renderContentOn:
	[ menu of links follows]
		[ 1. user administration ]
		[ 2. other admin menu #1]
		[ 3. other admin menu #2]
		[ etc. ]

#renderViewOfUserAdminOn: html
	[menu of links follows]
		[1. add user]
		[2. delete user]
		[3. edit user]
		[4. etc]


Currently, once the user select #1 above (user admin), then I  move to  
a 'view' model where that
one component has the concept of a view of itself and can call one of  
N 'renderViewOfXXXOn' methods.
The messy part comes in when it's time to return back to the above  
mentioned component... Ultimately,
I'd like the current rendering object to return to the parent  
component and only go up 1 level at a time
when its thru rendering the bottom level 'edit/delete/add' component  
but the current model's object
hierarchy gets messy due to the above mentioned 'view'  config (some  
times I can't set the currentView
since it's no longer in the object hierarchy -- I guess I might be  
able to shove it in the session class... )
At this point I figure I've got a few possible choices to avoid these  
issues and clean things up :

1) Flatten the above currentComponent>renderContentOn style so there  
are no nested menus
	--> makes for one really big menu in my case .. not desirable
2) Ditch the 'view' concept and split out each 'view' into its own  
standalone component thus allowing
     each to be registered as the 'currentComponent'
3) ???

I'm sure many of you have already gone through growing/detailing  
issues like this and mine is just
biting me in the rear due to an early design decision and I thought  
I'd ping the collective wisdom of
the list to find the best means..  I guess I was hoping I didn't have  
to go to #2 above since I've got
potentially 20-25 of these sub-menus which will make for quite a few  
objects.. But, if it works I guess
that's all that matters!  Many thanks in advance!

-- Rick