Craig McClanahan wrote:
>On 7/8/05, Werner Punz <[EMAIL PROTECTED]> wrote:
>
>>But one of the biggest gaps of the current JSF specs is that you do not
>>have local scopes... scopes which are bigger than a request but smaller
>>than a session. Shale has something with the dialog system, which I have
>>not checked out yet.
>>
>
>UIltimately, a standardized solution to this problem really belongs in
>the servlet spec so that the entire web tier can use it. In the mean
>time, Shale's approach works like this:
>
I agree we need a scope scope in the servlet tier, the gap is in the
servlet tier and has been carried along for years without really a
decent low level fix.
>* You have a "Status" bean that the framework uses to
> keep track of navigating through a particular dialog.
> Among other things, it knows how to do nested dialogs.
>
>* This bean has a "data" property of type Object, so the
> application can push any sort of bean it wants, to save
> and restore state for that particular dialog.
>
>* As a new dialog is entered, the current data object is
> pushed onto a stack so that the new dialog can push
> on its own data object.
>
>* When a dialog is exited, the stack is popped, making
> the data object from the previous dialog is made visible
> again, and the state for the just-completed dialog is
> released for garbage collection.
>
>>From a JSF perspective, this approach has the additional advantage
>that a value binding expression to access the state information stays
>the same ("#{status.data.foo}") no matter how deep the stack of nested
>dialogs is -- the data for the currently executing dialog is always
>the state that is visible to the expression.
>
>Craig
>
Thanks for the explanation Craig, basically what I was thinking of but
more on a backend level, because you do the dialogs on a config file level.
I am thinking currently and have been thinking about that, more along
the lines of having dialog/scope tags which basically mark an entire
scope which can be accessed, but never had time to implement it.
The base mechanism of my idea works pretty much the same, but the entire
scoping is done on the UI tier, with simple tags which the designer can
set...
Anyway some kind of dialog/scope system has to be added to the official
specs, the lower the better :-)
