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