shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: [dialog] Get rid of subdialogs
Date Thu, 24 Aug 2006 18:06:02 GMT
On 8/24/06, Sean Schofield <> wrote:
> > I agree that, if we keep the concept of subdialogs around, mechanisms
> for
> > dealing with this are important.  From the perspective of a subdialog,
> you
> > should be able to "pull" data out of the parent dialog's context
> > transparently (WebWork/XWork do this with their action context method).
> > And, we would want to provide a way for a subdialog to "push" data up
> (at
> > least) a level as well.
> What if we used dependency injection for the state object?  Instead of
> relying on this hard-coded #{} business you could just have
> a setData method that could be injected with an existing bean.  IIRC
> the current mechanism is that you provide your own data object by
> calling setData from one of your dialog states.
> I think it would be cool if you could have something like
>   <dialog name="Edit Profile" start="Setup" context="#{user}>
> where #{user} is a session-scoped bean defined in your faces-config
> file.  We could just make it a policy to clean it up after the dialog
> ends (if that's your desire.)  We could even make the cleanup optional
> and only dump the context data if the bean implements a DialogCleanup
> interface.
> I think this also solves the problem of storing states for multiple
> simultaneous dialogs that have not yet finished.

I don't see how this handles starting two instances of the same dialog at
once (say, in two different windows), unless we can design some magic
variable resolver that picks the right one somehow.

> Agreed that the need to share state is important.  But, even without,
> you'll
> > see use cases like the one in the logon dialog of the Use Cases sample
> app
> > :-), where the wizard part of "Create A New Profile" and "Edit My
> Existing
> > Profile" are nearly identical, and should not have to be configured
> twice.
> I think we need to maintain certain concepts related to the subdialog
> - I'm not suggesting we scrap it all together.  I still think we
> should be able to chain dialogs together in the manner that you are
> referring to in the use case sample app.  Perhaps we call the
> transition <chain> instead of <subdialog> to make it more clear?  To
> me, the "sub" part implies a hierarchy when we're really just
> composing one big dialog out of pieces.

Forgive my reversion to BASIC terminology :-), but "chain" seems like "GO
TO" and "subdialog" seems like "GOSUB".  Both concepts can be useful.

We also need to keep the Position stuff where you "push" a new
> position onto the "stack."  If you are going to chain dialogs like
> this you need to know where you left off once the dialog you called in
> a transition is completed.
> > Sharing the parent's context object (I'm leaning towards migrating to
> > "context" instead of "state" for this concept, because it seems more
> > consistent with various published discussions of the idea) is an
> interesting
> > idea -- but it seems like you'd run the risk of name collisions if the
> child
> > dialog happened to store something under name "foo" for its own use,
> without
> > being aware that "foo" was also in use by the parent dialog.  An
> appropriate
> > nesting technology for pulls, and some manner to deliberately push data
> for
> > pushes, should be able to deal with this, though.
> Context is probably a better term.  Putting aside what other dialog
> systems call it, we already have the notion of states in the dialog:
> action, view, etc.  We also have the state diagrams in UML which match
> up nicely to these states so I'm cool with using the context term.
> I don't anticipate too many collisions between dialogs that are
> composed of other dialogs.  Presumably the person doing the
> configuring is chaining them together for a purpose and knows what
> they're doing.  In my experience, many of the dialogs I used in a
> chain were not suitable to operate by themselves.  Take the shopping
> cart example again.  Its easy to see a dialog where each screen
> reads/writes information to a common underlying "order" object.
> > Craig
> Sean


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message