Annotation API about tikxml HOT 6 CLOSED

1. und 2. @root is good to go without "strict=false" because all attributes should be per default "required=false" (you know kicker ^^)
2. no idea at the moment :)
3. i will think about it but for the moment instanceof was also my first thought
4. @path VERY good for kicker feeds

from tikxml.

1. and 2. naming of @XmlAble or @root - i dont care, strict and required should be false per default
2. simple xml isnt supporting polymorphism now - so we should annotate it anyway to define which class should be used per element (for example a type-string like in @jsontype)
3. @path is just great.

from tikxml.

Regarding polymorphism, I think the following solution could work under the following assumption:

• Renaiming @Root to @Xmlable since the name root doesn't make sense anymore (see the next paragraph). We could also rename it to @TikXml to achieve a stronger Tickaroo branding ^^
• Each xml element name can be mapped to exactly one class
  In other words <car> maps to java @Xmlable("car" ) class Car extends Vehicle {} and <motorcycle> maps to java @Xmlable("motorcycle" ) class Motorcycle extends Vehicle {}

Therefore resolving polymorphism while reading the following xml should work:

<garage>
   <car id="1" />
  <motorcycle id="2" />
</garage>

@Xmlable("garage")
class Garage {

      @ElementList(inline = true)
       List<Vehicle> inventar; // Will contain car and motorcycle
}

When writing xml we can do the other way arround.

for (Vehicle v : garage.inventar){
    if (v.getClass() == Car.class) {
        // write <car />
     }

    if (v.getClass() == Motorcycle.class) {
        // write <motorcycle />
     }

}

However, there is one issue with this approach: Since the xml element name will map to a class, we can not use the xml element name anymore to identify a "Property" (which btw. is another reason why xml is such a bad serialization format).

<person>
   <name>Hannes</name>
   <age>26</age>
</person>

class Person {
    @Element
     String name;

     @Element
      int age;
}

The problem here is, that we would assume that <name> maps to a java class Name {}. Same for <age> which the compiler would expect to map to java class Age {}. For simple primitives like String, int, double etc. our xml parser could make an extra check and map them to the java field name rather than using xml elements name for determining the corresponding class. We could also introduce a special @PropertyElement annotation just for this kind of propertys to make it even more clear.

Than we could use @Element just for "objects" (not primitives) to resolve polymorphism like that:

@Xmlable
class Garage {

 @Element
   Vehilce vehicle;
}

<garage>
   <car id="1" />
</garage>

or

<garage>
   <motorcycle id="2" />
</garage>

Both xml snippets from above should be mappable to Vehilce by checking the xml element name as described with @ElementList

What do you think of this approach?

Alternatively, if we don't want to use the xml element name as mapping indicator, we have to give the polymorphism information as suggested by @luke1313 via an additional annotation like @JsonType in jackson:

@Xmlable
class Garage {

 @Element(type = { Car.class,  Motorcycle.class})
   Vehilce vehicle;
}

In this case the xml element name is mapped to the field, rather to the type and removes the problem of @Element on "Properties" as described above:

class Person {
    @Element
     String name;

     @Element
      int age;
}

However, that requires to write more code because we have to use annotations to explicitly declare polymorphism types like @Element(type = { Car.class, Motorcycle.class}). Last but not least, using xml element name for mapping to a field (and not as type information to map to a certain class) would also increase the extensibility of this xml parser, because we can add a "converter" to java.util.Date easily.

So the main question is: Is polymorphism more important than "properties" (like person name, person age)? The problem with properties is, that xml allow you to write properties as xml attributes and as child elements:

<person>
   <name>Hannes</name>
   <age>26</age>
</person>

vs.

<person name="Hannes" age="26" > </person>

Have I already mentioned how bad xml is for serializing data ^^
I'm not sure if replacing json with xml is a step forward for the kicker app ...

What do you think? What was your experience so far while working with kicker feeds? What about the home news feed? There is a lot of polymorphism I guess?

The question is: should xml element's name be used to map to a class (I guess this is how iOS team is parsing xml feeds) or should the xml element's name be used to map to a field of a class (this is how any other parser like jackson etc. works)

from tikxml.

i really like your approach mapping tags to classes - im thinking about cases where a class could (possibly) have more than one "name" coming from the backend in different feeds. i think this case exists and therefore we need a way to achieve mapping for multiple names per class.

i think we also could use it by extending the base class and just create classes per "name" - but thats kind of ugly - do you have any other ideas for the same objects coming with different names (if this actually happens in our feeds)

from tikxml.

Yep inheritance is the the only way to achieve that (maybe we could allow multiple names in @Xmlable(name = {"name1", "name2" }) too)

or

Xml element name as property / field name

from tikxml.

Since I have written down a proposal, let's close this issue and continue this discussion in a new issue #8

from tikxml.