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
facility).
For example, there is a "select many" component listing available
categories on (among others) the logon/profile3.jsp page:
<h:selectManyCheckbox
id="categories"
layout="pageDirection"
value="#{logon$dialog.categories}">
<f:selectItems value="#{domains.supportedCategories}"/>
</h:selectManyCheckbox>
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.
Craig
On Fri, 18 Mar 2005 10:21:47 +0000, Duncan Mills
<[EMAIL PROTECTED]> 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
> http://www.groundside.com/blog
>
> ---------------------------------------------------------------------
> 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]
