Professional Documents
Culture Documents
Struts is a java framework based on Model 2 architecture of JSP or popularly called Model-
View-Controller architecture.It provides a controller for this architecture.
Explain Struts navigation flow?
Struts Navigation flow.
1) A request is made from previously displayed view.
2) The request reaches the ActionServlet which acts as the controller .The ActionServlet
Looksup the requested URI in an XML file (Struts-Config.xml) and determines the name of the
Action class that has to perform the requested business logic.
3)The Action Class performs its logic on the Model Components associated with the
Application.
4) Once The Action has been completed its processing it returns the control to the Action
Servlet.As part of its return the Action Class provides a key to determine where the results
should be forwarded for presentation.
5)The request is complete when the Action Servlet responds by forwarding the request to the
view, and this view represents the result of the action.
What is the difference between Struts 1.0 and Struts 1.1?
We can call EJB from struts by using the service locator design patteren or by Using initial
context with create home object and getting return remote referenc object.
What is the difference between ActionErrors and ActionMessages?
There is no differnece between these two classes.All the behavior of ActionErrors was copied
into ActionMessages and vice versa. This was done in the attempt to clearly signal that these
classes can be used to pass any kind of messages from the controller to the view — where as
errors being only one kind of message.
The difference between saveErrors(…) and saveMessages(…) is simply the attribute name
under which the ActionMessages object is stored, providing two convenient default locations
for storing controller messages for use by the view. If you look more closely at the html:errors
and html:messages tags, you can actually use them to get an ActionMessages object from any
arbitrary attribute name in any scope.
STRUTS
Struts is an application development framework that is designed for and used with the
popular J2EE (Java 2, Enterprise Edition) platform. It cuts time out of the development
process and makes developers more productive by providing them a series of tools and
components to build applications with. It is non-proprietary and works with virtually any
J2EE-compliant application server.
The Model-View-Controller Architecture
“Model-View-Controller” is a way to build applications that promotes complete separation
between business logic and presentation. It is not specific to web applications, or Java, or J2EE
,but it can be applied to building J2EE web applications.
Model: Model is responsible for providing the data from the database and saving the data
into the data store. All the business logic are implemented in the Model. Data entered by the
user through View are check in the model before saving into the database. Data access, Data
validation and the data saving logic are part of Model.
View: View represents the user view of the application and is responsible for taking the input
from the user, dispatching the request to the controller and then receiving response from the
controller and displaying the result to the user. HTML, JSPs, Custom Tag Libraries and
Resources files are the part of view component.
Controller: Controller is intermediary between Model and View. Controller is responsible for
receiving the request from client. Once request is received from client it executes the
appropriate business logic from the Model and then produce the output to the user using the
View component. ActionServlet, Action, ActionForm and struts-config.xml are the part of
Controller.
Struts Components
1.Controller
This receives all incoming requests. Its primary function is the mapping of a request URI to an
action class selecting the proper application module. It’s provided by the framework.
2.Structs-cofig.xml File
This file contains all of the routing and configuration information for the Struts application.
This XML file needs to be in the WEB-INF directory of the application.
3.Action Classes
It’s the developer’s responsibility to create these classes. They act as bridges between user-
invoked URIs and business services. Actions process a request and return an ActionForward
object that identifies the next component to invoke. They’re part of the Controller layer, not
the Model layer.
4.View Resources
View resources consist of Java Server Pages, HTML pages, JavaScript and Stylesheet files,
Resource bundles, JavaBeans, and Struts JSP tags.
5.ActionForms
These greatly simplify user form validation by capturing user data from the HTTP request.
They act as a “firewall” between forms (Web pages) and the application (actions). These
components allow the validation of user input before proceeding to an Action. If the input is
invalid, a page with an error can be displayed.
*************************************************************************************************
FAQS
What is Struts?
Struts is a java framework based on Model 2 architecture of JSP or popularly called Model-
View-Controller architecture.It provides a controller for this architecture.
Explain Struts navigation flow?
Struts Navigation flow.
1) A request is made from previously displayed view.
2) The request reaches the ActionServlet which acts as the controller .The ActionServlet
Looksup the requested URI in an XML file (Struts-Config.xml) and determines the name of the
Action class that has to perform the requested business logic.
3)The Action Class performs its logic on the Model Components associated with the
Application.
4) Once The Action has been completed its processing it returns the control to the Action
Servlet.As part of its return the Action Class provides a key to determine where the results
should be forwarded for presentation.
5)The request is complete when the Action Servlet responds by forwarding the request to the
view, and this view represents the result of the action.
What is the difference between Struts 1.0 and Struts 1.1?
We can call EJB from struts by using the service locator design patteren or by Using initial
context with create home object and getting return remote referenc object.
What is the difference between ActionErrors and ActionMessages?
There is no differnece between these two classes.All the behavior of ActionErrors was copied
into ActionMessages and vice versa. This was done in the attempt to clearly signal that these
classes can be used to pass any kind of messages from the controller to the view — where as
errors being only one kind of message.
The difference between saveErrors(…) and saveMessages(…) is simply the attribute name
under which the ActionMessages object is stored, providing two convenient default locations
for storing controller messages for use by the view. If you look more closely at the html:errors
and html:messages tags, you can actually use them to get an ActionMessages object from any
arbitrary attribute name in any scope.
Misc
How to estimate project deadlines
Before jumping into calculating or estimating a Project Timeline, I will go through the steps of
how a software should be executed, so that whatever is estimated, actually works out that
way.
In the present day scenario where Time-to-Market issues achieve greater precedence over
other issues, which we have learnt over the years, the developers’ productivity and quality of
the software go out of the window. Has anyone thought why more and more open-source
projects are gaining such popularity compared to their proprietary counterparts?
The simple reason is the desire to build robust and good quality software where revenue
earned is not the major criteria. Open-source developers have a different mindset, they code
without selfishness, however that’s a different story.
Coming back to the topic, the software life cycle consists of: -
1. Analysis
2. Design
3. Construction
4. Deployment
5. Maintenance
Each of the phases is tightly coupled with each other and a slippage in any of the phases will
always carry down to the following phases. This brings us to the first phase, i.e. Analysis.
Phase 1 – Analysis
This is where the whole story begins. Analysis is the process of understanding the customer’s
requirement and mapping it to the use cases. The most essential requirement of this phase is
effective communication, however this fact is normally ignored. It must be understood that
not all people are good at everything. Allocating the brightest brain in the organization for the
Requirement Analysis may not be the best idea. By communicate effectively I mean a person
who can give a patient listening rather than showing his oratory skills and of course one who
is experienced in doing such kind of a job.
Phase 2 – Design
Once the foundation is laid with good use cases, it’s not that difficult a task to design the
system. However one must keep in mind to use the best tools available for creating the
software model. It is wise not to architect something new and venture into unseen territory to
prove one’s designing skills, rather than use accepted models and architecture, which have
matured over the years. Putting one’s designing prowess to test is best done with personal or
open-source projects. Following the standards of designing will always result in a stable
model.
Phase 3 – Construction
Again as the skills of developers vary, the only way we can get good consistent code is by
following high class coding and documentation standards. A good practice is to have an
independent Code Reviewer, who is well versed with the coding and documentation
standards, and who will do the review as the programs are being written so that the
developers will not run a mock with their code with the attitude that ‘It will be done later’.
This actually never happens. Once a code is written it always stays that way. The other
important implementation during this phase is Unit testing and System testing. It sounds
synonymous but there is a difference between the two, Unit testing is testing the performance
of the methods of a class whereas System testing is the performance of a class when accessed
from another class. This is important at this stage, as a bug is less expensive when found at an
early stage as compared to when found during Functional testing. By implementing these
simple measures, the Quality of software will definitely be enhanced.
Phase 4 – Deployment
One of the most critical steps in the software lifecycle is the deployment process. This is often
a customer's first experience with a product and a bad experience can have lasting effects.
Successful deployment depends on good System design and architecture of the project, which
brings us back to the design phase. It is during the design phase itself deployment
considerations should be kept in mind so that there are no hiccups during deployment.
Phase 5 – Maintenance
This phase will be a breeze if the Analysis, Design, Construction and Deployment have gone
off smoothly. The reason is that the issues to deal with, during this phase, will be considerably
reduced.
There are many software processes formulated over the years, which deal with building
robust and stable software of which the Rational Unified Process (RUP) and the Agile
Unified Process (AUP) are widely used. Extreme Programming is also gaining popularity
these days. No matter which process is being used by the organization, it has to be followed
sincerely without making any exceptions.
Calculating the Project Time
The reason why I had elaborated on the phases of the software development cycle was to
stress upon the fact that whichever method you use for estimating the timeline for a project,
the project will be on schedule if and only if the aforesaid are implemented with sincerity.
Making good time estimations requires a combination of qualities, which are experience,
intuition and good technical skills.
The method I am illustrating is the one by Derek C Ashmore, from his book titled the “The
J2EE Architect’s Handbook”, which states that the approximate time for a project can be
calculated by:
a. The total number of screens multiplied by 2 man-weeks each
b. The total number of External application interfaces multiplied by 4 man-weeks each
c. The total number of Database tables multiplied by 2 man-weeks each
d. The total number of Tables or files updated multiplied by 2 man-weeks each
This will give the base estimate for a single developer. Multiply the base estimate by 2.5 to
include analysis and testing activities for each usecase, lets call this figure as the total estimate
for a single developer. Now for each developer added to the project multiply the total
estimate with 1.20 (As each developer added increases Communication and Management
time, which is also time consumed for the project).
At times when implementing the above strategy, some time estimations for certain modules
of the project may seem a bit too inflated. In these circumstances adjust the assumptions made
in a, b, c, d for those specific modules.
Hope these inputs will be helpful to those interested.