Craig and Kevin,
First of all, thanks - I'm a newbie and I've really learned a lot from
reading your correspondence.
I'm dying to know, the instance of the action class, is it multithreaded or
do you use it to create other instances of the same class?
As well, what happens with input errors? More methods in the Action
interface, like:
public boolean hasErrors();
public String getErrorMessage();
public String getHandlerURI();
i.e....
try {
action.perform(this, request, response);
if (action.hasErrors()) {
String errorMessage = action.getErrorMessage();
String handlerURI = action.getHandlerURI();
request.setAttribute("ERROR", errorMessage);
request.getRequestDispatcher(handlerURI).forward(request, response);
}
} catch (Exception e){...}
or perhaps...
public ErrorBean getError(); // (which may return null?)
action.perform(this, request, response);
ErrorBean error = action.getErrorBean();
if (error!=null) {
request.setAttribute("ERROR", error);
request.getRequestDispatcher(action.getHandlerURI).forward(request,
response);
}
or with home grown exceptions:
try {
action.perform(this, request, response);
} catch (InvalidFormInputException ex){...
} catch (Exception e) {...}
thanks again,
Scott
> ----------
> From: Kevin Duffey[SMTP:[EMAIL PROTECTED]]
> Reply To: Kevin Duffey
> Sent: Saturday, March 18, 2000 4:19 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Need help with Model 2
>
> Hi,
>
>
> >I suppose you could call the controller servlet using a GET
> >request with query
> >line parameters, but in practice I always used a form for this.
> >Sometimes that
> >meant creating a form just to encapsulate a submit button that is
> >an image --
> >but a form nevertheless.
>
> Yeah..but so far I haven't seen a need to ever put an empty form just to
> call the servlet. Plus, with JSP you can map the .do like you mention
> later
> on, and just use <jsp:include page="someservlet.do" /> and call the
> servlet
> directly cant you? Not that any form parameters are passed, but I imagine
> you can do that if necessary..why I have no clue.
>
> >As you suggest -- if there's no business logic to be done, I don't see
> any
> >problem with linking directly from one JSP page directly to another. In
> >essence, the user is manipulating the View without modifying the Model.
>
> Agreed.
>
> >I'm not actually using reflection. All the action classes
> >implement something
> >like this:
> >
> > public interface Action {
> >
> > public void perform(HttpServlet servlet,
> > HttpServletRequest request,
> > HttpServletResponse response)
> > throws IOException, ServletException;
> >
> > }
> >
> >so that I just deal with instances of an Action. The advantages include:
> >
> >* Not all the logic is in one class, so it scales better and
> > never runs into a class size limit my JVM might impose.
> >
> >* The logic can be written by multiple members of a
> > team without fighting over a single source module.
> >
> >* Adding a new action requires zero software changes
> > to the controller servlet itself -- just a new configuration
> > parameter.
> >
> >* The controller servlet itself is generic enough to be used
> > for multiple web applications.
>
> Very good points. I like your ideas and it does have some merit. However,
> is
> there any difference really in the way your doing it, and using descendant
> servlets, one for each form say, much like you use one action class for
> each
> form?
>
> >I tend to use initialization parameters for the controller
> >servlet. It would
> >be just as simple to load from a properties resource file in the
> >init() method.
>
> I think I would prefer the property file just because I can edit it easier
> than editing init parameters, plus I would think it might be more portable
> to a J2EE app server. From what I have seen, init parameters have to be
> defined for each server you use. I could be wrong..but I thought I saw
> that
> somewhere. I know in Orion there is a .xml config file that you define
> init
> parameters for.
>
> >My favorite way is actually the third alternative that I presented in the
> >previous response. I map the controller servlet to a filename
> >extension like
> >"*.do" -- which implies "go do something". Then, my form submit looks
> >something like this:
> >
> <snip>
>
>
> >The three approaches (hidden parameter, path information, and extension
> >mapping) are all functionally equivalent, and roughly the same
> >amount of code
> >in the controller servlet (one or two lines) -- I just find this
> >one makes my
> >JSP pages more readable.
>
> I agree with you. It does make for easier reading. The only downside is
> that
> you do have to do some changes on the server. The main one being mapping
> all
> .do files to a specific servlet. But, I have to admit..I like it. Seems
> the
> overall setup is using simple classes to handle the work, instead of
> servlets, with only a single servlet to call the action classes. The thing
> of it is..if it gets the "class" name from the property file (or init
> param), how does it call the class? I would think it has to use reflection
> to do that doesn't it? How else do you pass in a String and call a class
> by
> that name?
>
> >In my EJB-based apps, the work is indeed done in the EJB -- the
> >action class is
> >just an "adapter" that maps from HTTP request parameters into appropriate
> >property setting and method calls. In my non-EJB based apps, I
> >use business
> >logic beans to do all the real work -- and these beans have no
> >clue they are
> >being invoked in a servlet based environment (i.e. no imports of
> >"javax.servlet.*"), so they can be reused in non-servlet-based
> >apps as well.
>
> Hmm..interesting. I guess that is what we use really. We use simple
> classes,
> some of them derived from others to include generic functionality. We dont
> serialize them, at least not in the sense of a JavaBean that is
> serialized.
> We have "core" classes that contain a session package which is where we
> put
> our session classes. This isn't my design, incidentally..its what was here
> when I started. But it does work.
>
> Look forward to your reply. Take care.
>
> ==========================================================================
> =
> 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
