shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Spencer <pau...@apache.org>
Subject Re: [dialog] How to use a common view with different dialog managed beans?
Date Sat, 26 Aug 2006 01:26:06 GMT
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
View raw message