Struts Interview Questions And Answers_3

[ganeshbala]

Struts Interview Questions And Answers

Why do the Struts tags provide for so little formatting?

The Struts tags seem to provide only the most rudimentary functionality. Why is there not better support for date formatting and advanced string handling?
Three reasons:
First, work started on the JSTL and we didn't want to duplicate the effort.
Second, work started on Java Server Faces, and we didn't want to duplicate that effort either.
Third, in a Model 2 application, most of the formatting can be handled in the ActionForms (or in the business tier), so all the tag has to do is spit out a string. This leads to better reuse since the same "how to format" code does not need to be repeated in every instance. You can "say it once" in a JavaBean and be done with it. Why don't the Struts taglibs offer more layout options?
Since the Struts tags are open source, you can extend them to provide whatever additional formatting you may need. If you are interested in a pre-written taglib that offers more layout options, see the struts-layout taglib.
In the same arena, there is a well regarded contributor taglib that can help you create Menus for your Struts applications.

Why does the <html:link> tag URL-encode javascript and mailto links?

The <html:link> tag is not intended for use with client-side references like those used to launch Javascripts or email clients. The purpose of link tag is to interject the context (or module) path into the URI so that your server-side links are not dependent on your context (or module) name. It also encodes the link, as needed, to maintain the client's session on the server. Neither feature applies to client-side links, so there is no reason to use the <html:link> tag. Simply markup the client-side links using the standard tag.

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

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.

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