Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic root tag name #140

Open
heyarny opened this issue Jan 6, 2020 · 6 comments
Open

Dynamic root tag name #140

heyarny opened this issue Jan 6, 2020 · 6 comments

Comments

@heyarny
Copy link

heyarny commented Jan 6, 2020

I was looking for a simple solution on how to proceed when there are different responses.

<response1>
  <foo>foo</foo>
</response1>
<response2>
  <bar>bar</bar>
</response2>

I could find some info about dynamic element within root, but not the root itself.
Is this not supported by this library?

@sockeqwe
Copy link
Contributor

sockeqwe commented Jan 6, 2020

I'm not 100% sure what you mean with "dynamic" but yes, that is possible you have to annotate 2 classes though:

@Xml
class Response1 {
  @PropertyElement
  String foo;
}
@Xml
class Response2 {
  @PropertyElement
  String bar;
}

When parsing you just have to tell TikXML to either parse Response1.class or Response2.class (that's what our Retrofit converter does under the hood)

@sockeqwe sockeqwe closed this as completed Jan 6, 2020
@heyarny
Copy link
Author

heyarny commented Jan 6, 2020

What if you don't know what response you're expecting?
Lets say there is an error while you expect Response1:

<error>
  <code>...</code>
</error>

Or there are different response types inherited from some "BaseResponse".
Everything quite possible scenarios.

Just like this case:
https://github.com/Tickaroo/tikxml/blob/master/docs/AnnotatingModelClasses.md#polymorphism-and-inheritance

But on root element.

@heyarny
Copy link
Author

heyarny commented Jan 6, 2020

Take a look at this unresolved question years ago:
https://stackoverflow.com/questions/34046908/retrofit-and-simplexml-for-unknown-root-element

@sockeqwe
Copy link
Contributor

sockeqwe commented Jan 6, 2020

No, it's not supported and I think error responses in general as return value is not best practice for REST API's (use HTTP Status codes)

With that said, reading such xml might work as following (haven't tried it yet, so you have to give it a try on your own):

@Xml 
class Response {
   
   @Element
    Foo foo;
 
   @Element
   Error error;
}

So you always parse into Response.class but either Foo or Error is null.

Writing xml is defenitely not supported as it will produce

<response>
   <foo>...</foo>
</response>

or

<response>
   <error>...</error>
</response>

@heyarny
Copy link
Author

heyarny commented Jan 6, 2020

I know at least one xml protocol (by CISCO) which is actually based on different root tags and those are not bound to specific endpoints. So you'll never know what response may come.
So it is not something uncommon.

Will convert the responses manually then.
Thanks

PS: you could change this to "feature request", if anyone cares..

@sockeqwe
Copy link
Contributor

You could do some "semi automated parsing" if you know all possible root tags by writing your own TypeAdapter that reads the root tag and then delegates to other (generated by annotation processors) TypeAdapter that then will do further xml parsing of child notes ... Same for writing xml in case you need it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants