Kevin Duffey wrote:
> 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.
>
Sure ... this works fine. You can also <jsp:include> another JSP page if
that's the way you've got your subordinate view components organized.
>
> >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?
>
Using servlet-per-form is certainly possible, but it gets down to a couple of
issues:
* Net number of lines of "overhead" code to add a
new action is slightly higher (but we're talking like
10 lines of code versus 5, so not a huge deal).
* You might want to implement some common logic,
like enforcing login (by checking for existence of a
particular session attribute) which can be slightly
easier in a single servlet.
At this level of detail, it's probably more personal preference than anything.
>
> >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.
>
All J2EE-compatible servers will utilize the web.xml format descriptor for
servlet/JSP based apps, so it's totally portable. It is a few more characters
to edit web.xml versus a properties file, however.
>
> >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.
This is a one-time mapping for all of them:
<servlet-mapping>
<servlet-name>MyControllerServlet</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
No changes to the mappings are required as you add new action procedures, where
there would be if you use servlet-per-form.
> 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.
>
JavaBeans don't really have to be serialized unless you need them to be
persistent. The servlet spec only requires you to use Serializable session
beans if you mark your app as <distributable/>.
Lots of people have built session management architectures prior to the advent
of the 2.2 spec, along with home grown security mechanisms. What I plan to do
is rip out all the authentication and user role checking stuff I've hand built
over the years, and use the declarative security constraints that are now
portable. It's worth reviewing your session management architecture in the
light of the new standards when you have a few minutes of non-panic mode (yah,
like *that* ever happens :-).
>
> Look forward to your reply. Take care.
Craig
===========================================================================
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
