shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Geary" <>
Subject Re: [dialog] Get rid of subdialogs
Date Thu, 24 Aug 2006 17:08:28 GMT
2006/8/24, Sean Schofield <>:
> > OTOH, I don't think this necessarily warrants a change to subdialog
> design
> > because dialogs  have the mechanisms to deal with this. The starting
> state
> > for a subdialog can be an action state, and that method can set up the
> > reference before entering the first view state.
> Its true you can always maintain dialog data outside of the dialog
> mechanism by setting up your own session scoped bean in the starting
> action state.  If you do this, you bypass one of the supposed benefits
> of dialog which is that it manages a state for you that lasts only
> during the duration of the dialog.

Actually, I'm not using session-scoped beans and I am taking advantage of
dialog scope. Let me explain.

The benefit of dialog state is that views have reference to the state
through #{}. In my setup actions, I assign instance variables
(they're not session scoped) to #{}. No matter what view is
invoked, the correct data is always referenced through #{}, so
I'm taking advantage of dialog scope.

IOW, Shale doesn't manage a state for you that lasts only during the
duration of the dialog; instead, it makes that state available to the view
via #{} only during the duration of the dialog. How long the
state lasts is another matter.

To clarify things, here's some code. I've got a Bill Pay dialog with a Wire
Transfer subdialog.

In payment.xml, which defines the Bill Pay dialog:

  <dialog name="Payment" start="Setup">

        <!-- This transition is applicable to
             all states in this dialog -->
    <transition outcome="cancel" target="Exit"/>

    <action name="Setup"
       <transition outcome="success"
                    target="Payee Information"/>

        <!-- Payee Information -->
    <view name="Payee Information"
      <transition outcome="next"
                             target="Payment Method"/>

Shale calls DialogLauncher.setupPaymentDialog() when you enter the dialog
and then transitions immediately to Payee Information.

Similarly in wireTransfer.xml:

  <dialog name="Wire Transfer Dialog"

     <action name="Setup"
         <transition outcome="success"
                      target="Bank Information"/>

     <view name="Bank Information"
         <transition outcome="next"
                      target="Account Information"/>
         <transition outcome="cancel"

Shale calls DialogLauncher.setupWireTransferDialog() when you enter the
dialog and then transitions immediately to Bank Information.

So I have two methods: setupPaymentDialog() and setupWireTransferDialog() in
DialogLauncher. Those methods assign the appropriate objects to

package com.corejsf.dialog;

import org.apache.shale.view.AbstractFacesBean;

public class DialogLauncher extends AbstractFacesBean {
    // billpayData contains all of the properties for the
    // payment dialog. It also contains a couple of JSF
    // action methods used for navigation, and an
    // embedded wire transfer data object
    private BillpayData billpayData = null;

    // Called just afer entering the payment dialog
    public String setupPaymentDialog() {
       // Create billpay data and nested wire transfer data
       billpayData = new BillpayData();
       billpayData.setTransfer(new WireTransferData());

       // Set dialog data with the handy setValue method
       // from org.apache.shale.view.AbstractFacesBean
       setValue("#{}", billpayData);

       // This outcome takes us to the payment dialog's
       // first view
       return "success";

    // Called just afer entering the wire transfer dialog
    public String setupWireTransferDialog() {
       // Set the dialog's data to the wire transfer object
       // stored in the bill pay data
       setValue("#{}", billpayData.getTransfer());

       // This outcome takes us to the wire transfer dialog's
       // first view
       return "success";

I'm not 100% convinced such a dialog scope is that useful, but if you
> are going to provide such a mechansim, you need to be able to *easily*
> access it through the duration of the dialog and all subdialogs in the
> chain.  Right now the data is "popped" off the "stack" each time you
> enter a subdialog so you can't use #{} in your JSF to refer
> to stuff from a previous page.

I think the scope is useful, but I'm still not convinced the extra
complexity required to support easy access of ancestral data on the dialog
stack is worth the effort. It seems to me that you can easily handle
situations like this with setup actions that synthesize the right data and
make it available to the view via #{}.


> > david
> Sean

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message