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.

Feature

Completed

Notes

Maven build

90%

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

Servlet dispatcher

100%

Servlet dispatches to request processing chain

Chain integration

80%

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

Spring integration

60%

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 http://www.mail-archive.com/dev@struts.apache.org/msg11563.html)

Page Flow integration

50%

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

75%

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

100%

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

10%

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

70%

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.

Localization

60%

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

50%

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

80%

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

30%

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

5%

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.

Distribution

20%

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

30%

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.

Configuration

0%

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)