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