There is overlap between Struts Taglib and the JavaServer Standard Tag Library (JSTL). To make the best use of JSTL, use the Struts EL component instead.

Struts 1 is not the best choice if you'd like to use JavaServer Faces components in your application. The Struts Faces component provides some interoperability with JSF, but Faces is really only intended as a stop gap for teams experimenting with JSF.

For better JavaServer Faces support, consider using Struts 2 or Apache Shale.

If you use an <html:html xhtml="true> or <html:xhtml/> element on your page, the tags will render as XHTML (since version 1.1).

The framework itself is markup neutral. The original Struts taglibs are only one example of how presentation layer components can access the framework. The framework objects are exposed through the standard application, session, and request contexts, where any Java component in the application can make use of them.

Markup extensions that use the framework are available for Velocity and XLST, among others. A new Struts tag library for Java Server Faces is also in development.

For more about using WAP/WML with Struts see the article WAP up your EAserver.

Yes. Define the element as an array and the framework 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

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.

One popular approach is to use a 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 <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.

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

Another approach is to use a separate JavaScript that automatically focusses the first enabled field on the first form on a page. See the article Set Focus to First Input on Web Page for a working example that you can use in your own applications.

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

You can submit a form with a link as below. BTW, the examples below assume you are in an <html:form> block and 'myForm' is picked up from the struts-config.xml name field of the action.

Now the trick in the action is to decode what action you intend to perform. Since you are using JavaScript, you could set a field value and look for it in the request or in the form.

... html/javascript part ...

... the java part ...

This is just one of many ways to achieve submitting a form and decoding the intended action. Once you get used to the framework you will find other ways that make more sense for your coding style and requirements. Just remember this example is completely non-functional without JavaScript.

Here is a link which utilizes the LookupDispatch action to submit forms with multiple actions without javascript: http://husted.com/struts/tips/003.html

The framework is mainly a server-side technology. We bundled in some JSP tags to expose the framework components to your presentation page, but past that, the usual development process applies.

Interactive pages require the use of JavaScript. (That's why it was invented.) If you want things popping up or doing this when they click that, you are outside the scope of the framework and back into the web development mainstream.

You use JavaScript with the framework the same way you use with any presentation page. Since JavaScript is a client-side technology, you can use simple relative references to your scripts. If you need to fire a JavaScript from a HTML control, the Struts HTML tags have properties for the JavaScript events.

A very good JavaScript resource is Matt Kruse's site at http://www.mattkruse.com/javascript/

No. You need to set checkbox properties to false if the ActionForm is being retained in session scope. This is because an unchecked box does not submit an attribute. Only checked boxes submit attributes. If the form is in session scope, and the checkbox was checked, there is no way to turn it back off without the reset method. Resetting the properties for other controls, or for a request scope form, is pointless. If the form is in request scope, everything already just started at the initial value.

The framework 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 framework application does go against the grain. The approach recommended by most 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 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.

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.

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

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

For more flexible placement of error messages, try the <html2> Tag Library for Struts.

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.

Another very popular tag library is DisplayTag. . DisplayTag is an excellent choice when you have tabular data to present.

• Why do my option lists disappear when validation fails?
• Why can't I disable URL-encoding in the Struts taglibs?