Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.
The following page has been changed by RichFeit: http://wiki.apache.org/struts/StrutsTi/StatusMatrix The comment on the change is: Some status updates after the annotation/xdoclet patch that Don applied. ------------------------------------------------------------------------------ ||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||0%||The Beehive annotation processing layer has yet to be brought over to Ti. This layer would generate Page Flow, XWork, and XWork validation XML files from Controller annotations.|| - ||XJavadoc support for Java 1.4||20%||Some work has gone into generating XWork and XWork validation XML from controller tags, although this will radically change when the tag processing layer from Beehive is ported.|| + ||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., [EMAIL PROTECTED]).|| + ||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. 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.|| + ||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||10%||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.|| + ||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%||Rich contributed working examples that demonstrate an application that uses Page Flow controllers. These examples don't do any tag processing so are not easy to modify. Also, we need more examples to show off other features like JSF integration.|| + ||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 Reloadable``Class``Handler needs to delegate to XWork's Object``Factory, and that to initialize the XWork Compiling``Object``Factory we need to set a Java``Compiler that processes annotations, and a Compilation``Problem``Handler that displays annotation errors to the user.|| --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
