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
<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.
