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 .
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.
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.
4.request can be fulllfilled by multithreded architecture of servlet engine (i need
not to do the thread programming in my actiion classes .)
thanks
piyush
"Loganathan, Kamalesh" wrote:
> Craig/and All,
>
> I've been following the Model 2 thread. I've the following model working.
> I've customized the Model 2 to meet our business requirements.
> (constraints??). Could you all please review and comment ? Here is the
> overview.:
> * The HTTP request arrives and is dispatched to the Controller
> (Router) servlet. This is done based on configuration rules provided when
> the application is installed.
> * The controller servlet delegates the request to appropriate servlet.
> (Why can't we use a 'servlet' instead of 'action' class ? What are the
> disadvantages?? ) The application servlets acts as command beans and
> implements the customization required for the application. The controller's
> sole responsibility is to delegate the requests.
> * The application servlet makes calls on one or more service beans to
> perform the logic of the request. All application servets requiring
> security extends a SecureServlet which implements page and event level
> security.
> * The service and beans implement the business logic and may leverage
> relational database access, connectors, or the Web application
> infrastructure to perform its computations.
> * Based on the results of the computation the servlet either selects
> and invokes a JSP or does an HTTP redirection to another structured
> interaction. In the former case, the servlet will need to post some of the
> results (Datastore, DataSheet - glorified hashtables.) of the computation to
> the execution (HtttpRequest & HttpResponse) context for use by the JSP
> before calling it. In the latter case, the servlet will usually need to
> place some of the results of the computation into the session context so
> that it can be picked up by the next interaction.
> * The dynamic content on the selected page is filled in from the
> request and session context and the page is sent to the client. This may
> leverage:
> formatting beans, other JSP pages, and static content components.
>
> Thanks,
> Kamalesh.
>
> ===========================================================================
> 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
