Initializing the data:
One solution would be to implement javax.servlet.ServletContextListener
interface and define it in your web.xml. This is a type of bootstrap class
for web applications. When it is invoked populate all of your static data
and place it in the ServletContext where it is available to all users. This
solution is not bound to the Struts framework and is portable. All
XXXXListeners are invoked before the web application processes any requests
so your data is guaranteed to be available (assuming it was successfully
retrieved).

public void contextInitialized(ServletContextEvent event) {

    ServletContext context = event.getServletContext();
    Collection categoryOptions = null;

    try {

        categoryOptions = // DAO retrieves data.

    } catch (Exception e) {
       // handle exception
       // log warning
       categoryOptions = new ArrayList(); // prevent screen from blowing up
    }

    context.setAttribute("categoryOptions", categoryOptions);

}

Rendering the data:
One solution would be that since your static data already exists in the
ServletContext, you could user JSTL, Struts tags, or custom tags to retrieve
and render their values. In this manner you avoid having a "set up" action
which prepares the page for display and you can simply directly  request the
.jsp page; assuming ofcourse that there is no other preparation for the page
beyond the existence of the static data.
Let's say my form has a data member called "category" and I have placed
category options under the key
"categoryOptions" in the ServletContext, then the following syntax would
work assuming your Collection
was a collection of LabelValue beans.

<html:select property="category">
<html:optionsCollection name="categoryOptions" label="label" value="value"/>
</html:select>

Another strategy would be to use the ActionForm as a container for all data
that is rendered to the page.
This requires a set up action to prepare the page. For example, the set up
action would retrieve the static data from the ServletContext and populate
the form with the values, then forward to the page.
In this example we have the same form data member "category" and we also
have an additional data member called "categoryOptions".

<html:select property="category">
<html:optionsCollection property="categoryOptions" label="label"
value="value"/>
</html:select>

Yet another strategy would be a combination of the first two, that is if
your page contained both static and volatile data.

HTH,

robert



> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 02, 2002 7:57 PM
> To: [EMAIL PROTECTED]
> Subject: Help with Struts + DB Access
>
>
>
> I'm trying to put a select list on my page.  The contents of the
> list need to come from the database.  I have a DAO layer, so I'm
> doing okay isolating the database access, but I'm still not quite
> sure when to retrieve the values and where to put them.
>
> In most of the examples I look at, and the struts-example webapp
> is no different, when you get down to the details, it'll say
> something like:
>
> "In real life, these would be loaded from a database"
>
> Well, that's in the 'subscription.jsp' page, and I *know* that
> "in real life" it wouldn't be loaded from the database *there*!
>
> I'm reading the docs for the <html:collection> and there are so
> many combinations of attributes that I'm still a bit confused.
> So far I've worked out that I can:
>
> 1. Put a Collection in some scope, as the example does.
>
> 2. Put a method in my ActionForm extension that returns a Collection
>
> There are probably more.  Can someone give me some guidance on
> which method of supplying choices for a select list might work
> best for me?
>
> I'd like to get them into application scope if possible-- once
> they're loaded they're good "forever" and can be shared among
> sessions.  (They change infrequently, and can wait for a restart
> on maintenance weekend to load the new values.)
>
> Thanks!
>
> --
> Wendy in Chandler, AZ
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


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

Reply via email to