shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Schofield" <sean.schofi...@gmail.com>
Subject Re: [dialog] How to use a common view with different dialog managed beans?
Date Sat, 26 Aug 2006 00:00:37 GMT
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 <paulsp@apache.org> 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 <craigmcc@apache.org> wrote:
> >
> >> On 8/25/06, Paul Spencer <paulsp@apache.org> 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
> >>
> >>
> >
> >
>
>

Mime
View raw message