A wise old hermit known only as Mathias Bogaert <[EMAIL PROTECTED]> once said:
> Update of /cvsroot/xdoclet/xdoclet/core/resources/xdoclet/ejb > In directory usw-pr-cvs1:/tmp/cvs-serv10031/core/resources/xdoclet/ejb > > Modified Files: > dataobject.j > Log Message: > Added experimental toXml method (remove again if not approved). You may want to check out the postings on "XML Aware Value Objects" on theserverside.com (http://www.theserverside.com/patterns/thread.jsp?thread_id=10431) The impression I was left with was that value objects shouldn't themselves do conversion to XML (or any other format you care to think of), but instead have some other class (marshaller/renderer) that can convert your data object(s) to the format. For one thing, you can add new formats without having to change the data objects. In an ideal world, the same would apply to toString, except that's there anyway from java.lang.Object and it's handy for debug logging. Secondly, should toXml really be returning a string anyway, rather than an org.w3c.dom.Document? It depends on what you plan to do with it subsequently, of course, but most of the uses I can think of in a J2EE application (e.g. applying a JAXP transform to it in your JSPs' associated javabeans) will need to parse it first, which is slow; with a Document you avoid that. In a book I was reading on "J2EE and XML" a month or so ago, things were *always* passed around as Documents - the only time they ever got converted directly to a string was for writing to a text file, any other output was done via an XSL stylesheet. However, if we use e.g. JDOM to build a Document in toXml() it introduces additional library dependencies to the data objects (which is undesirable). If the conversion is done by a separate class, on the other hand, it's that class that has the dependency so only those people using it need the extra libraries. I guess, on the whole, my feeling is that we probably shouldn't have (or don't need) a toXml(); it's worth discussing, though. Comments, people? Andrew. _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
