struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [Shale] Resource initialisation best practice
Date Fri, 18 Mar 2005 17:21:40 GMT
A technique I like (and is actually used in the Use Cases example) is
to make your reference data into an application-scoped managed bean
(for stuff common to all users; use session scope if it is user
specific).  Then, the first use of a value binding that needs to load
the reference data will cause it to happen (via the managed beans

For example, there is a "select many" component listing available
categories on (among others) the logon/profile3.jsp page:

        <f:selectItems  value="#{domains.supportedCategories}"/>

The "domains" bean is an application scoped managed bean that (for the
simple lists) has a getter for each one.  The contents of the list can
be composed with literal Java statements (as was done here for
simplicity), loaded from a database or web service call, or whatever
you need.

For extra credit, you can hook up JSF-Spring and use Spring's
mechanisms to configure the managed bean for you.


On Fri, 18 Mar 2005 10:21:47 +0000, Duncan Mills
<> wrote:
> Fellow Shale'ers,
> Given the scenario when you have reference data to set up, say on the
> application, which is not dependent on a particular view, but which must
> be put in place before the first view is displayed, and given that there
> is no single entry point for the app, what approach would you take?
> What I'm currently doing is inserting a custom command into the Shale
> preprocess chain . This works OK, however, I'm "distressed" by the fact
> that I can't save the relevant state using a valueBinding because at the
> point in time the Chain command is first executed there is no
> FacesContext.  So instead I have to set the application attributes
> directly.
> Plan B would be to do the same setup in a common superclass of
> viewController which will have access to a valid FacesContext, however,
> I'd rather keep this general setup logically away from the per page
> setup. Does anyone have any other ideas?
> Duncan Mills
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message