You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shale.apache.org by Paul Spencer <pa...@apache.org> on 2006/08/25 23:21:25 UTC
[dialog] How to use a common view with different dialog managed beans?
An advantage with the current dialog.data bean is that it allows a the
use of a common view when the underlying data objects are different. How
would this be done with dialog managed beans?
As an example the AbstractPayment class has a CreditCard and a Check
implementation. Both the "Pay By Check" and "Pay by CreditCard" share a
common view that collects the billing address information. In the
current implementation, that view uses #{dialog.data.billingZipCode} to
pass the billing zip code regardless of the actual class. With dialog
managed beans their will be a check and creditCard bean so how would the
billing zip code be referenced in the common view? So unless their is a
way to alias the beans in the dialog configuration, the billing address
view can not be shared.
Dialog configuration show the common view getBillingAddress.
<dialog name="Pay By CreditCard" start="getBillingAddress">
<view name="getBillingAddress" viewId="/getBillingAddress.jsp">
<transition outcome="next" target="getCreditCardNumber"/>
</view>
<view name="getCreditCardNumber viewId="/getCreditCardNumber.jsp">
<transition outcome="next" target="processPayment"/>
</view>
<action name="processPayment" method="#{creditCard.processPayment}">
<transition outcome="success" target="paymentAccepted"/>
<transition outcome="rejected" target="paymentRejected"/>
</action>
<end name="paymentAccepted" view="/paymentAccepted.jsp"/>
<end name="paymentRejected" view="/paymentRejected.jsp"/>
</dialog>
<dialog name="Pay By Check" start="getBillingAddress">
<view name="getBillingAddress" viewId="/getBillingAddress.jsp">
<transition outcome="next" target="getAccountNumber"/>
</view>
<view name="getAccountNumber viewId="/getCheckingAccountNumber.jsp">
<transition outcome="next" target="processPayment"/>
</view>
<action name="processPayment" method="#{check.processPayment}">
<transition outcome="success" target="paymentAccepted"/>
<transition outcome="rejected" target="paymentRejected"/>
</action>
<end name="paymentAccepted" view="/paymentAccepted.jsp"/>
<end name="paymentRejected" view="/paymentRejected.jsp"/>
</dialog>
Paul Spencer
Re: [dialog] How to use a common view with different dialog managed
beans?
Posted by Paul Spencer <pa...@apache.org>.
David Geary wrote:
> That's an interesting proposal. IIUC, this is kind of like Tomahawk's
> aliasBean, but for Shale dialogs. You could achieve the same effect by
> wrapping each of your view state jsp's with <t:aliasBean>. Right?
>
I suspect if you <t:aliasBean> a request managed bean will work for each
request in the dialog, but the content will be lost since each request
brings a new instance of the managed bean.
<snip>
Paul Spencer
Re: [dialog] How to use a common view with different dialog managed beans?
Posted by David Geary <sa...@gmail.com>.
That's an interesting proposal. IIUC, this is kind of like Tomahawk's
aliasBean, but for Shale dialogs. You could achieve the same effect by
wrapping each of your view state jsp's with <t:aliasBean>. Right?
If we were to incorporate something like this, I think we should:
1. Allow multiple <alias>es.
2. Like transitions, have global and state-scoped aliases. Aliases declared
within a state would be scoped to that state. Aliases declared outside any
view would be global to all views in the dialog.
I'm a big fan of <t:aliasBean>. Reusing code for multiple managed beans is
very nice.
david
2006/8/25, Paul Spencer <pa...@apache.org>:
>
> Sean,
> 1) I am neither for nor against scrapping #{dialog.data}.
>
> 2) I am advocating a way of mapping an existing, or new managed bean, to
> a dialog managed bean as a part of the dialog configuration.
>
> As an example the following would create a dialog managed bean
> named paymentBean that is an alias for the creditCard managed bean.
> This allows the common view, /getBillingAddress.jsp, to use
> #{paymentBean} which is really #{creditCard} or #{check} depending
> on which dialog is being executed.
>
>
> <dialog name="Pay By CreditCard" start="getBillingAddress">
> <alias="paymentBean" value="#{creditCard}"
> <view name="getBillingAddress" viewId="/getBillingAddress.jsp">
> <transition outcome="next" target="getCreditCardNumber"/>
> </view>
> <view name="getCreditCardNumber viewId="/getCreditCardNumber.jsp">
> <transition outcome="next" target="processPayment"/>
> </view>
> <action name="processPayment" method="#{creditCard.processPayment
> }">
> <transition outcome="success" target="paymentAccepted"/>
> <transition outcome="rejected" target="paymentRejected"/>
> </action>
> <end name="paymentAccepted" view="/paymentAccepted.jsp"/>
> <end name="paymentRejected" view="/paymentRejected.jsp"/>
> </dialog>
>
>
> Paul Spencer
>
>
> Sean Schofield wrote:
>
> > I think Paul was commenting on an earlier idea that I had about
> > scrapping #{dialog.data} in favor of a managed bean type solution. If
> > I'm reading his message correctly he raises some good points. I think
> > we're past that idea now though in favor of keeping #{dialog.data} but
> > no longer blowing away the context when entering a subdialog.
> >
> > Sean
> >
> >
> >
> > On 8/25/06, Paul Spencer <pa...@apache.org> wrote:
> >
> >> Rahul,
> >> This was not a "how to do I do this" question. It was in reference to
> >> the current Dialog Manager design effort.
> >>
> >> Paul Spencer
> >>
> >>
> >> Rahul Akolkar wrote:
> >> > On 8/25/06, Craig McClanahan <cr...@apache.org> wrote:
> >> >
> >> >> On 8/25/06, Paul Spencer <pa...@apache.org> wrote:
> >> >> >
> >> >> > An advantage with the current dialog.data bean is that it allows
> >> a the
> >> >> > use of a common view when the underlying data objects are
> different.
> >> >> How
> >> >> > would this be done with dialog managed beans?
> >> >> >
> >> >> >
> >> >> > As an example the AbstractPayment class has a CreditCard and a
> Check
> >> >> > implementation. Both the "Pay By Check" and "Pay by CreditCard"
> >> >> share a
> >> >> > common view that collects the billing address information. In the
> >> >> > current implementation, that view uses
> >> #{dialog.data.billingZipCode} to
> >> >> > pass the billing zip code regardless of the actual class. With
> >> dialog
> >> >> > managed beans their will be a check and creditCard bean so how
> would
> >> >> the
> >> >> > billing zip code be referenced in the common view? So unless
> their
> >> >> is a
> >> >> > way to alias the beans in the dialog configuration, the billing
> >> address
> >> >> > view can not be shared.
> >> >>
> >> >>
> >> >> You are limited to a single instance of #{dialog.data}, but that
> bean
> >> >> itself
> >> >> can have properties that are, in fact , beans ... and you can nest
> as
> >> >> deeply
> >> >> as you like. So, your Payment class (the one you use as the data
> bean
> >> >> for
> >> >> one of the processes could have a property of type AddressBean, and
> >> you
> >> >> could therefore have binding expressions like
> >> >> "#{dialog.data.address.zipCode}"
> >> >> to talk to it. The only collaboration that would be needed here is
> >> >> that all
> >> >> of the 'outer" data beans that used an AddressBean would need to
> >> store it
> >> >> under the same property name. You don't have to worry if the type
> >> of the
> >> >> "data" bean is different, because the EL machinery takes care of all
> >> >> of that
> >> >> for you.
> >> >>
> >> > <snip/>
> >> >
> >> > And IIU your class diagram correctly, having the zip in the
> >> > AbstractPayment automatically takes care of this. All you would then
> >> > need to do is populate #{dialog.data} with either the CreditCard or
> >> > the Check bean via the "setup" action state in the corresponding
> >> > dialog.
> >> >
> >> > -Rahul
> >> >
> >> >
> >> >> Paul Spencer
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> Craig
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>
Re: [dialog] How to use a common view with different dialog managed
beans?
Posted by Paul Spencer <pa...@apache.org>.
Sean,
1) I am neither for nor against scrapping #{dialog.data}.
2) I am advocating a way of mapping an existing, or new managed bean, to
a dialog managed bean as a part of the dialog configuration.
As an example the following would create a dialog managed bean
named paymentBean that is an alias for the creditCard managed bean.
This allows the common view, /getBillingAddress.jsp, to use
#{paymentBean} which is really #{creditCard} or #{check} depending
on which dialog is being executed.
<dialog name="Pay By CreditCard" start="getBillingAddress">
<alias="paymentBean" value="#{creditCard}"
<view name="getBillingAddress" viewId="/getBillingAddress.jsp">
<transition outcome="next" target="getCreditCardNumber"/>
</view>
<view name="getCreditCardNumber viewId="/getCreditCardNumber.jsp">
<transition outcome="next" target="processPayment"/>
</view>
<action name="processPayment" method="#{creditCard.processPayment}">
<transition outcome="success" target="paymentAccepted"/>
<transition outcome="rejected" target="paymentRejected"/>
</action>
<end name="paymentAccepted" view="/paymentAccepted.jsp"/>
<end name="paymentRejected" view="/paymentRejected.jsp"/>
</dialog>
Paul Spencer
Sean Schofield wrote:
> I think Paul was commenting on an earlier idea that I had about
> scrapping #{dialog.data} in favor of a managed bean type solution. If
> I'm reading his message correctly he raises some good points. I think
> we're past that idea now though in favor of keeping #{dialog.data} but
> no longer blowing away the context when entering a subdialog.
>
> Sean
>
>
>
> On 8/25/06, Paul Spencer <pa...@apache.org> wrote:
>
>> Rahul,
>> This was not a "how to do I do this" question. It was in reference to
>> the current Dialog Manager design effort.
>>
>> Paul Spencer
>>
>>
>> Rahul Akolkar wrote:
>> > On 8/25/06, Craig McClanahan <cr...@apache.org> wrote:
>> >
>> >> On 8/25/06, Paul Spencer <pa...@apache.org> wrote:
>> >> >
>> >> > An advantage with the current dialog.data bean is that it allows
>> a the
>> >> > use of a common view when the underlying data objects are different.
>> >> How
>> >> > would this be done with dialog managed beans?
>> >> >
>> >> >
>> >> > As an example the AbstractPayment class has a CreditCard and a Check
>> >> > implementation. Both the "Pay By Check" and "Pay by CreditCard"
>> >> share a
>> >> > common view that collects the billing address information. In the
>> >> > current implementation, that view uses
>> #{dialog.data.billingZipCode} to
>> >> > pass the billing zip code regardless of the actual class. With
>> dialog
>> >> > managed beans their will be a check and creditCard bean so how would
>> >> the
>> >> > billing zip code be referenced in the common view? So unless their
>> >> is a
>> >> > way to alias the beans in the dialog configuration, the billing
>> address
>> >> > view can not be shared.
>> >>
>> >>
>> >> You are limited to a single instance of #{dialog.data}, but that bean
>> >> itself
>> >> can have properties that are, in fact , beans ... and you can nest as
>> >> deeply
>> >> as you like. So, your Payment class (the one you use as the data bean
>> >> for
>> >> one of the processes could have a property of type AddressBean, and
>> you
>> >> could therefore have binding expressions like
>> >> "#{dialog.data.address.zipCode}"
>> >> to talk to it. The only collaboration that would be needed here is
>> >> that all
>> >> of the 'outer" data beans that used an AddressBean would need to
>> store it
>> >> under the same property name. You don't have to worry if the type
>> of the
>> >> "data" bean is different, because the EL machinery takes care of all
>> >> of that
>> >> for you.
>> >>
>> > <snip/>
>> >
>> > And IIU your class diagram correctly, having the zip in the
>> > AbstractPayment automatically takes care of this. All you would then
>> > need to do is populate #{dialog.data} with either the CreditCard or
>> > the Check bean via the "setup" action state in the corresponding
>> > dialog.
>> >
>> > -Rahul
>> >
>> >
>> >> Paul Spencer
>> >> >
>> >>
>> >>
>> >>
>> >> Craig
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Re: [dialog] How to use a common view with different dialog managed beans?
Posted by Sean Schofield <se...@gmail.com>.
I think Paul was commenting on an earlier idea that I had about
scrapping #{dialog.data} in favor of a managed bean type solution. If
I'm reading his message correctly he raises some good points. I think
we're past that idea now though in favor of keeping #{dialog.data} but
no longer blowing away the context when entering a subdialog.
Sean
On 8/25/06, Paul Spencer <pa...@apache.org> wrote:
> Rahul,
> This was not a "how to do I do this" question. It was in reference to
> the current Dialog Manager design effort.
>
> Paul Spencer
>
>
> Rahul Akolkar wrote:
> > On 8/25/06, Craig McClanahan <cr...@apache.org> wrote:
> >
> >> On 8/25/06, Paul Spencer <pa...@apache.org> wrote:
> >> >
> >> > An advantage with the current dialog.data bean is that it allows a the
> >> > use of a common view when the underlying data objects are different.
> >> How
> >> > would this be done with dialog managed beans?
> >> >
> >> >
> >> > As an example the AbstractPayment class has a CreditCard and a Check
> >> > implementation. Both the "Pay By Check" and "Pay by CreditCard"
> >> share a
> >> > common view that collects the billing address information. In the
> >> > current implementation, that view uses #{dialog.data.billingZipCode} to
> >> > pass the billing zip code regardless of the actual class. With dialog
> >> > managed beans their will be a check and creditCard bean so how would
> >> the
> >> > billing zip code be referenced in the common view? So unless their
> >> is a
> >> > way to alias the beans in the dialog configuration, the billing address
> >> > view can not be shared.
> >>
> >>
> >> You are limited to a single instance of #{dialog.data}, but that bean
> >> itself
> >> can have properties that are, in fact , beans ... and you can nest as
> >> deeply
> >> as you like. So, your Payment class (the one you use as the data bean
> >> for
> >> one of the processes could have a property of type AddressBean, and you
> >> could therefore have binding expressions like
> >> "#{dialog.data.address.zipCode}"
> >> to talk to it. The only collaboration that would be needed here is
> >> that all
> >> of the 'outer" data beans that used an AddressBean would need to store it
> >> under the same property name. You don't have to worry if the type of the
> >> "data" bean is different, because the EL machinery takes care of all
> >> of that
> >> for you.
> >>
> > <snip/>
> >
> > And IIU your class diagram correctly, having the zip in the
> > AbstractPayment automatically takes care of this. All you would then
> > need to do is populate #{dialog.data} with either the CreditCard or
> > the Check bean via the "setup" action state in the corresponding
> > dialog.
> >
> > -Rahul
> >
> >
> >> Paul Spencer
> >> >
> >>
> >>
> >>
> >> Craig
> >>
> >>
> >
> >
>
>
Re: [dialog] How to use a common view with different dialog managed
beans?
Posted by Paul Spencer <pa...@apache.org>.
Rahul,
This was not a "how to do I do this" question. It was in reference to
the current Dialog Manager design effort.
Paul Spencer
Rahul Akolkar wrote:
> On 8/25/06, Craig McClanahan <cr...@apache.org> wrote:
>
>> On 8/25/06, Paul Spencer <pa...@apache.org> wrote:
>> >
>> > An advantage with the current dialog.data bean is that it allows a the
>> > use of a common view when the underlying data objects are different.
>> How
>> > would this be done with dialog managed beans?
>> >
>> >
>> > As an example the AbstractPayment class has a CreditCard and a Check
>> > implementation. Both the "Pay By Check" and "Pay by CreditCard"
>> share a
>> > common view that collects the billing address information. In the
>> > current implementation, that view uses #{dialog.data.billingZipCode} to
>> > pass the billing zip code regardless of the actual class. With dialog
>> > managed beans their will be a check and creditCard bean so how would
>> the
>> > billing zip code be referenced in the common view? So unless their
>> is a
>> > way to alias the beans in the dialog configuration, the billing address
>> > view can not be shared.
>>
>>
>> You are limited to a single instance of #{dialog.data}, but that bean
>> itself
>> can have properties that are, in fact , beans ... and you can nest as
>> deeply
>> as you like. So, your Payment class (the one you use as the data bean
>> for
>> one of the processes could have a property of type AddressBean, and you
>> could therefore have binding expressions like
>> "#{dialog.data.address.zipCode}"
>> to talk to it. The only collaboration that would be needed here is
>> that all
>> of the 'outer" data beans that used an AddressBean would need to store it
>> under the same property name. You don't have to worry if the type of the
>> "data" bean is different, because the EL machinery takes care of all
>> of that
>> for you.
>>
> <snip/>
>
> And IIU your class diagram correctly, having the zip in the
> AbstractPayment automatically takes care of this. All you would then
> need to do is populate #{dialog.data} with either the CreditCard or
> the Check bean via the "setup" action state in the corresponding
> dialog.
>
> -Rahul
>
>
>> Paul Spencer
>> >
>>
>>
>>
>> Craig
>>
>>
>
>
Re: [dialog] How to use a common view with different dialog managed beans?
Posted by Rahul Akolkar <ra...@gmail.com>.
On 8/25/06, Craig McClanahan <cr...@apache.org> wrote:
> On 8/25/06, Paul Spencer <pa...@apache.org> wrote:
> >
> > An advantage with the current dialog.data bean is that it allows a the
> > use of a common view when the underlying data objects are different. How
> > would this be done with dialog managed beans?
> >
> >
> > As an example the AbstractPayment class has a CreditCard and a Check
> > implementation. Both the "Pay By Check" and "Pay by CreditCard" share a
> > common view that collects the billing address information. In the
> > current implementation, that view uses #{dialog.data.billingZipCode} to
> > pass the billing zip code regardless of the actual class. With dialog
> > managed beans their will be a check and creditCard bean so how would the
> > billing zip code be referenced in the common view? So unless their is a
> > way to alias the beans in the dialog configuration, the billing address
> > view can not be shared.
>
>
> You are limited to a single instance of #{dialog.data}, but that bean itself
> can have properties that are, in fact , beans ... and you can nest as deeply
> as you like. So, your Payment class (the one you use as the data bean for
> one of the processes could have a property of type AddressBean, and you
> could therefore have binding expressions like "#{dialog.data.address.zipCode}"
> to talk to it. The only collaboration that would be needed here is that all
> of the 'outer" data beans that used an AddressBean would need to store it
> under the same property name. You don't have to worry if the type of the
> "data" bean is different, because the EL machinery takes care of all of that
> for you.
>
<snip/>
And IIU your class diagram correctly, having the zip in the
AbstractPayment automatically takes care of this. All you would then
need to do is populate #{dialog.data} with either the CreditCard or
the Check bean via the "setup" action state in the corresponding
dialog.
-Rahul
> Paul Spencer
> >
>
>
>
> Craig
>
>
Re: [dialog] How to use a common view with different dialog managed beans?
Posted by Craig McClanahan <cr...@apache.org>.
On 8/25/06, Paul Spencer <pa...@apache.org> wrote:
>
> An advantage with the current dialog.data bean is that it allows a the
> use of a common view when the underlying data objects are different. How
> would this be done with dialog managed beans?
>
>
> As an example the AbstractPayment class has a CreditCard and a Check
> implementation. Both the "Pay By Check" and "Pay by CreditCard" share a
> common view that collects the billing address information. In the
> current implementation, that view uses #{dialog.data.billingZipCode} to
> pass the billing zip code regardless of the actual class. With dialog
> managed beans their will be a check and creditCard bean so how would the
> billing zip code be referenced in the common view? So unless their is a
> way to alias the beans in the dialog configuration, the billing address
> view can not be shared.
You are limited to a single instance of #{dialog.data}, but that bean itself
can have properties that are, in fact , beans ... and you can nest as deeply
as you like. So, your Payment class (the one you use as the data bean for
one of the processes could have a property of type AddressBean, and you
could therefore have binding expressions like "#{dialog.data.address.zipCode}"
to talk to it. The only collaboration that would be needed here is that all
of the 'outer" data beans that used an AddressBean would need to store it
under the same property name. You don't have to worry if the type of the
"data" bean is different, because the EL machinery takes care of all of that
for you.
Paul Spencer
>
Craig