shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Geary" <sabrew...@gmail.com>
Subject Re: [dialog] How to use a common view with different dialog managed beans?
Date Sat, 26 Aug 2006 04:26:43 GMT
That's an interesting proposal. IIUC, this is kind of like Tomahawk's
aliasBean, but for Shale dialogs. You could achieve the same effect by
wrapping each of your view state jsp's with <t:aliasBean>. Right?

If we were to incorporate something like this, I think we should:

1. Allow multiple <alias>es.
2. Like transitions, have global and state-scoped aliases. Aliases declared
within a state would be scoped to that state. Aliases declared outside any
view would be global to all views in the dialog.

I'm a big fan of <t:aliasBean>. Reusing code for multiple managed beans is
very nice.


david


2006/8/25, Paul Spencer <paulsp@apache.org>:
>
> Sean,
> 1) I am neither for nor against scrapping #{dialog.data}.
>
> 2) I am advocating a way of mapping an existing, or new managed bean, to
>     a dialog managed bean as a part of the dialog configuration.
>
>     As an example the following would create a dialog managed bean
>     named paymentBean that is an alias for the creditCard managed bean.
>     This allows the common view, /getBillingAddress.jsp, to use
>     #{paymentBean} which is really #{creditCard} or #{check} depending
>     on which dialog is being executed.
>
>
>       <dialog name="Pay By CreditCard" start="getBillingAddress">
>         <alias="paymentBean" value="#{creditCard}"
>         <view name="getBillingAddress" viewId="/getBillingAddress.jsp">
>           <transition outcome="next" target="getCreditCardNumber"/>
>         </view>
>         <view name="getCreditCardNumber viewId="/getCreditCardNumber.jsp">
>           <transition outcome="next" target="processPayment"/>
>         </view>
>         <action name="processPayment" method="#{creditCard.processPayment
> }">
>           <transition outcome="success" target="paymentAccepted"/>
>           <transition outcome="rejected" target="paymentRejected"/>
>         </action>
>         <end name="paymentAccepted" view="/paymentAccepted.jsp"/>
>         <end name="paymentRejected" view="/paymentRejected.jsp"/>
>      </dialog>
>
>
> Paul Spencer
>
>
> Sean Schofield wrote:
>
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message