Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  XML question  (Read 1744 times)
0 Members and 1 Guest are viewing this topic.
Offline pedro

Junior Member




Java games rock!


« Posted 2004-04-13 00:05:08 »


Maybe even off-topic here, dunno 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 Smiley
Offline mlk

Junior Member




Muppet!


« Reply #1 - Posted 2004-04-13 00:10:25 »

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

Offline javawillie

Junior Member




Hola, Paco.


« Reply #2 - Posted 2004-04-14 19:01:49 »

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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline pedro

Junior Member




Java games rock!


« Reply #3 - Posted 2004-04-14 20:47:30 »

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
Offline javawillie

Junior Member




Hola, Paco.


« Reply #4 - Posted 2004-04-14 21:02:35 »

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
Offline pedro

Junior Member




Java games rock!


« Reply #5 - Posted 2004-04-15 17:17:58 »

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 Tongue

Offline javawillie

Junior Member




Hola, Paco.


« Reply #6 - Posted 2004-04-15 17:55:45 »

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:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
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
Offline pedro

Junior Member




Java games rock!


« Reply #7 - Posted 2004-04-16 13:14:37 »


Thanks Willie. Help is much appreaciated Smiley

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 ;P  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.


Offline javawillie

Junior Member




Hola, Paco.


« Reply #8 - Posted 2004-04-16 17:39:51 »

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
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (36 views)
2014-09-24 16:13:29

Pippogeek (29 views)
2014-09-24 16:12:22

Pippogeek (18 views)
2014-09-24 16:12:06

Grunnt (41 views)
2014-09-23 14:38:19

radar3301 (24 views)
2014-09-21 23:33:17

BurntPizza (60 views)
2014-09-21 02:42:18

BurntPizza (30 views)
2014-09-21 01:30:30

moogie (35 views)
2014-09-21 00:26:15

UprightPath (49 views)
2014-09-20 20:14:06

BurntPizza (52 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!