shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Schofield" <sean.schofi...@gmail.com>
Subject Re: [dialog] Get rid of subdialogs
Date Thu, 24 Aug 2006 17:44:14 GMT
> 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
> >
>
>

Mime
View raw message