Craig,
I understand. One thing, however - I still was going to have the main
"controller" servlet that was going to do the routine things - check for
login, check for session, etc. Then *that* controller servlet was going to
instantiate the Action servlet and call its doGet(). But as you say, that
would be overkill since the Action servlet would carry a lot of unnecessary
baggage.
Am I right that your Action classes then just each extend the Action
interface and have just the one perform() method? And the Action class is
the one that forwards to the correct JSP page?
Thanks, Bill
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 24, 2000 12:50 PM
To: [EMAIL PROTECTED]
Subject: Re: Model 2 - Instantiate Action & Call doGet()?
"Hines, Bill" wrote:
> In the model 2 architecture that many of you use, is the Action class
> derived from HttpServlet? I saw a code example where I think it was a
> generic class, but passed in the calling servlet, request, and response.
> Would it be better to just make it a servlet and instantiate it and then
> call its doGet(), passing in the request and response? If possible, this
> might allow me to more easily port an existing app to this architecture.
>
In my case, the Action interface (not really a class) is *not* a servlet --
it has
one method:
public interface Action {
public void perform(HttpServlet servlet,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException;
}
It is certainly possible to make each action a servlet -- and then it's even
possible to call them directly instead of going through a controller.
However,
I've found the following disadvantages to this for my own apps (your mileage
may
vary):
- You lose the fact that the controller servlet
can perform common logic (such as making
sure you've logged on) for all requests -- you
would now need to make sure that this is
done in every single action servlet.
- You tend to create subtle dependencies between
the presentation logic and the business logic
based on the URLs being used. I find it easier
to avoid this temptation if I'm using an action
class that is clearly not a servlet.
- If your action procedures don't need the full
lifecycle support (init and destroy methods) that
servlets support, making them servlets is overkill.
(If they do need this support, maybe you should
look at designing them to access shared servlet
context attributes that are initialized when the
server starts up instead?).
For some folks, action servlets works just fine because they don't need a
single
point of management. Personally, I find it easier to separate roles, and
design my
action classes as "adapters" (in Design Patterns terms) between the
parameters
coming in with the HTTP request, and the business logic beans or EJBs that
actually
do things.
>
> Thanks, Bill
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
