Struts Class 5

Steps to understand the above Architecture:-

In the above Architecture we understand two phases.

Phase I:- The initialization phase:

         -> In this phase we understand Struts components initialization which commences with ActionServlet initialization

         -> In ActionServlet initialization the configuration files are read or looked. 

         -> Checks for ModuleCofigurations whether Modules are configured or not.

         -> If Modules are not configured , default module is taken.(in details about modules at later stages of our learning)

Note: Modules are configured in web.xml file using the init-param tags, for the default module the configuration is

                  <init-param>

            <param-name>config</param-name>

            <param-value>/WEB-INF/struts-config.xml</param-value>

                  </init-param>                   

for module configuration

Ex:     <init-param>

        <param-name>config/[moduleName]</param-name>

        <param-value>/WEB-INF/module-config.xml</param-value>

        </init-param>

         ->The next step in the initialization process is module initialization.

         ->Here ModuleConfig object is prepared.

         ->This object consists of configuration file and a unique name(modulename).

         ->The next process is initialization of RequestProcessor where RequestProcessor is initiated  and injected with ActionServlet instance and ModuleConfig instance.

         ->Initialization of any PlugIns configured or any Frameworks plugged like tiles.

Note: ActionServletInstance and ModuleConfig instance are maintained in instance variables, for the further use.

Phase 2:

         -> Clients request initiates to ActionServlet

         -> In the process() behaviors of ActionServlet, navigation logic is implemented to locate the module. Module is located by matching the first part of the request with the module name configured.

         -> The next step in delegation i.e request is delegated by calling process() behaviors on the RequestProcessor instance.

         -> Request is given to the RequestProcessor where RequestProcessor performs various steps like

                 processMultiPart();(we discuss about this later)   

                 processPath(): Here navigation logic is implemented to locate the Action, where the request uri is matched with the path attribute value of the <action>tag.

              If the match is not found we get 404 ErrorCode if match is found.

            ->Checks whether the Action is instantiated or not.

            -> If the Action is not intantiated, instanciated the action where processActionCreate() behavior of RequestedProcessor is invoked.

            -> If instantiated fails, we get an ErrorCode 500

Note: In our application we need Action class and <action> tag ActionClass is an Wrapper between the request and the corresponding BussinessOperation.

      The ActionMapping object describe an Action object, meaning for every <action> tag an ActionMapping object is created where ActionMapping object is encapsulated with type,name,path,forward,exception... details of an Action.

Note: ActionMapping used in the Application represents the details to map the request to particular Action instance.

     

      -> After the Action is instantiated, process ActionPerform() is called, this results to invoke the execute(-,-,-,-) behavior.

      -> The execute(-,-,-,-) behavior may return null, if the response is generated in the Action.

      -> If the response is not generated in the Action, the execute(-,-,-,-) returns ActionForward to the RequestProcessor

(recall am.findForward("logical name")), this returns ActionForward Object).

Note: for every <forward>tag, this object is created which consists of name & path. 

         -processForwardConfig() behavours is invoked, results to forward or send Redirect to the respective path using RequestDispatcher's forward mechanism(recall of servlets). This results to display the respective view page.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the previous example, to retrieve the client parameters we used the logic.

    req.getParameter("parameterName"); or we say this is the logic used to exchange the data between the view and Action but implemented this logic, results to issues like

                - Complexity 

                -Dependency to the Actions.

Struts Class 4

Struts Architecture

Struts Class 3

Struts 1.3.10:
So far discussion gave an idea what is the workflow of Struts and what Design Patterns are implemented. Before we use Struts w.r. to WebApplication development lets see few advantages of Struts.

1. Presenting Dynamic web content to the web clients in a faster, simpler and easier manner.
2. As it is built on top of Servlet & JSP specifications we can deploy the Struts applications in any web or application servers.
3. Provides Infrastructures, so we take the advantage of Declarative Exception handling, Declarative validations and also Programmatic validations(at server side).
4. As Struts is open source, customization is not a deal. Meaning we can have further UserExtensions.
5. Helps in designing the view pages followed with implementing Composite view design pattern(i.e Struts with Tiles framework).

To understand in detail about Struts components and the work flow we directly commence by implementing an application.




Requirement is validating User name and password.

• Write a Login.html
• Write a web.xml
• Write an Action Class? How?

     ->Your class should be sub type of      org.apache.struts.action.Action
     ->Override the execute() behavior which takes the following inputs
         -->ActionMapping
         -->ActionForm
         -->HttpServletRequest
         -->HttpServletResponse
         -->throws clause is throws "Exception"
     ->Output type of execute() behavior is ActionForward.


     ->Write a struts configuration file.
     ->Write a jsp document as a view page.
What is the Directory Structure to arrange the above?
As Struts is a web Application framework it uses the same directory structure that we used for Servlets and jsp.

      
     Login.Html

web.xml


<web-app>
    <servlet>
        <servlet-name> st1  </servlet-name>
        <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
   </servlet>
   <servlet-mapping>
        <servlet-name> st1  </servlet-name>
        <url-pattern>*.stech</url-pattern>
   </servlet-mapping>


</web-app>


LoginAction.java



import javax.servlet.http.*;
import org.apache.struts.action.*;


public class LoginAction extends Action{
    public ActionForward execute(ActionMapping am,ActionForm af, HttpServletRequest req, HttpServletResponse res)throws Exception{
    //retrive the client sent parameters
        String name=req.getParameter("uname");
        String pass=req.getParameter("pass");
        //now validate the username and password
        // not recommanded database logic in the Action
        //use controlflow statements
        if(name.equals("user1")&&pass.equals("pass1"))
            return am.findForward("success");
        return  am.findForward("failure");


    }//execute
}//Action class

struts-config.xml : 

<struts-config>

    <action-mappings>

        <action type="LoginAction" path="/login">

            <forward name="success" path="/welcome.jsp"/>

            <forward name="failure" path="/Login.html"/>

        </action> 

    </action-mappings>

</struts-config>

welcome.jsp:

Welcome to Java at:: <%=request.getParameter("uname")%>

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

for classpath we need the following jars to compile the program.

servlet-api.jar

struts-core-1.3.8.jar

url:

localhost:2010/ex1/Login.html

Struts Class 2

Continued....

The above diagram says:

-> FrontController acts like an Entry point.

-> It provides low level services with respect to RequestProcessing.

-> It manages the WorkerComponents(WC in fig) and also view components.

But in the above diagram we have another requirement like: if the number of WorkerComponents increases, again burden sits on the FrontController.

To overcome this type of issue, we go for another presentation tier design pattern named as ApplicationController. Using which we can modularize like set of WorkerComponents are managed by an ApplicationController.

Another ApplicationController can manage another set of WorkerComponents and so on.

The following diagram gives us an idea about the ApplicationController Design Pattern implemented.

In the above diagram we find FrontController taken part in providing only low Level services and the ApplicationController's responsibilities are ViewComponent management and WorkerComponent management.

The same is what we have with respect to Struts Architecture, where FrontController implemented component is termed as ActionServlet.

ApplicationController implemented component is termed as RequestProcessor.

CommandPattern implemented components are ActionComponents which we referred as WorkerComponents above.

Note: Struts is limited to Presentation Tier only.

Bye till next class

Struts Class 1

                 STRUTS
-> It is an OpenSource Web MVC Framework, given by Apache Software Foundation, and it is built on Servlet and JSP specification and used to build Java Web Application.


What is a Web Application?
An Application that provides data and services to web client.


What is Web Client?
Which makes a request using web protocals.


What is a Framework?
It is a well-defined set of classes and Interfaces.


The next responsibility is to understand how do we use STRUTS with respect to Application Development?
--> First we need to understand the STRUTS workflow.


where we commence with different architectures, i.e one of the best implemented Architecture pattern i.e web MVC architecture. 


-> In this Architecture Data presentation is separated from Data representation and a third component is used to integrate the two.

Role of MODEL: this takes in Data Representation i.e stores and retrives data.

Role of VIEW:  Takes part in Data Presentation i.e prepares the Presentation that is presented to the client, in short we say it holds Presentation Logic.

Role of Controller: Controller plays main role in MVC Architecture.

where Controller takes a request from the client and locates the appropriate model component and then dispatches the request, takes the response from the model, locates appropriate view component and forwards.

-> so the controller only integrates the model and View Components.

In the above architecture imagine the number of clients making the request increases, results to Burden on the controller.

Possible solution is: Designing Multiple Controllers, solves the above issue but we get a new issue, we loose Centralized accessability i.e access becomes Decentralized.

So what is the best solution where we meet the above requirement and also achieve Centralized accessability, so solution is given by a design pattern or a Presentation tier Design Pattern Named as FRONT CONTROLLER...

wait till tommorrow...

Catch u soon....

ur

Struts Developer..