I have been working with Struts and am very impressed. But it seems to me that for Struts to be competitive with XML/XSL-based designs from a usability perspective, it eventually needs to do a few of their more popular tricks. I'm not sure if these are tooling or platform issues, but I would love to hear people's opinions on this subject. I looked around a bit (e.g. I read the threads on ActionForm generation via XSLT, CodeMaker; etc.) before posting, so hopefully these are not moot points. Hopefully struts-user is also the right place for this discussion. Anyway, thanks for any comments you may have...
Document generation: In Struts, one has to create an ActionForm bean to represent a document schema. Not a problem for me, but potentially a problem if I'm trying to put together a development environment for the average HTML hack. I've seen several tools that allow generation of form beans from JSPs or XML instance data (like CodeMaker), but nothing yet that uses a DTD or XML Schema as the source. In an enterprise app development scenario, it seems likely that the document will often be pre-defined and the page designer will need to work from that, rather than automatically generating the document from the page design. Therefore, support for the prevailing document schema standards (DTD, XSD) seems key. The closest options I've found are the various data binding solutions out there (JAXB, Castor, and some various IBM tools), but I didn't see a way to generate *ActionForm* beans from them -- for example, Castor will allow generation of beans from XSD, but things like the signature of the validate() method don't entirely match those in ActionForm. I didn't see an easy way in any of these tools to sufficiently customize the output, beyond things like superclass and package name. If one has to manually alter or wrap the generated bean, it probably defeats the purpose (namely, automation and convenience). Has anyone tried using JAXB or Castor to generate their ActionForm beans? Anyone been successful? Manipulation of complex documents: On a related note... with XML it is easy to describe a complex, hierarchical document, and with XSL it is easy to render this document as HTML. But in Struts, it seems that the forms -- and accompanying tools like the Struts taglibs -- are geared toward simpler, flatter documents. If there were an easy way for page designers to control the display of complex documents and the generation of forms from them, it would go a long way toward Struts being utilized in industrial-grade forms scenarios (like RFQs, purchase orders, etc.). For example, if my document (originally derived from an XSD) contains an optional repeating element group, how can a developer easily represent that capability on a Struts page? Ideally they would want a taglib that automatically provides an HTML link that, when clicked, adds the new optional element group to the document instance and redraws the form to include its contained fields. Do these issues seem relevant? If so, has anyone had any luck addressing them within the Struts framework? regards, --Steve
