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 DonBrown: http://wiki.apache.org/struts/StrutsTi/StatusMatrix New page: #format wiki #language en 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||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.|| ||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.|| ||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.|| ||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.|| ||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.|| --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
