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.
Paul Spencer
Craig
