You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shale.apache.org by Sean Schofield <se...@gmail.com> on 2006/08/24 05:02:07 UTC
[dialog] Get rid of subdialogs
I'm not quite convinced that <subdialog> is very useful as
implemented. I see the usefulness in stringing existing dialogs
together but certain byproducts of subdialog are undesirable. For
instance, SHALE-153 which complains about how you can't easily access
state information between a "parent" and "child" dialog.
I've discussed this with Craig before and IIRC he doesn't agree with
me on this but I can't see how having subdialogs as "black boxes" is
very useful. Maybe there are some use cases out there but it would
seem to me that its much more common that you would want to share
state across two dialogs.
Here's a hypothetical example: Suppose you have a e-commerce site
where you sell both physical products as well as downloadable
software. You have the following "dialogs":
shopping cart
shipping
payment
download link
Each of these "dialogs" represents a series of actions and views. For
the physical goods you might want to compose a "physical goods" dialog
as follows:
shopping cart -> shipping -> payment
For the downloadable software you might want to compose a dialog that
uses the same shopping cart and payment dialogs as in the physical
goods case:
shopping cart -> payment -> download link
If you compose these using <subdialog> you immediately run into
problems. Your payment dialog has no access to any of the state
generated by the shopping cart phase of the dialog. As a developer I
don't want shopping cart and payment to be black boxes, I want them to
work seamlessly together. I also don't want to configure the shopping
cart and payment stuff twice in order to avoid this.
I think the ability to plug dialogs into one another is really cool
but in the past I have found myself doing various hacks and
workarounds to get at the state information further down the stack.
Of course we could make it optional to create a new state for the
subdialog but there are other reasons not to bother with this. I have
implemented my own prev, next, ok button scheme on top of shale
dialogs and subdialogs significantly complicate this.
Sean
Re: [dialog] Get rid of subdialogs
Posted by Craig McClanahan <cr...@apache.org>.
On 8/24/06, Sean Schofield <se...@gmail.com> 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
Re: [dialog] Get rid of subdialogs
Posted by Sean Schofield <se...@gmail.com>.
> 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
Re: [dialog] Get rid of subdialogs
Posted by Craig McClanahan <cr...@apache.org>.
On 8/23/06, Sean Schofield <se...@gmail.com> wrote:
>
> I'm not quite convinced that <subdialog> is very useful as
> implemented. I see the usefulness in stringing existing dialogs
> together but certain byproducts of subdialog are undesirable. For
> instance, SHALE-153 which complains about how you can't easily access
> state information between a "parent" and "child" dialog.
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.
I've discussed this with Craig before and IIRC he doesn't agree with
> me on this but I can't see how having subdialogs as "black boxes" is
> very useful. Maybe there are some use cases out there but it would
> seem to me that its much more common that you would want to share
> state across two dialogs.
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.
Here's a hypothetical example: Suppose you have a e-commerce site
> where you sell both physical products as well as downloadable
> software. You have the following "dialogs":
>
> shopping cart
> shipping
> payment
> download link
>
> Each of these "dialogs" represents a series of actions and views. For
> the physical goods you might want to compose a "physical goods" dialog
> as follows:
>
> shopping cart -> shipping -> payment
>
> For the downloadable software you might want to compose a dialog that
> uses the same shopping cart and payment dialogs as in the physical
> goods case:
>
> shopping cart -> payment -> download link
>
> If you compose these using <subdialog> you immediately run into
> problems. Your payment dialog has no access to any of the state
> generated by the shopping cart phase of the dialog. As a developer I
> don't want shopping cart and payment to be black boxes, I want them to
> work seamlessly together. I also don't want to configure the shopping
> cart and payment stuff twice in order to avoid this.
>
> I think the ability to plug dialogs into one another is really cool
> but in the past I have found myself doing various hacks and
> workarounds to get at the state information further down the stack.
>
> Of course we could make it optional to create a new state for the
> subdialog but there are other reasons not to bother with this. I have
> implemented my own prev, next, ok button scheme on top of shale
> dialogs and subdialogs significantly complicate this.
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.
Sean
>
Craig
Re: [dialog] Get rid of subdialogs
Posted by Rahul Akolkar <ra...@gmail.com>.
On 8/24/06, Craig McClanahan <cr...@apache.org> wrote:
> On 8/24/06, David Geary <sa...@gmail.com> wrote:
> >
> > 2006/8/24, Sean Schofield <se...@gmail.com>:
> >
> > > > 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?
> >
> >
> > I'm not sure. I am somewhat uncomfortable adding new functionality when
> > there's already a valid mechanism in place, especially when such a change
> > requires considerable design changes. And in this case, we've got our
> > hands
> > full of things that must be fixed for a viable dialog implementation
> > that's
> > usable in production, such as supporting simultaneous dialogs. I'd rather
> > concentrate on those things first, hoping that the smaller issues, such as
> > this, will fall out in the design, if appropriate.
>
>
> I'm going to start my personal quest here by reviewing the context storage
> and instance disambiguation strategies of some of the "prior art" links.
> Because I need to look at it anyway, I'm going to start with Seam, and then
> post a summary onto the wiki page. Anyone else fancy taking a look at how
> others do this sort of thing, and reporting back?
>
<snip/>
Some relevant bits on Commons SCXML:
* Context storage -- Hierarchial contexts, each <state> has its own
context / datamodel / namespace. v0.5 works like blocks in a
procedural language, you can "see" variables in your ancestor states.
Datamodels can be declared declaratively, or one may procedurally
inject data into the documents root context. There will probably be
two enhancements soon:
1. Latest Working Draft requires ability to refer to data in
non-ancestor context using the stateID.variable notation.
2. Flat context option: There was a user request for that, can
probably be provided with a switch that collapses everything into one
document context.
* Multiple instances of the same state machine -- Commons SCXML
clearly differentiates between the abstract model of a state machine
and a concrete executing instance thereof. Care has been taken to make
sure the model itself is stateless, and hence can be reused by as many
executor instances as possible (in other words -- parse once, execute
as many times).
* Disambiguation strategies -- A suitable disambiguation strategy
should be employed by the "environment" in which Commons SCXML is
used. The strategy could simply be some key-based instance
identification.
There was some interest on the commons lists for using SCXML in SWF,
and I've been meaning to look at SWF, so I can volunteer for that as
well.
-Rahul
> Craig
>
> david
> >
> > >
> > > Sean
Re: [dialog] Get rid of subdialogs
Posted by Craig McClanahan <cr...@apache.org>.
On 8/24/06, David Geary <sa...@gmail.com> wrote:
>
> 2006/8/24, Sean Schofield <se...@gmail.com>:
>
> > > 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?
>
>
> I'm not sure. I am somewhat uncomfortable adding new functionality when
> there's already a valid mechanism in place, especially when such a change
> requires considerable design changes. And in this case, we've got our
> hands
> full of things that must be fixed for a viable dialog implementation
> that's
> usable in production, such as supporting simultaneous dialogs. I'd rather
> concentrate on those things first, hoping that the smaller issues, such as
> this, will fall out in the design, if appropriate.
I'm going to start my personal quest here by reviewing the context storage
and instance disambiguation strategies of some of the "prior art" links.
Because I need to look at it anyway, I'm going to start with Seam, and then
post a summary onto the wiki page. Anyone else fancy taking a look at how
others do this sort of thing, and reporting back?
Craig
david
>
> > david
> >
> > Sean
> > > > > david
> > > >
> > > > Sean
> > > >
> > >
> > >
> >
>
>
Re: [dialog] Get rid of subdialogs
Posted by Rahul Akolkar <ra...@gmail.com>.
On 8/24/06, Craig McClanahan <cr...@apache.org> wrote:
<snip/>
>
> In my ideal world scenario, we'll be able to rebuild things on the inside,
> with minimal-to-none impact on how an application developer uses it.
> However, I'm not convinced that goal is actually achievable, if we're going
> to have a dialog infrastructure that meets the functional requirements we've
> outlined. Even if it is not totally possible, however, I'm a fan of the way
> dialogs are currently configured, and would like to keep as much of that as
> possible, even if we did something radical like used Commons SCXML as the
> execution engine under the covers (betcha Rahul just perked up :-) -- things
> like that should be on the table at this point, as far as I can see.
>
<snap/>
Yes, that draws my attention, not (only) because I'm a Commons SCXML
developer, but because I believe this is the right way moving forward
for Shale dialogs (I'll articulate in detail in another thread). No
doubt that backwards compatibility should be maintained as far as
possible. To use Commons SCXML to also support the current dialog
notation, three approaches come quickly to mind:
1) Run a XML tranform under the hood (possibly tricky, since
dialog-configs can contain multiple dialogs).
2) Write a specific digester that can map dialog-config.xml to the
Commons SCXML model package [1].
3) Do a Java object mapping (basically walk the object graph) of the
Shale object model to a Commons SCXML one.
Any other ideas? Any preferences?
-Rahul
(long, possibly fragmented URL below)
[1] http://jakarta.apache.org/commons/scxml/apidocs/org/apache/commons/scxml/model/package-summary.html
>
>
> Craig
>
>
Re: [dialog] Get rid of subdialogs
Posted by Craig McClanahan <cr...@apache.org>.
On 8/24/06, Sean Schofield <se...@gmail.com> wrote:
>
> > I'm not sure. I am somewhat uncomfortable adding new functionality when
> > there's already a valid mechanism in place, especially when such a
> change
> > requires considerable design changes. And in this case, we've got our
> hands
> > full of things that must be fixed for a viable dialog implementation
> that's
> > usable in production, such as supporting simultaneous dialogs. I'd
> rather
> > concentrate on those things first, hoping that the smaller issues, such
> as
> > this, will fall out in the design, if appropriate.
>
> It sounds like Craig is proposing a rapid redesign of the dialogs over
> the next few weeks. If that's the case then IMO everything should be
> on the table. Now that we've seen the limitations of shale dialog
> "out in the wild" its time to correct things now before its too late.
> I would agree that lots of the existing stuff is viable but it
> doesn't hurt to think out of the box before we commit ourselves to
> what we have.
In my ideal world scenario, we'll be able to rebuild things on the inside,
with minimal-to-none impact on how an application developer uses it.
However, I'm not convinced that goal is actually achievable, if we're going
to have a dialog infrastructure that meets the functional requirements we've
outlined. Even if it is not totally possible, however, I'm a fan of the way
dialogs are currently configured, and would like to keep as much of that as
possible, even if we did something radical like used Commons SCXML as the
execution engine under the covers (betcha Rahul just perked up :-) -- things
like that should be on the table at this point, as far as I can see.
> david
>
> Sean
>
Craig
Re: [dialog] Get rid of subdialogs
Posted by Sean Schofield <se...@gmail.com>.
> I'm not sure. I am somewhat uncomfortable adding new functionality when
> there's already a valid mechanism in place, especially when such a change
> requires considerable design changes. And in this case, we've got our hands
> full of things that must be fixed for a viable dialog implementation that's
> usable in production, such as supporting simultaneous dialogs. I'd rather
> concentrate on those things first, hoping that the smaller issues, such as
> this, will fall out in the design, if appropriate.
It sounds like Craig is proposing a rapid redesign of the dialogs over
the next few weeks. If that's the case then IMO everything should be
on the table. Now that we've seen the limitations of shale dialog
"out in the wild" its time to correct things now before its too late.
I would agree that lots of the existing stuff is viable but it
doesn't hurt to think out of the box before we commit ourselves to
what we have.
> david
Sean
Re: [dialog] Get rid of subdialogs
Posted by David Geary <sa...@gmail.com>.
2006/8/24, Sean Schofield <se...@gmail.com>:
> > 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?
I'm not sure. I am somewhat uncomfortable adding new functionality when
there's already a valid mechanism in place, especially when such a change
requires considerable design changes. And in this case, we've got our hands
full of things that must be fixed for a viable dialog implementation that's
usable in production, such as supporting simultaneous dialogs. I'd rather
concentrate on those things first, hoping that the smaller issues, such as
this, will fall out in the design, if appropriate.
david
> david
>
> Sean
> > > > david
> > >
> > > Sean
> > >
> >
> >
>
Re: [dialog] Get rid of subdialogs
Posted by Sean Schofield <se...@gmail.com>.
> 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
> >
>
>
Re: [dialog] Get rid of subdialogs
Posted by David Geary <sa...@gmail.com>.
2006/8/24, Sean Schofield <se...@gmail.com>:
>
> > OTOH, I don't think this necessarily warrants a change to subdialog
> design
> > because dialogs have the mechanisms to deal with this. The starting
> state
> > for a subdialog can be an action state, and that method can set up the
> > dialog.data reference before entering the first view state.
>
> Its true you can always maintain dialog data outside of the dialog
> mechanism by setting up your own session scoped bean in the starting
> action state. If you do this, you bypass one of the supposed benefits
> of dialog which is that it manages a state for you that lasts only
> during the duration of the dialog.
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.
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.
To clarify things, here's some code. I've got a Bill Pay dialog with a Wire
Transfer subdialog.
In payment.xml, which defines the Bill Pay dialog:
<dialogs>
<dialog name="Payment" start="Setup">
<!-- This transition is applicable to
all states in this dialog -->
<transition outcome="cancel" target="Exit"/>
<action name="Setup"
method="#{dialogLauncher.setupPaymentDialog}">
<transition outcome="success"
target="Payee Information"/>
</action>
<!-- Payee Information -->
<view name="Payee Information"
viewId="/billpay/payment/wizard.jsp">
<transition outcome="next"
target="Payment Method"/>
</view>
...
</dialog>
...
</dialogs>
Shale calls DialogLauncher.setupPaymentDialog() when you enter the dialog
and then transitions immediately to Payee Information.
Similarly in wireTransfer.xml:
<dialogs>
<dialog name="Wire Transfer Dialog"
start="Setup">
<action name="Setup"
method="#{dialogLauncher.setupWireTransferDialog}">
<transition outcome="success"
target="Bank Information"/>
</action>
<view name="Bank Information"
viewId="/billpay/payment/wireTransfer/wizard.jsp">
<transition outcome="next"
target="Account Information"/>
<transition outcome="cancel"
target="Exit"/>
</view>
...
</dialog>
</dialogs>
Shale calls DialogLauncher.setupWireTransferDialog() when you enter the
dialog and then transitions immediately to Bank Information.
So I have two methods: setupPaymentDialog() and setupWireTransferDialog() in
DialogLauncher. Those methods assign the appropriate objects to dialog.data:
package com.corejsf.dialog;
import org.apache.shale.view.AbstractFacesBean;
import com.corejsf.dialog.data.BillpayData;
import com.corejsf.dialog.data.WireTransferData;
public class DialogLauncher extends AbstractFacesBean {
// billpayData contains all of the properties for the
// payment dialog. It also contains a couple of JSF
// action methods used for navigation, and an
// embedded wire transfer data object
private BillpayData billpayData = null;
// Called just afer entering the payment dialog
public String setupPaymentDialog() {
// Create billpay data and nested wire transfer data
billpayData = new BillpayData();
billpayData.setTransfer(new WireTransferData());
// Set dialog data with the handy setValue method
// from org.apache.shale.view.AbstractFacesBean
setValue("#{dialog.data}", billpayData);
// This outcome takes us to the payment dialog's
// first view
return "success";
}
// Called just afer entering the wire transfer dialog
public String setupWireTransferDialog() {
// Set the dialog's data to the wire transfer object
// stored in the bill pay data
setValue("#{dialog.data}", billpayData.getTransfer());
// This outcome takes us to the wire transfer dialog's
// first view
return "success";
}
}
I'm not 100% convinced such a dialog scope is that useful, but if you
> are going to provide such a mechansim, you need to be able to *easily*
> access it through the duration of the dialog and all subdialogs in the
> chain. Right now the data is "popped" off the "stack" each time you
> enter a subdialog so you can't use #{dialog.data} in your JSF to refer
> to stuff from a previous page.
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}.
david
> > david
>
> Sean
>
Re: [dialog] Get rid of subdialogs
Posted by Sean Schofield <se...@gmail.com>.
> OTOH, I don't think this necessarily warrants a change to subdialog design
> because dialogs have the mechanisms to deal with this. The starting state
> for a subdialog can be an action state, and that method can set up the
> dialog.data reference before entering the first view state.
Its true you can always maintain dialog data outside of the dialog
mechanism by setting up your own session scoped bean in the starting
action state. If you do this, you bypass one of the supposed benefits
of dialog which is that it manages a state for you that lasts only
during the duration of the dialog.
I'm not 100% convinced such a dialog scope is that useful, but if you
are going to provide such a mechansim, you need to be able to *easily*
access it through the duration of the dialog and all subdialogs in the
chain. Right now the data is "popped" off the "stack" each time you
enter a subdialog so you can't use #{dialog.data} in your JSF to refer
to stuff from a previous page.
> david
Sean
Re: [dialog] Get rid of subdialogs
Posted by David Geary <sa...@gmail.com>.
I agree that it's often useful for a subdialog to access data contained in a
parent dialog, or as SHALE-153 points out, vice-versa. Use cases where
subdialogs are entirely self-contained would certainly seem to be in the
minority.
OTOH, I don't think this necessarily warrants a change to subdialog design
because dialogs have the mechanisms to deal with this. The starting state
for a subdialog can be an action state, and that method can set up the
dialog.data reference before entering the first view state.
What the dialog.data reference points to, and whether that object has access
to the data object of the enclosing dialog (or vice-versa) seems like more
of OO design issue that's separate from the dialogs themselves.
david
2006/8/23, Sean Schofield <se...@gmail.com>:
>
> I'm not quite convinced that <subdialog> is very useful as
> implemented. I see the usefulness in stringing existing dialogs
> together but certain byproducts of subdialog are undesirable. For
> instance, SHALE-153 which complains about how you can't easily access
> state information between a "parent" and "child" dialog.
>
> I've discussed this with Craig before and IIRC he doesn't agree with
> me on this but I can't see how having subdialogs as "black boxes" is
> very useful. Maybe there are some use cases out there but it would
> seem to me that its much more common that you would want to share
> state across two dialogs.
>
> Here's a hypothetical example: Suppose you have a e-commerce site
> where you sell both physical products as well as downloadable
> software. You have the following "dialogs":
>
> shopping cart
> shipping
> payment
> download link
>
> Each of these "dialogs" represents a series of actions and views. For
> the physical goods you might want to compose a "physical goods" dialog
> as follows:
>
> shopping cart -> shipping -> payment
>
> For the downloadable software you might want to compose a dialog that
> uses the same shopping cart and payment dialogs as in the physical
> goods case:
>
> shopping cart -> payment -> download link
>
> If you compose these using <subdialog> you immediately run into
> problems. Your payment dialog has no access to any of the state
> generated by the shopping cart phase of the dialog. As a developer I
> don't want shopping cart and payment to be black boxes, I want them to
> work seamlessly together. I also don't want to configure the shopping
> cart and payment stuff twice in order to avoid this.
>
> I think the ability to plug dialogs into one another is really cool
> but in the past I have found myself doing various hacks and
> workarounds to get at the state information further down the stack.
>
> Of course we could make it optional to create a new state for the
> subdialog but there are other reasons not to bother with this. I have
> implemented my own prev, next, ok button scheme on top of shale
> dialogs and subdialogs significantly complicate this.
>
> Sean
>