Another option is to use the JSP BEAN tag with application scope (this will
implicitly put it in the ServletContext). For example
(using jsp1.0 syntax *Note: pre 1.0 does not have "application" scope)
<jsp:useBean id="question_manager" scope="application"
class="package.MultipleChoiceQuestionManager" </jsp:useBean>
Putting this tag on all necessary jsp pages will allow you to access this
object like
<%
MultipleChoiceQuestion1 mcq1 =
question_manager.getChoice("multiple.choice.question.1");
Data data = mcq1.getData( param );
String d1 = data.getProperty("d1");
String d2 = data.getProperty("d2");
//display it in the html
%>
The MultipleChoiceQuestionManager could extend java.util.Hashtable and give
you utility methods like Craig explained.
Tom Ivers
email:[EMAIL PROTECTED]
http://www.portera.com
"Portera.com - Online Headquarters for the Professional Services Industry"
-----Original Message-----
From: Craig McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 04, 1999 9:14 AM
To: [EMAIL PROTECTED]
Subject: Re: Storing application objects in the ServletContext
Willie Wheeler wrote:
> Hi all,
>
> In a JSP, is it appropriate to use the implicit 'application'
> ServletContext as a repository for application-level objects that I want
> to create? E.g., let's say I want to create 200 MultipleChoiceQuestion
> instances. Is it "ok" to dump them all onto the ServletContext?
If the objects need to be shared across multiple JSP pages and/or servlets,
the
ServletContext is a natural place to stash them -- that is exactly what it
is
designed for.
>
> Does the ServletContext provide for any kind of bean management
> (e.g., caching)? If not, then is the standard approach to write my own
> MultipleChoiceQuestionManager, stick the beans in there, and then stick
> the manager in the ServletContext?
>
Think of the servlet context attributes as a Hashtable with a little bit
different
method names. The thing that's probably going to matter most in your
example is
the fact that every object you store here needs to have a unique key. So,
you
would need to either manufacture unique keys "multiple.choice.question.1"
through
"multiple.choice.question.200" for the individual questions, or wrap them in
a
manager bean under a key like "multiple.choice.questions". For 200 of them,
I'd
probably choose that approach, which also allows your manager to have some
other
useful logic ("grab me the set of questions that goes on page 3 of the
questionnaire").
>
> Thanks!
> Willie Wheeler
> [EMAIL PROTECTED]
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
