On 8/24/06, Sean Schofield <[EMAIL PROTECTED]> 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 #{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.
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
Craig
