techpreparation-homepage

Home  Interview Questions  Certifications  Aptitude Questions  Tutorials  Placement Papers  Search  Resume  Soft Skills  Video  Forum  Blog

Android app on Google Play

Technical Interview Questions
Oracle Interview Questions
J2EE Interview Questions
C++ Interview Questions
XML Interview Questions
EJB Interview Questions
JSP Interview Questions
                              .........More

Programming Source Codes
Java Source Codes
Html Source Codes
CSS Source Codes
C Source Codes
                              .........More

Soft Skills
Communication Skills
Leadership Skills
                              .........More

 

 

  

Structs Interview Questions and Answers



Why are some of the class and element names counter-intuitive?
The framework grew in the telling and, as it evolved, some of the names drifted.
The good thing about a nightly build, is that everything becomes available to the community as soon as it is written. The bad thing about a nightly build is that things like class names get locked down early and then become difficult to change.

Why is ActionForm a base class rather than an interface?
The MVC design pattern is very simple to understand but much more difficult to live with. You just need this little bit of Business Logic in the View logic or you need just that little bit of View logic in the Business tier and pretty soon you have a real mess.
Making ActionForm a class takes advantage of the single inheritance restriction of Java to it makes it more difficult for people to do things that they should not do.
ActionForms implemented as interfaces encourage making the property types match the underlying business tier instead of Strings, which violates one of the primary purposes for ActionForms in the first place (the ability to reproduce invalid input, which is a fundamental user expectation). ActionForms as an interface would also encourage using existing DAO objects as ActionForms by adding ‘implements ActionForm’ to the class. This violates the MVC design pattern goal of separation of the view and business logic.
Since the goal of struts is to enforce this separation, it just makes more sense for Struts to own the ActionForm.
DynaActionForms relieve developers of maintaining simple ActionForms. For near zero maintenance, try Niall Pemberton's LazyActionForm

Do ActionForms have to be true JavaBeans?
The utilities that Struts uses (Commons-BeanUtils since 1.1) require that ActionForm properties follow the JavaBean patterns for mutators and accessors (get*,set*,is*). Since Struts uses the Introspection API with the ActionForms, some containers may require that all the JavaBean patterns be followed, including declaring "implements Serializable" for each subclass. The safest thing is to review the JavaBean specification and follow all the prescribed patterns.
Since Struts 1.1, you can also use DynaActionForms and mapped-backed forms, which are not true JavaBeans. For more see ActionForm classes in the User Guide and Using Hashmaps with ActionForms in this FAQ.

Can I use multiple HTML form elements with the same name?
Yes. Define the element as an array and Struts will autopopulate it like any other.
private String[] id= {};
public String[] getId() { return this.id; }
public void setItem(String id[]) {this.id = id;}
And so forth

Can I use multiple HTML form elements with the same name?
Yes. The issue is that only one action class can be associated with a single form. So the real issue is how do I decode multiple submit types to a single Action class. There is more than one way to achieve this functionality.
The way that is suggested by struts is right out of the javadoc for LookupDispatchAction . Basically, LookupDispatchAction is using the keys from ApplicationProperties.resources as keys to a map of actions available to your Action class. It uses reflection to decode the request and invoke the proper action. It also takes advantage of the struts <html:submit> tags and is straight forward to implement.
You can roll your own with JavaScript events and javascript:void (document.forms["myform"].submit) on any html element. This gives you control of how you want your page to look. Again you will have to decode the expected action in the execute method of your action form if you choose this route.

Why doesn't the focus feature on the <html:form> tag work in every circumstance?
Unfortunately, there is some disagreement between the various browsers, and different versions of the same browser, as to how the focus can be set. The <html:form> tag provides a quick and easy JavaScript that will set the focus on a form for most versions of most browsers. If this feature doesn't work for you, then you should set the focus using your own JavaScript. The focus feature is a convenient "value-add" -- not a core requirement of the tag. If you do come up with a JavaScript that provides the final solution to this project, please post your patch to this Bugzilla ticket.

Why are my checkboxes not being set from ON to OFF?
A problem with a checkbox is that the browser will only include it in the request when it is checked. If it is not checked, the HTML specification suggests that it not be sent (i.e. omitted from the request). If the value of the checkbox is being persisted, either in a session bean or in the model, a checked box can never unchecked by a HTML form -- because the form can never send a signal to uncheck the box. The application must somehow ascertain that since the element was not sent that the corresponding value is unchecked.
The recommended approach for Struts applications is to use the reset method in the ActionForm to set all properties represented by checkboxes to null or false. The checked boxes submitted by the form will then set those properties to true. The omitted properties will remain false. Another solution is to use radio buttons instead, which always submit a value.
It is important to note that the HTML specification recommends this same behavior whenever a control is not "successful". Any blank element in a HTML form is not guaranteed to submitted. It is therefor very important to set the default values for an ActionForm correctly, and to implement the reset method when the ActionForm might kept in session scope.

Can't I just create some of my JavaBeans in the JSP using a scriptlet?
Struts is designed to encourage a Model 2/MVC architecture. But there is nothing that prevents you from using Model 1 techniques in your JavaServer Pages, so the answer to the question is "Yes, you can".
Though, using Model 1 techniques in a Struts application does go against the grain. The approach recommended by most Struts developers is to create and populate whatever objects the view may need in the Action, and then forward these through the request. Some objects may also be created and stored in the session or context, depending on how they are used.
Likewise, there is nothing to prevent you from using scriptlets along with JSP tags in your pages. Though, many Struts developers report writing very complex scriplet-free applications and recommend the JSP tag approach to others.
For help with Model 1 techniques and scriptlets, you might consider joining the Javasoft JSP-interest mailing list, where there are more people still using these approaches.

Page Numbers :   1       2        3        4        5        6        7        8        9       10        11       12       13       14       15

Have a Question ? post your questions here. It will be answered as soon as possible.

Check Java Interview Questions for more Java Interview Questions with answers

Check Servlet Interview Questions for more Servlet Interview Questions with answers