Hi, I have an XML file A with some structure. I have a program that uses Castor to read file A and converts it into Java Objects. Now I need to convert file A into another XML file say B with some different structure. What I have thought is to define an interface which will have methods that would return me objects pertaining to XML file B and then use an Adapter class that would implement this interface and invoke and fetch values from the existing class(that returns objects of file A). The client to the adapter will then marshall these objects using Castor that would give me xml file B. Why I plan to do this is because I have more such XML files with some different structures that needs to be converted to structure of file B. So I will write adapters(that will implement the common interface) for all such files. Is this a correct approach? Am I correct in using Adapter pattern here? Or is there a better approach to achieve this?
Thanks for replying Peer. I have nerver used XSLT, but will go through it. There is already an existing code that converts the source XML file to Java objects using Castor, hence I thought of using Adaptor to convert it into objects of the target type and then marshal them to target XML. Also there are two different XML source files that needs to be converted to a single target XML. Can you give me some pointers for good XSLT tutorial or book where I can start reading from. Thanks in advance.
There is already an existing code that converts the source XML file to Java objects using Castor, hence I thought of using Adaptor to convert it into objects of the target type and then marshal them to target XML.
XML is hierarchical; objects are object-oriented. There is an inherent impedance mismatch between both ("Item 43: Recognize the object-hierarchical impedance mismatch" in Effective Enterprise Java: Ch.5: State Management (PDF)) So often it doesn't make sense to force your data twice across the paradigm boundary when both input and output are in the same paradigm (e.g. XML-to-XML conversion). This makes XSLT (possibly extended with Java) the right tool for the job in the majority of cases of XML-to-XML conversion.
If this is one-off code that is only going to be used once and then thrown away then just "do it" completely in Castor but don't worry about patterns. If it is going to stick around a bit longer then you might as well do it right.
Thanks Peer for your invaluable comments. Neglected completely the "impedance mismatch". And sorry for missing out on the links that you provided in your earlier post. I would go through the links that you have provided.
The transformer pulls the objects out of the Reader, collects as many as are necessary and then writes one or a cluster of Style Y objects out to the Writer. In this case we should have most of the code for the XML style A to Style X Object Reader. This list already shows a separation of concerns: Reader is responsible for reconstituting the Style X objects, the Transformer is responsible for transforming objects and the Writer is responsible serializing Style Y Objects. Program to an interface, not an implementation suggests that we design a "Style X Object Reader" interface to be used by the Transformer and to be implemented by the concrete "XML style A to Style X Object Reader" and that we design a "Style Y Object Writer" interface to be used by the Transformer and to be implemented by the concrete "Style X Object to XML style B Writer". The details of these interfaces depend on the actual structure of the object graphs of the Style X and Y Objects. Now repeated application of various relevant OO design principles will guide you during the refinement of your design. In the end you will probably end up with a concrete XmlAObjXReader (implements ObjXReader) which is configured with one or more input files, a concrete ObjYXmlBWriter (implements ObjYWriter) which is configured with one or more output files - both of which are then dependency injected into a concrete ObjXObjYTransformer as ObjXReader and ObjYWriter respectively.
Don't overemphasize object-oriented design patterns - there isn't a pattern for every problem - object-oriented design principles are a much more valuable and a more broadly applicable tool and all OO design patterns are based on object-oriented design principles.
See also this topic: Design Patterns... [ May 06, 2008: Message edited by: Peer Reynders ]