XML question

Miscellaneous Topics
#1

Maybe even off-topic here, dunno :stuck_out_tongue:

What’s the ‘best’ approach when wanting to be able to write and load objects to XML format? Is it recommended to have a complex MyWriter class that deals with my objects and write them, or should my objects implement a XMLWritable interface, so MyWriter is simpler and rely on the objects to write themselves?

I want to implement this the fastest way possible. Sometimes, the fact that I will have to modify a couple of dozen of objects to implement a certain interface bothers me a bit, and I tend to prefer the centralized version, but again, something tells me that such big complex writer is more error prone and less flexible?

Any hints would be valuable, since I’m not used with XML issues.

Thanks :slight_smile:

#2

You could just make your objects beans, and then use XMLEncoded

#3

Either approach works well. I tend to distribute toElement() methods across classes if there is a stable canonical XML representation for that object. (That can happen, for example, if you’re implementing an object model specifically for some public XML spec.) That is pretty convenient because you can dump into XML just by having the object reference (i.e. without having to get ahold of a converter, which may or may not be a pain). So the distributed approach is just simpler, which is a reason to prefer it absent other considerations.

But if you intend to allow multiple XML representations for the object, it might be better to go with a centralized converter. The reason is that the distributed approach would encourage people to have to modify the original objects every time a new format is introduced, which is not a very scalable model for making such introductions. E.g., you may start out with toApp1Element() and toApp2Element() defined on your object interfaces. Then somebody wants to support some new XML application. While they could create a central converter, the existing toApp1Element() and toApp2Element() might encourage them instead to modify the original classes, which means that you might break clients that depend on the original APIs. (Especially if the original APIs were defined using Java interfaces–you can’t add new interface methods without breaking clients.)

Neither approach in inherently more performant than the other.

Hope that helps.
Willie

#4

Thanks very much!

I’ll problably implement the distributed version though. It’s a small project so it should suffice.

Very helpful comments. If I could give you guys some duke dollars, you would have them :wink:

#5

Hehe, glad the comments were helpful. Here is something else to keep in mind (and it applies no matter which approach you use). Your toElement() method should document the schema you use. (Probably best bet is to define a DTD and then have your Javadocs reference that DTD.) A common mistake I have seen is for developers to treat the toElement() output as if it’s not specified by contract, in the same way that the exact toString() output is not usually specified by contract. (Usually the toString() output is documented as being subject to change.) With toString() it is generally fine, but with XML it is rarely if ever fine. The reason is that the XML consumer almost always depends on the XML conforming to some very specific schema, so changes to the XML will break those consumers. Contrast that with the case of the typical toString() consumer, which is usually just dumping the toString() to System.out (and not parsing the string).

Willie

#6

Will definitely keep that in mind.

As always, a programmer faces many options on how to implement something. That’s why we have design patterns and so on… but what’s the best way to process and object and return its Element representation. I am not sure if it’s best to have a generic toElement method that takes an object, or if I should have specific toElement methods that take specific object instances. I tried to illustrate the situation:

I can do the same thing in two ways.

in my loop writing objects to Xml {

 if( object instanceof ABC ) 
       root.appendChild( ABCToElement( object) );

}

Element ABCToElement(ABC object) {
//…return element after processing
}

OR

in my loop writing objects to Xml {

root.appendChild( toElement(object) );
}

Element toElement(Object object) {
if( object instance ABCToElement)
// process element and return
}

Note that the first example could also benefit from having a toElement(Object obj) method which simply calls the appropriate method. But the different being that in the second case, there is just one big method dealing with all cases.

Are there any penaulties in heaving many methods per class? It doesn’t seem there is much problem in having a huge method with loads of if-else statements, but is it easy to mantain? I personally do not like huge methods, and tend to split it in smaller, more specific ones. But I’m not sure if much over head is indeed a problem.

I know it’s probably a silly question, but I thought why not ask since I can learn something :stuck_out_tongue:

#7

Hi Pedro,

Here is how I usually do it. Suppose that you have an object model for tests containing multiple choice questions. Then you can do this:


public class Test {
    private List questions;

    ...

    public Element toElement() {
        Element testElem = new Element("test");
        for (Iterator it = questions.iterator(); it.hasNext(); ) {
            Question question = (Question)it.next();
            testElem.addContent(question.toElement());
        }
        return testElem;
    }
}

public class Question {
    private List choices;

    ...

    public Element toElement() {
        Element quesElem = new Element("question");
        for (Iterator it = choices.iterator(); it.hasNext(); ) {
            Choice choice = (Choice)it.next();
            quesElem.addContent(choice.toElement());
        }
        return quesElem;
    }
}

public class Choice {
    private String text;

    ...

    public Element toElement() {
        Element choiceElem = new Element("choice");
        choiceElem.setText(text);
        return choiceElem;
    }
}

This approach is nice because it is very simple: a given class in the object model is responsible for outputting its own XML, and delegates responsibility for outputting child XML to its children. The toElement() method for any given class tends to be reasonably simple.

Willie

#8

Thanks Willie. Help is much appreaciated :slight_smile:

The example does sell well the more object-oriented solution to the problem.

But, what would you do if some of those objects you want to put in xml format are from another API? (in my case, scenegraph objects from Xith3d) Since, they are open source, I could add toElement() methods to them or I could also create my own objects that extend them and add the extra method.

I ended up implementing a centralised version in the end :stuck_out_tongue_winking_eye: Simply because I didn’t want to create or modify all those classes. It seems that if those classes are not really yours, you can’t always implement a “hasToElement” interface.

I face a similar problem now when wanting to clone certain objects from a diffrent API that do not have such cloneable features. I’m really considering having a centralising method clone(Object obj) that handles the objects I care, and return to me a copy of it. I still don’t like this approach, because the way you described before does seem a lot better, but again I cannot really modify the sourcecode from the third-party API I’m using, and it seems that to extend with all their classes with a clone() and toElement() is not really a good solution.

#9

Hi Pedro,

Oh, yeah, I agree with what you did entirely. The suggestion I was making was based on the assumption that the classes are yours to modify. If they are not yours to modify, I agree that you shouldn’t. (For example, if you want to use an updated version of the external library, you have to reimplement everything all over again.) And I don’t think that introducing tons of new classes just to support a toElement() method makes any sense.

On your centralized converter, I like the idea of having ABCToElement() methods as you proposed. That is a more OO way to do it than to use if’s and instanceof’s. (Also, you said that performance matters, and doing if’s and instancesof’s is more expensive than calling known methods. Moreover you get the compile-time type-checking.)

Actually, you could (if you wanted) suppress the “ABC” part of the method name, and just have a bunch of toElement(ABC abc), toElement(XYZ xyz) methods. That’s a little cleaner (IMHO). But either way is fine.

Willie