Actually, I'm not using session-scoped beans and I am taking advantage of
dialog scope. Let me explain.
The benefit of dialog state is that views have reference to the state
through #{dialog.data}. In my setup actions, I assign instance variables
(they're not session scoped) to #{dialog.data}. No matter what view is
invoked, the correct data is always referenced through #{dialog.data}, so
I'm taking advantage of dialog scope.
This is just the standard way to use dialog I thought you were
proposing something new in response to the problem of the *same* info
not being available to #{dialog.data} when inside a subdialog. I must
have misinterpreted you original suggestion.
IOW, Shale doesn't manage a state for you that lasts only during the
duration of the dialog; instead, it makes that state available to the view
via #{dialog.data} only during the duration of the dialog. How long the
state lasts is another matter.
Since most dialogs will want a state, why not inject the state instead
of having every single dialog require an action state to set one up?
I think the scope is useful, but I'm still not convinced the extra
complexity required to support easy access of ancestral data on the dialog
stack is worth the effort. It seems to me that you can easily handle
situations like this with setup actions that synthesize the right data and
make it available to the view via #{dialog.data}.
So we abandon #{dialog.data} and leave it as an "exercise for the
user" to supply their own mechanism for managing a "dialog scope"? Is
that what you're saying?
david
Sean
> > david
>
> Sean
>
