This a snapshot of Struts Ti current status. Please feel free to modify these entries, or add new ones. At this stage, the feature list for Struts Ti is open for full discussion.




Maven build


Maven builds for the jars and example wars works thanks to James

Servlet dispatcher


Servlet dispatches to request processing chain

Chain integration


Commons chains include init chain, request processing chain, action invocation chain. Need exception handling chain?

Spring integration


Spring used to load environment-specific implementations of services. For example, a ServletActionMapper instance of the ActionMapper interface. More work needed to better load/locale bean factory (see

Page Flow integration


Rich has done the bulk of the work porting Ti to page flow. We need to shore up better XWork integration including l18n support and validation.

Annotation processing


The Beehive annotation processing layer has been ported to Ti. This layer generates XWork configuration files from annotations in controller classes. Assuming we want to move off of Commons Validator and onto XWork validation, we still need to get it to generate the right config for XWork based on validation annotations (e.g., @ti.validateMinLength).

XJavadoc support for Java 1.4


XDoclet tags can now be used in place of annotations, for running against Java 1.4. The tags are the same as the Java 5 annotations, but in XDoclet format (in JavaDoc comments, without the nasty Java 5 syntax (commas, parens, braces). See wars/samples-xdoclet for an example. I put this one at 100%, since changes to the annotation processing layer (e.g., to support XWork validation) will work underneath the XDoclet layer.

Validation support


The non-Page Flow aware controller has support for XWork-style validation, however this will change when integrated with Page Flow, which currently generates Commons Validator config files. At issue is the use of XWork validation interceptors which apply validations to the Value Stack. For multiple reasons, we may want to move away from the general Value Stack approach of WebWork/XWork so we'd have to write our own interface to their validation. Whatever our end story is, we should support (?) varying sets of validation rules per-locale, as Validator does.

Form Bean support


Since multiple actions will share a controller class, it makes sense to continue to use form beans as a way to define input properties per action. These form beans could be POJOs, Maps, or perhaps other data type forms, and also should be optional. They should be passed to the action method as a parameter. This works currently, but the guts of it should be integrated with XWork -- currently, form bean processing is done without regard to XWork.



Currently, Ti can use XWork l18n capabilites which allows for global localization files, as well as action-specific files. This may be all we need, time will tell.

Working examples


We have samples that demonstrate using Page Flow controllers, with both Java 5 annotations (wars/samples) and XDoclet tags (wars/samples-xdoclet). There is also a sample that demonstrates JSF integration (wars/samples-jsf). We need to get these samples into a distribution build, with a simple ant script for building each one.

Multiple view support


Thanks to WebWork, we have a whole host of Result implementations to support Velocity, Freemarker, JSP, and XSLT. Rich's Page Flow patch also adds JSF support.

Customized Tag Library


Again thanks to WebWork, we can use their tag library which supports JSP, Velocity, and Freemarker to name a few. In fact, each tag can have its HTML content generated by another template type if desired, so your JSP tag could have its HTML generated by a Velocity template, rather than hard coded into the tag like the Struts tags. Beehive also has a good set of tag libraries we should look at. Whatever we use, we should consider multiple output types in addition to the common JSP.

Porlet support


While the new Ti code and probably the Beehive stuff doesn't depend on Servlets, WebWork does and they supply the Results. Also, there is no spring config for portlets or Portlet dispatcher yet.



James's work in getting us into a legitimate maven build structure already puts us ahead here -- maybe we're farther along. We need to end up with a distribution that includes running samples (with simple ant builds), a blank starter app, docs, etc.

Dev Mode


As Don has described, in Dev Mode you should be able to make changes to annotations in a controller class source file, and simply refresh the browser to see your changes take effect. I think this means that the Page Flow ReloadableClassHandler needs to delegate to XWork's ObjectFactory, and that to initialize the XWork CompilingObjectFactory we need to set a JavaCompiler that processes annotations, and a CompilationProblemHandler that displays annotation errors to the user.



Currently, Page Flow functionality is configured through "ti-config.xml" (read from the classloader), which was simply ported from Beehive's beehive-netui-config.xml. We need some general way to expose framework-wide configuration in Ti (e.g, choosing an expression language or disabling file upload). An XML file like ti-config.xml? Well-known (documented) properties on some Spring bean?

StrutsTi/StatusMatrix (last edited 2009-09-20 23:12:14 by localhost)