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