Struts Interview Questions with Answers Page III

From freshersonline.com

Interview Question Home

1. Why does the option tag render selected=selected instead of just selected?

Attribute minimization (that is, specifying an attribute with no value) is a place where HTML violates standard XML syntax rules. This matters a lot for

people writing to browsers that support XHTML, where doing so makes the page invalid.It's much better for Struts to use the expanded syntax, which works

the same on existing browsers interpreting HTML, and newer browsers that expect XHTML-compliant syntax. Struts is following the behavior recommended by the

XHTML specification

2. Do I have to use JSPs with my application?

The short answer to this question is: No, you are not limited to JavaServer Pages.

The longer answer is that you can use any type of presentation technology which can be returned by a web server or Java container. The list includes but is

not limited to:

• JavaServer Pages,

• HTML pages,

• WML files,

• Java servlets,

• Velocity templates, and

• XML/XLST

Some people even mix and match apparently unrelated technologies, like PHP, into the same web application.

3. Do ActionForms have to be true JavaBeans?

ActionForms are added to a servlet scope (session or request) as beans. What this means is that, for certain functionality to be available, your

ActionForms will have to follow a few simple rules.

First, your ActionForm bean must have a zero-arguments constructor. This is required because Struts must be able to dynamically create new instances of

your form bean class, while knowing only the class name. This is not an onerous restriction, however, because Struts will also populate your form bean's

properties (from the request parameters) for you.

Second, the fields of your form bean are made available to the framework by supplying public getter and setter methods that follow the naming design

patterns described in the JavaBeans Specification. For most users, that means using the following idiom for each of your form bean's properties:

private {type} fieldName;

public {type} getFieldName() {

return (this.fieldName);

}

public void setFieldName({type} fieldName) {

this.fieldName = fieldName;

}

NOTE - you MUST obey the capitalization conventions shown above for your ActionForm properties to be recognized. The property name in this example is

"fieldName", and that must also be the name of the input field that corresponds to this property. A bean property may have a "getter" method and a

"setter" method (in a form bean, it is typical to have both) whose name starts with "get" or "set", followed by the property name with the first

character capitalized. (For boolean properties, it is also legal to use "is" instead of "get" as the prefix for the getter method.)

Advanced JavaBeans users will know that you can tell the system you want to use different names for the getter and setter methods, by using a

java.beans.BeanInfo class associated with your form bean. Normally, however, it is much more convenient to follow the standard conventions.

WARNING - developers might be tempted to use one of the following techniques, but any of them will cause your property not to be recognized by the

JavaBeans introspection facilities, and therefore cause your applications to misbehave:

• Using getter and setter method names that do not match - if you have a getFoo() method for your getter, but a setBar() method for your setter, Java

will not recognize these methods as referring to the same property. Instead, the language will think you have a read-only property named "foo" and a

write-only property named "bar".

• Using more than one setter method with the same name - The Java language lets you "overload" methods, as long as the argument types are different. For

example, you could have a setStartDate(java.util.Date date) method and a setStartDate(String date) method in the same class, and the compiled code would

know which method to call based on the parameter type being passed. However, doing this for form bean properties will prevent Java from recognizing that

you have a "startDate" property at all.

There are other rules to follow if you want other features of your form beans to be exposed. These include indexed attributes and mapped attributes. They

are covered in detail in other areas of the Struts documentation, in particular: indexedprops.html

For a complete explanation of what a JavaBean is, and everything it can do, see the JavaBeans Specification (version 1.01) at:

http://java.sun.com/products/javabeans/docs/beans.101.pdf

4. Do I have to have a separate ActionForm bean for every HTML form?

This is an interesting question. As a newbie, it is a good practice to create a new ActionForm for each action sequence. You can use DynaActionForms to

help reduce the effort required, or use the code generation facilities of your IDE.

Some issues to keep in mind regarding reuse of form beans are as follows:

• Validation - You might need to use different validation rules depending upon the action that is currently being executed.

• Persistence - Be careful that a form populated in one action is not unexpectedly reused in a different action. Multiple entries in struts-config.xml

for the same ActionForm subclass can help (especially if you store your form beans in session scope). Alternatively, storing form beans in request scope

can avoid unexpected interactions (as well as reduce the memory footprint of your application, because no server-side objects will need to be saved in

between requests.

• Checkboxes - If you do as recommended and reset your boolean properties (for fields presented as checkboxes), and the page you are currently displaying

does not have a checkbox for every boolean property on the form bean, the undisplayed boolean properties will always appear to have a false value.

• Workflow - The most common need for form bean reuse is workflow. Out of the box, Struts has limited support for workflow, but a common pattern is to

use a single form bean with all of the properties for all of the pages of a workflow. You will need a good understanding of the environment (ActionForms,

Actions, etc.) prior to being able to put together a smooth workflow environment using a single form bean.

As you get more comfortable, there are a few shortcuts you can take in order to reuse your ActionForm beans. Most of these shortcuts depend on how you

have chosen to implement your Action / ActionForm combinations.

5. How can I prepopulate a form?

The simplest way to prepopulate a form is to have an Action whose sole purpose is to populate an ActionForm and forward to the servlet or JSP to render

that form back to the client. A separate Action would then be use to process the submitted form fields, by declaring an instance of the same form bean

name.

The struts-example example application that is shipped with Struts illustrates this design pattern nicely. Note the following definitions from the

struts-config.xml file:

...

<form-beans> ...

<-- Registration form bean -->

<form-bean name="registrationForm"

type="org.apache.struts.webapp.example.RegistrationForm"/>

...

</form-beans>

...

<action-mappings>

...

<-- Edit user registration -->

<action path="/editRegistration"

type="org.apache.struts.webapp.example.EditRegistrationAction"

name="registrationForm"

scope="request"

validate="false"/>

...

<-- Save user registration -->

<action path="/saveRegistration"

type="org.apache.struts.webapp.example.SaveRegistrationAction"

name="registrationForm"

input="registration"

scope="request"/>

...

</action-mappings>

Note the following features of this approach:

• Both the /editRegistration and /saveRegistration actions use the same form bean.

• When the /editRegistration action is entered, Struts will have pre-created an empty form bean instance, and passed it to the execute() method. The

setup action is free to preconfigure the values that will be displayed when the form is rendered, simply by setting the corresponding form bean

properties.

• When the setup action completes configuring the properties of the form bean, it should return an ActionForm that points at the page which will display

this form. If you are using the Struts JSP tag library, the action attribute on your <html:form> tag will be set to /saveRegistration in order for the

form to be submitted to the processing action.

• Note that the setup action (/editRegistration) turns off validation on the form that is being set up. You will normally want to include this attribute

in the configuration of your setup actions, because you are not planning to actually process the results -- you simply want to take advantage of the fact

that Struts will precreate a form bean instance of the correct class for you.

• The processing action (/saveRegistration), on the other hand, leaves out the validate attribute, which defaults to true. This tells Struts to perform

the validations associated with this form bean before invoking the processing action at all. If any validation errors have occurred, Struts will forward

back to your input page (technically, it forwards back to an ActionForward named "registration" in this case, because the example webapp uses the

inputForward attribute in the element -- see the documentation describing struts-config.xml for more information) instead of calling your processing

action.

6. Can I have an Action without a form?

Yes. If your Action does not need any data and it does not need to make any data available to the view or controller component that it forwards to, it

doesn't need a form. A good example of an Action with no ActionForm is the LogoffAction in the struts example application:

<action path="/logoff"

type="org.apache.struts.webapp.example.LogoffAction">

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

</action>

This action needs no data other than the user's session, which it can get from the Request, and it doesn't need to prepare any view elements for display,

so it does not need a form.

However, you cannot use the <html:form> tag without an ActionForm. Even if you want to use the <html:form> tag with a simple Action that does not require

input, the tag will expect you to use some type of ActionForm, even if it is an empty subclass without any properties.

7. When is the best time to validate input?

This is an excellent question. Let's step back a second and think about a typical mid to large size application. If we start from the back end and work

toward the view we have:

1) Database: Most modern databases are going to validate for required fields, duplicate records, security constraints, etc.

2) Business Logic: Here you are going to check for valid data relationships and things that make sense for the particular problem you are tiring to

solve.

... This is where struts comes into the picture, by now the system should be pretty well bulletproof. What we are going to do is make validation

friendlier and informative. Remember it is OK to have duplicate validations...

3) ActionErrors validate(ActionMapping map, HttpServletRequest req) is where you can do your validation and feed back to the view, information required

to correct any errors. validate is run after the form has been reset and after the ActionForm properties have been set from corresponding view based

input. Also remember you can turn validation off with validate="false" in the action mapping in the struts-config.xml. This is done by returning an

ActionErrors collection with messages from your ApplicationResources.properties file.

Here you have access to the request so you can see what kinds of action is being requested to fine tune your validations. The <html:error> tag allows you

to dump all errors on your page or a particular error associated with a particular property. The input attribute of the struts-config.xml action allows

you to send validation errors to a particular jsp / html / tile page.

4) You can have the system perform low level validations and client side feedback using a ValidatorForm or its derivatives. This will generate javascript

and give instant feedback to the user for simple data entry errors. You code your validations in the validator-rules.xml file. A working knowledge of

regular expressions is necessary to use this feature effectively.

8. How can I avoid validating a form before data is entered?

The simplest way is to have two actions. The first one has the job of setting the form data, i.e. a blank registration screen. The second action in our

writes the registration data to the database. Struts would take care of invoking the validation and returning the user to the correct screen if

validation was not complete.

The EditRegistration action in the struts example application illustrates this:

< action path="/editRegistration">

type="org.apache.struts.webapp.example.EditRegistrationAction"

attribute="registrationForm"

scope="request"

validate="false">

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

</action>

When the /editRegistration action is invoked, a registrationForm is created and added to the request, but its validate method is not called. The default

value of the validate attribute is true, so if you do not want an action to trigger form validation, you need to remember to add this attribute and set

it to false.

9. Dynamic pages using struts

Is it possible to create the elements of a page(jsp) dynamically based on the results of a data base query, when using struts framework?

If you are talking about rendering a report, then sure. The Action iteracts with the business layer/data access objects to acquire the data, and then

passes it to the presentation page bundled up as a JavaBean or a collection of JavaBeans. The JSP tags (and other systems) all use reflection, so you can

use whatever JavaBean you like.

If you are talking about creating a dynamic data-entry form, then "not so much".

Struts 1.1 supports map-backed ActionForms, but the page still needs to know what input fields are going to be needed. For a truly dynamic input form, I

guess the key would be some type of tag that took a map and then generated a column of input fields. (Wouldn't work for everyone, since a lot of forms

must be designed just so.) For extra credit, the entry names could (optionally) be resource keys that were used to find the label text.

Text fields would be easy. Others would need some type of JavaBean with properties to tell the tag what to output. A bit of work, but obviously doable.

Of course, you'd probably want to validate the form before passing it back to the database. I imagine it's possible to use the validator in a

non-declarative way, but I don't know anyone whose doing that. If you can do a db query to get the information about the form, I imagine you could also

do a query to get the information about validations for the form. It would probably be easier to write your own engine than adopt the validator. (It's

not really that complicated to do.)

People often ask about "dynamic input forms", but most of us just can't get our head around the use case. It's hard to understand what you do with the

dynamic data when it comes back. Most application don't allow you to input or update an arbitrary (e.g. dynamic) set of fields.

10. What's the best way to deal with migrating a large application from Struts to JSF? Is there any tool support that can help?

Answer: This is a complicated task depending on your Struts application. Because the two frameworks have different goals, there are some challenges.

Migrate your response pages first. Keep the Struts controller and place and forward to JSF pages. Then you can configure Struts forwards to go through

the Faces servlet. Consider looking at the Struts-Faces framework from Apache. See the framework chapter in JSF in Action.

11. Declarative Exception Handling

If you have developed web applications long enough, you will realize a recurring pattern emerges: when the backend (e.g. the EJB tier) throws you an

exception, you nearly always need to display an error page corresponding to the type of that exception. Sooner or later, you will come up with a

mechanism to use a lookup table (e.g. an HashMap) to lookup an error page from the exception class.

Struts 1.1 now provides a similar but more powerful mechanism to declare exception handling. In Struts 1.1, you can declare in the struts-config.xml the

associations between an exception class and an exception handler. Using the default exception handler included in Struts, you can also specify the path

of the error pages. With this information, Struts will automatically forward to the specified pages when an uncaught exception is thrown from an Action.

Like other facilities in Struts, the exception handlers are pluggable. You can write and define your own handler classes if needed.

12. Can you compare the advantages and disadvantages of JSF vs. Struts ?

This is a very popular question these days. In general, JSF is still fairly new and will take time to fully mature. However, I see JSF being able to

accomplish everything Struts can, plus more. Struts evolved out of necessity. It was created by developers who were tired of coding the same logic again

and again. JSF emerged both from necessity and competition.

Struts has several benefits:

• Struts is a mature and proven framework. It has been around for a few years and deployed successfully on many projects. The WebSphere Application

Server admin console is a Struts application.

• Struts uses the Front Controller and Command patterns and can handle sophisticated controller logic.

• In addition to the core controller function, it has many add-on benefits such as layouts with Tiles, declarative exception handling, and

internationalization.

There are disadvantages:

• Struts is very JSP-centric and takes other frameworks to adapt to other view technologies.

• Although Struts has a rich tag library, it is still geared towards helping the controller aspect of development and does not give a sense that you are

dealing with components on a page. Therefore, it is not as toolable from a view perspective.

• Struts requires knowledge of Java™. Its goal was to aid Java developers, but not to hide Java. It does not hide details of the Java language to Web

developers that well.

• ActionForms are linked programmatically to the Struts framework. Therefore, to decouple the model, you need to write transfer code or use utilities to

move data from Action Forms to the Model on input.

JSF is an evolution of a few frameworks, including Struts. The creator of Struts, Craig McClanahan, is one of the JSF specification leads. Therefore, it

is not by accident to see some overlap between Struts and JSF. However, one of JSF's major goals is to help J2EE Web applications to be easily developed

using RAD tools. As such, it introduces a rich component model. JSF has several advantages:

• JSF is a specification from Sun® and will be included in future versions of the J2EE specification. All major vendors are pledging strong support for

JSF.

• JSF uses the Page Controller Pattern and therefore aids in Page rich applications. Components can respond to event from components on a page.

• JSF has a well-defined request lifecycle allowing for plugability at different levels.

• One powerful example of plugability is building your own render toolkit. The ability to separate the rendering portion from the controller portion of

the framework allows for wonderful opportunities of extensibility. Component providers can write their own toolkits to render different markup languages,

such as XML or WML. In addition, the render toolkit is not tied to JSP.

• Because JSF has a rich component model, it favors a RAD style of development. I can now build my Web pages using drag and drop technology. In addition,

JSF gives me a way to link visual components to back model components without breaking the layering.

JSF has disadvantages:

• JSF is still quite new and evolving. It will take some time to see successful deployments and wide usage. In addition, as vendors write components,

they may not do everything you want them to.

• JSF by hand is not easier than Struts. Its goal was more oriented to RAD. Those who prefer to do things by hand (for example, the vi type guy who does

not like IDEs) may find Struts easier to develop.

• Struts navigation may be a bit more flexible and adhere to more complex controller logic.

13. Both JSF and Struts will continue to exist for a while ?

Both JSF and Struts will continue to exist for a while. The Struts community is aware of JSF and is positioning itself to have strong support for JSF.

See What about JSTL and JavaServer faces?

From a tools perspective, if you look at the support for JSF versus Struts in WebSphere Studio, the Struts tools are focused around the controller

aspects. The Web Diagram editor helps build your Struts configuration and the wizards/editors build Struts artifacts. The JSF tools are geared towards

building pages, and in essence, hide the JSF framework from you. Expect WebSphere Studio to support both frameworks for a while. As JSF matures, expect

to see some of the controller aspects in JSF to become toolable.

14. Multiple Sub-applications

One of the shortcomings in Struts 1.0 is manageability of the configuration file (commonly known as struts-config.xml) when the development of the

application involves a sizable team. This problem arises because a Struts-based application must run under one controller servlet, the ActionServlet, and

the ActionServlet can use only one struts-config.xml. It is not an issue when the project is relatively small and the team consists of a couple of

developers; however, when the project size becomes significant and the project involves a large number of developers, maintaining all the mapping

information in a single file becomes increasingly problematic.Struts 1.1 solves this problem nicely by introducing multiple sub-applications. In Struts

1.1, each sub-application has its own struts-config.xml file. A large Struts-based application can thus be easily partitioned into largely independent

modules, i.e. sub-applications, and each sub-team can maintain their struts-config.xml independently.The sub-application scheme is a natural extension of

the servlet context mapping scheme of the URI paths used by servlet containers. According to the Servlet standard, when the servlet container receives a

request with a URL, the servlet container will try to match the prefix of the URI path to a deployed web-application in the container. What Struts 1.1

does is it maps the second prefix of the path to a sub-application. In effect, this prefix mapping scheme creates another level of namespace for each

sub-application. For example, for the URI,http://some-host.com/myApp/module2/editSubscription.do/myApp is the context path for a web-application called

"myApp" and /module2 is the sub-app prefix for a Struts sub-application called "module2".

15. DynaBean and BeanUtils

Another major complaint usually heard amongst Struts 1.0 users is the extensive effort involved in writing the FormBean (a.k.a. ActionForm) classes.

Struts provides two-way automatic population between HTML forms and Java objects, the FormBeans. To take advantage of this however, you have to write one

FormBean per HTML form. (In some use cases, a FormBean can actually be shared between multiple HTML forms. But those are specific cases.) Struts'

FormBean standard follows faithfully the verbose JavaBean standard to define and access properties. Besides, to encourage a maintainable architecture,

Struts enforces a pattern such that it is very difficult to 'reuse' a model-layer object (e.g. a ValueObject from the EJB tier) as a FormBean. Combining

all these factors, a developer has to spend a significant amount of time to write tedious getters/setters for all the FormBean classes.

Struts 1.1 offers an alternative, Dynamic ActionForms, which are based on DynaBeans. Simply put, DynaBeans are type-safe name-value pairs (think

HashMaps) but behave like normal JavaBeans with the help of the BeanUtils library. (Both the DynaBeans and the BeanUtils library were found to be useful

and generic enough that they have been 'promoted' into Jakarta's Commons project.) With Dynamic ActionForms, instead of coding the tedious

setters/getters, developers can declare the required properties in the struts-config.xml files. Struts will instantiate and initialize Dynamic ActionForm

objects with the appropriate metadata. From then onwards, The Dynamic ActionForm instance is treated as if it is an ordinary JavaBean by Struts and the

BeanUtils library.

16. Validator

The Validator is not exactly a new feature. The Validator has been in the contrib package in the distribution since Struts 1.0.1. Since then, part of it

has now been refactored and moved into the Jakarta-Commons subproject and renamed the Commons-Validator and the Struts specific portion is now called the

Struts-Validator. However, since it is in the contrib package, people may overlook it and it is worthwhile to mention it here.

The Validator provides an extensible framework to define validation rules to validate user inputs in forms. What is appealing in the Validator is that it

generates both the server-side validation code and the client-side validation code (i.e. Javascript) from the same set of validation rules defined in an

XML configuration file. The Validator performs the validation based on regular-expression pattern matching. While a handful of commonly used validators

are shipped with the framework (e.g. date validator, range validator), you can always define your own ones to suit your need.

17. Default Sub-application

To maintain backward compatibility, Struts 1.1 allows one default sub-application per application. The URI of the resources (i.e. JSPs, HTMLs, etc) in

the default sub-application will have an empty sub-app prefix. This means when an existing 1.0 application is "dropped" into Struts 1.1, theoretically,

it will automatically become the default sub-application.

18. Direct Requests to JSPs

To take the full advantage of sub-application support, Struts 1.1 stipulates the requirement that all requests must flow through the controller servlet,

i.e. the ActionServlet. Effectively, this means all JSPs must be fronted by Actions. Instead of allowing direct requests to any of the JSPs, all requests

must go through an Action and let the Action forward to the appropriate JSP.

This is perhaps the biggest impact of migration to Struts 1.1 if you have not followed this idiom in your applications. This restriction is required

because without going through the ActionServlet, Struts navigation taglibs (e.g. <html:form> and <html:link>) used in the JSPs will not have the correct

sub-app context to work with.

19. ActionServlet Configurations

With the introduction of sub-applications, a more flexible way is introduced to configure each sub-application independently. Many of the configuration

entries (e.g. resource bundle location, maximum upload file size, etc) that used to be defined in web.xml have now been moved to struts-config.xml. The

original entries in web.xml are deprecated but will still be effective.

20. Action.execute() and Action.getResources()

In Struts 1.0, request handling logic is coded in Action.perform(); however, Action.perform() throws only IOException and SevletException. To facilitate

the new declarative exception handling , the request handling method needs to throw Exception, the superclass of all the checked exceptions. Therefore,

to both maintain backward compatibility and facilitate declarative exception handling, Action.perform() is now deprecated in favour of Action.execute().

You also have to be careful if you use DispatchAction in your existing applications. At the time of writing, the DispatchAction in Struts 1.1 beta has

not yet been updated to use execute(). (A bug report has been filed in Struts' bug database.) Therefore, without modifying the DispatchAction class

yourself, declarative exception handling will not work with DispatchAction subclasses.

In addition, Action.getResources() is now deprecated. Instead, you should call Action.getResources(HttpServletRequest) instead. This allows Struts to

return to you the sub-application specific message resources. Otherwise, the message resources for the default sub-app will be used.

21. Library Dependency

Struts 1.1 now depends on a handful of libraries from other Jakarta subprojects (e.g. Commons-Logging, Commons-Collections, etc.). Some of these

libraries may cause classloading conflicts in some servlet containers. So far, people have reported in the mailing list the classloading problem of

commons-digester/jaxp1.1, and commons-logging causing deployment difficulties in Struts 1.1 applications running on Weblogic 6.0. (The problems have been

corrected in Weblogic 6.1 and 7.0.)

22. Resources under WEB-INF

According to the Servlet specification, resources (e.g. JSP files) stored under WEB-INF are protected and cannot be accessed directly by the browsers.

One design idiom for Struts 1.0 is to put all the JSP files under WEB-INF and front them by Actions so that clients cannot illegally access the JSPs.

With the introduction of sub-application prefixes in Struts 1.1, mapping resources under WEB-INF gets complicated. Extra configuration steps utilizing

the pagePattern and forwardPattern attributes of the element in struts-config.xml is required to inform Struts to construct the paths correctly. More

specifically, you need to set these attributes to the pattern "/WEB-INF/$A$P".

23. What is the Jakarta Struts Framework?

Jakarta Struts is an open source implementation of MVC

(Model-View-Controller) pattern for the development of web based applications.

Jakarta Struts is a robust architecture and can be used for the development of applications of any size.

The “Struts framework” makes it easier to design scalable, reliable Web applications.

24. What is an ActionServlet?

The class org.apache.struts.action.ActionServlet is called the ActionServlet.

In the Jakarta Struts Framework this class plays the role of controller.

All the requests to the server go through the “Controller”.

The “Controller” is responsible for handling all the requests.

25. How can one make any “Message Resources” definitions file available to the “Struts Framework” environment?

Answer: “Message Resources” definitions file are simple .properties files and

these files contain the messages that can be used in the struts project.

“Message Resources” definition files can be added to the struts-config.xml file

through <message-resources /> tag. Example:

<message-resources parameter="MessageResources" />

26. What is an “Action Class”?

The “Action Class” is part of the “Model” and is a wrapper around the business logic.

The purpose of the “Action Class” is to translate the HttpServletRequest to the business logic.

To use the “Action”, we need to subclass and overwrite the execute() method.

All the database and business processing is done in the “Action” class.

It is advisable to perform all the database related work in the “Action” class.

The ActionServlet (command) passes the parameterized class to ActionForm using the execute() method.

The return type of the execute method is ActionForward which is used by the Struts Framework to forward the request to the file according to the value of

the returned ActionForward object.

27. Write code of any Action Class?

Here is the code of Action Class that returns the ActionForward object.

package j2eeonline.jdj.com;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import org.apache.struts.action.Action;

import org.apache.struts.action.ActionForm;

import org.apache.struts.action.ActionForward;

import org.apache.struts.action.ActionMapping;

public class TestAction extends Action{

public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request,

HttpServletResponse response) throws Exception{

return mapping.findForward("testAction");

}

}

28. What is an “ActionForm”?

An “ActionForm” is a JavaBean that extends org.apache.struts.action.ActionForm.

ActionForm maintains the session state for web application and the “ActionForm” object is automatically populated on the server side with data entered

from a form on the client side.

29. What is Struts Validator Framework?

The “Struts Framework” provides the functionality to validate the form data.

It can be used to validate the data in the user’s browser as well as on the server side.

Struts Framework checks the JavaScript code and it can be used to validate the form data on the client browser.

Server side validation of form data can be accomplished by subclassing your “form” Bean with DynaValidatorForm class.

The “Validator” framework was developed by David Winterfeldt as a third-party “add-on” to Struts.

Now the Validator framework is part of the “Jakarta Commons” project and it can be used with or without Struts.

The Validator framework comes integrated with the Struts Framework and

can be used without any making any additional settings.

30. Describe the details of XML files used in the “Validator Framework”?

The Validator Framework uses two XML configuration files

1) validator-rules.xml and

2) validation.xml.

The validator-rules.xml defines the standard validation routines.

These are reusable and used in validation.xml to define the form specific validations.

The validation.xml defines the validations applied to a form bean.