[Seaside] Question about nested menu handling..
Richard E. Flower
rickf at ca-flower.com
Tue Nov 25 14:06:40 UTC 2008
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
More information about the seaside
mailing list