Re: Passing a wrapper component to a page-level component
Re: Passing a wrapper component to a page-level component
- Subject: Re: Passing a wrapper component to a page-level component
- From: Andrew Lindesay <email@hidden>
- Date: Thu, 7 May 2009 19:14:21 +1200
Hello Paul;
Did you end up taking a look through the LEWOStuff page/navigation
architecture in the end? No need to use it directly, but you may
potentially get some design ideas. It sounds like some of what you
are trying I have already worked through. I keep a stack structure of
"page states" off the session (instead of using the context's info
dictionary) and these are called "navigation destinations" or "ND"-s
for short. NDs are KVC-compliant and act a bit like a dictionary to
store state in. Having said this, for sanity, I *always* access this
data through a structured component controller and *never* directly
from the ND. The ND's are also able to express the component name to
swap over in the WOSwitchComponent like you mention you are doing.
The NDs are conveniently able to be formed into a tree to provide a
data structure for menus and exist in a stack off the session which
forms the breadcrumbs for historical navigation. The architecture
does have a couple of things that one ought to watch, but it works
very well in practise.
cheers.
So I rolled my own solution. EditFooPage has a WOSwitchComponent as
its outermost element. The app-specific LAF class is passed to
EditFooPage after construction so that it knows what to substitute
for the WOSwitchComponent. Key-value pairs are stored in
context().userInfo() to simulate the bindings intended for LAF. The
keys are in a namespace specific to the app-specific LAF, which
knows to look for them and change its behaviour accordingly. Of
course, context() disappears at the end of the transaction, so if
LAF finds key-values in userInfo(), it also caches them locally for
reuse if required.
It works, but I feel dirty. Critiques welcome.
___
Andrew Lindesay
www.lindesay.co.nz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden