Just to show there's more than one way to skin a cat:

#1) Create a custom tag library to share an application-wide cached value of
the order list, and populate the list into scope:

### in your custom tag handler
  public int doStart() {
    if(cacheNeedsRebuilding()) {
      List orderList = buildCache();
      pageContext.setAttribute("net.reumann.appl.cache.orderList",
orderList,
          pageContext.APPLICATION_SCOPE);
    }
    return Tag.SKIP_BODY;
  }
### in your JSP
  <myTagLib:checkCache/>
  <html:select property="order">
    <html:optionsCollection name="net.reumann.appl.cache.orderList"/>
  </html:select>

#2) Have an Action populate the list into the Form before forwarding to the
display page. The chain starts with your action, which can implement your
desired caching scheme for the list of orders, then displays the JSP. The
JSP submits back to an action, which can restart the cycle.

### in struts-config.xml
<action path="/prepareForm"
        type="net.reumann.appl.MyAction"
        name="formBean"
        input="/display.jsp"
        validate="false"
        parameter="prepare">
  <forward name="next" path="/display.jsp"/>
</action>
<action path="/handleForm"
        type="net.reumann.appl.MyAction"
        name="formBean"
        input="/display.jsp"
        validate="true"
        parameter="handle">
  <forward name="next" path="/do/prepareForm"/>
</action>

### in net.reumann.appl.MyAction.java
  public ActionForward execute(ActionMapping mapping, ActionForm theForm,
...) {
    String param = mapping.getParameter();
    if(param.equals("prepare")) {
      return doPrepare(mapping, theForm, ...);
    } else if(param.equals("handle")) {
      return doHandle(mapping, theForm, ...);
    } else {
      throw new ServletException("bad param [" + param + "]:
struts-config.xml is b0rken");
    }
  }

  public ActionForward doPrepare(ActionMapping mapping, ActionForm theForm,
...) {
    FormBean form = (FormBean)theForm;
    form.setOrderChoices(getCachedOrders());
    return mapping.findForward("next");
  }

  public ActionForward doHandle(ActionMapping mapping, ActionForm theForm,
...) {
    FormBean form = (FormBean)theForm;
    // Do all the heavy lifting here
    return mapping.findForward("next");
  }



> -----Original Message-----
> From: Rick Reumann [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 10, 2003 3:58 AM
> To: Struts Users Mailing List
> Subject: Where to repopulate dynamic lists ?
>
>
> Sorry to repost this question but it still has me wondering...
>
>
> Say you have a form where a user is to select "An Order To
> Update" from
> an options list. Now also assume that these orders to choose
> from change
> very frequently. You also will need to validate the form when it's
> submitted.
>
> * Where is it best to repopulate this type of dynamic list
> (example above: 'orders')? The list of orders that make up the
> options list needs to be repopulated somewhere in case validation
> returns false and returns the user to the form page again.
>
> It seems like you have three choices:
>
> 1) In the reset method repopulate the list by making a call
> to business
> layer to get back your list and put in scope (or maybe even directly
> into FormBean).
>
> 2) Use session scope so the list is available at all times until
> repopulated by some setUp type of action.
>
> 3) Possibly set this list in application scope upon container start up
> and maybe have a thread running that periodically updates the list and
> put the new list back into application scope.
>
> Are there any other options available? I happen to like #1
> the best but
> I'm wondering what others think. I don't really like option 2 as it
> requires a form to be put into session scope that really
> doesn't need to
> be there (apart from the re-population of lists). Also a pain
> to monitor
> cleaning the form out of session when it is no longer needed. Option 3
> would be ok if the information in the list rarely changed, but if it's
> data that changes very frequently I wouldn't want to rely on some time
> interval to have to go by before getting fresh data.
>
> Curious what other's thoughts are on this situation.
>
> Thanks,
>
> --
> Rick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to