Quoting Mete Kural <[EMAIL PROTECTED]>: > >I am thinking of fliping sides on FormBean as interface, I am now > >leaning against formbeans being an interface. FormBean is a concept > >(properties that map to form elements), plus this idea of XML as a > >FormBean. It could be a List or String or anything. > > XML as a FormBean! That got my attention... > > Say we want to populate customer information where a user can edit it like in > an Excel spreadsheet. If the Action accesses a web service and receives a > SOAP response and some XML objects in the SOAP response, sometimes it is too > much processing to convert XML to Java objects if it is a lot of XML (for > example: If the web service returns a list of 50 customers with detailed > info). In such cases it may make more sense to do an XSLT transformation over > the XML objects and render the form. Any suggestions on how this could be > done in Struts 2.0? >
The key to this, IMHO, is the expression language used to bind a reference to a field (say, in a JSP page) to some underlying data object representing the field's value. One very simple approach would be to teach BeanUtils and PropertyUtils how to treat the "." operator differently when the base object is an Element (from the DOM API) ... it would find a child element with an element name equal to the "property name". This would deal directly with any XML document totally based on elements (as opposed to attributes), in a very simple (and mostly backwards compatible) way, so it could therefore even be implemented in Struts 1.2.x. A more comprehensive (but tied to XML) approach would be to support the use of XPath for referencing elements and attributes in a DOM ... but ideally have a way to access "trees of JavaBeans" using the same search expressions. Tools like commons-jxpath make that pretty easy to do as well. If you can have pluggability in your binding expressions, you can adapt to pretty much any internal data representation. (That's one of the key reasons, for example, that JavaServer Faces supports pluggable VariableResolver and PropertyResolver implementations). > Thanks, > Mete > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
