Kevin Duffey wrote:
> Hi,
>
> >Would another option be to check the current context (instead of having
> >multiple suffixes)? (This way everything still routes thru your single
> >controllerServlet.)
>
> Not quite sure what you mean by this. I have to admit there are still things
> I dont quite understand in the whole servlet model. Does the context refer
> to EVERY application running? Or when you get the servlet context during the
> init() method, is that specific to the application the init method is called
> in?
>
If you follow the packaging principles in the 2.2 servlet spec, you will have a
servlet context per web application, that can run essentially independently of all
other applications running in the same container. For all servlets packaged within
that app, getServletContext() returns the same ServletContext instance -- the one
controlling that application. That's why you can use servlet context attributes
(in JSP they are application scope beans) to share information between the servlets
and JSP pages that make up an app.
>
> >Does it make sense to add a parameter to the perform() function to
> >represent the target Page? E.g.
> >
> >public interface Action {
> > public void perform(HttpServlet servlet,
> > HttpServletRequest request,
> > HttpServletResponse response
> > String targetPage)
> > throws IOException, ServletException;
> >} // ends interface Action
> >
> >{BTW, thank you Craig for the above!}
> >
> >This way the target page is (more) open to configuration (specifically, the
> >configuration file that links request uri's with java class names, would
> >also specify the target page. And, of course, only under exceptional
> >circumstances would the user be redirected back to the request uri, an
> >error uri, etc.
>
> I would think not, because how is the controller servlet going to pass the
> right forwarding URL to each action? I mean, what if the logic of one action
> class may forward to many different pages depending on the outcome of the
> logic? I would think the forwarding page should be defined or figured out in
> the action class, EJB, whatever is doing the logic. An example would
> be..what if you needed to go to a different page based on a STATE drop-down
> on a form. Each state has its own page. The controller servlet I guess could
> read this in from an XML file..but I think this is "logic" that shouldn't be
> done in the controller servlet.
>
In my code, its the action class that knows where it wants to go next, not the
action servlet. However, I made a mistake in my first app, and used hard coded
names of the JSP pages to be forwarded to -- not very nice when I wanted to
rearrange my page names and had to go modify all the action classes.
Now, I tend to add a public method in my controller servlet that can look up actual
page names from a logical name (as someone else in this thread recommended). This
is yet another Hashtable (or HashMap :-) that is configured in the init() method,
either from servlet init parameters or from an XML file.
>
> >I think of the action class objects as still part of the controller level
> >(from Model - View - Controller). Since their role in life is to mediate
> >between the UI & the Model (your EJB objects, or, as in my case, our Corba
> >objects, whatever). If your business logic objects have method signatures
> >including HttpServletRequest and the like, then you're only going to be
> >accessing them thru a web-based frontend. (Not necessarily a bad thing if
> >you're a web developer!)
>
> Thats a good point. I am curious as to how you pass, say, the values of a
> form field on to the EJB (or business) layer. Do you just pass it the
> request object, or do you parse the request object into some intermediary
> object, pass that on to the business layer, and it works with it that way? I
> would agree though..I can't imagine passing on an HttpServletRequest, which
> is the front-end webserver stuff, to the middle-tier logic. Seems that the
> middle-tier would expect a certain bit of info passed to it via a simple
> object, like a javabean or something.
>
I agree with Daniel here. Some have likened Action classes we've been talking
about to the "command" pattern in the GoF design patterns book. You can also think
of them as "adapters" -- they translate between the HTTP format (request
parameters) to the model format (bean properties). Passing the HttpServletRequest
object on to your bean (be it an EJB or a JavaBean) would bypass this, but (much
worse IMHO) it ties your bean to being used *only* in a servlet environment. You
really want your business logic (the "model" beans) to be independent of whether
you're running inside a servlet container or a Swing-based GUI app, or an CORBA or
RMI based server, or ...
>
> Then again..I am not in full understanding of the EJB spec and thus cant say
> that I am correct in this.
>
>From the client programming point of view (i.e. from an Action class), an EJB is
pretty much a JavaBean that has some fancy extra capabilities. It's not that much
different from programming with regular JavaBeans for the business logic.
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
