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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> >
>> >> On 8/25/06, Paul Spencer <[EMAIL PROTECTED]> 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
>> >>
>> >>
>> >
>> >
>>
>>
>
>
