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
