piyush raj jain wrote:
> hi model2 camp..
> newly joined the camp, following the threads from past two weeks..
> sorry if this kind of stuffs already been discussed
>
> i was also thinking that what is wrong if my controller will pass the control to a
> action servlet which implements the action interface.
> advantages:
> 1.if i am not maintaing the hashtable of action object like craig , (just storing
> the names and dynamically creating an object for each request , same what kevin is
> doing ) then my action servlet will give me the benifit of servlet life cycle .
>
As I just responded to Kamalesh's post, it's probably OK to do this -- but don't
succumb to the temptation to mix presentation logic in your action servlets. They
should still just do the business logic and forward to JSP pages for output. ((NOTE --
in all cases where I have been saying "use JSP pages" for output, you could also use
servlets based on some nice template mechanism; but I find JSP easy and its very widely
supported))
My action classes tend to be 50-150 lines of code -- nearly all of which is copying
HTTP parameters into bean properties, calling bean business methods, and storing
results. I haven't ever found any need to have lifecycle support for them.
>
> 2.through servletcontext i can access the application level objects while
> processing my logic in action class,and once controller will pass me the
> resposibilty i will never ask controller to do any thing else, all further
> processing will be done by second level action servlet .This can give me cleaner
> architecture.
>
As long as you don't map your action servlet to its own URL. If you do, you're going
to tempt page designers to bypass your controller servlet and go directly to the
"right" action servlet. This is one more subtle linkage between presentation logic and
business logic that you want to think about.
>
> 3.If i can divide my application in number of different domains then i can call
> these servlets as a subcontroller, which will act as a controller for a particular
> area of application.
>
That's certainly possible -- you could do the same thing by having subcontrollers that
still used action beans if you wanted to.
>
> 4.request can be fulllfilled by multithreded architecture of servlet engine (i need
> not to do the thread programming in my actiion classes .)
>
Here is where I think you are going to be unpleasantly surprised. The multithread
environment issues apply just as much to the "action servlet" design pattern as they do
to "action beans", because there's only one instance of the action servlet class --
exactly like I only create one instance of the "action bean" class of any particular
type.
There's a ***partial*** workaround in the servlet API -- if your servlet implements the
SingleThreadModel interface, the servlet container guarantees that it won't call that
particular servlet instance on more than one thread at the same time. However, you are
not out of the woods -- there are lots of cases where the same user can cause more than
one request to be in progress at the same time, so you *still* have to deal with
multithread impacts on all your beans.
>
> thanks
> piyush
>
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
