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 16:16:23 GMT
> 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 #{dialog.data} 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.

> 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.

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

Mime
View raw message