Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm considering passing xml back and forth for error messages but each error has different scenarios.

one situation at hand is passing diffed text comparison while others are as simple as passing a text message.

What kind of serialization/deserialization strategy could I use for such a scenario?

The main issue with a scenario like this is that the object is different from case to case and there needs to be a mechanism for identifying what type it is.

Serializing xml is pretty straight forward:

Three sloppy ideas pop into my mind from the start:

  1. Make some super class that contains every possibility of contained types.
  2. Make some mechanism for reading the xml first to identify what's in it.
  3. Use option 2 and convert the inner body xml to an object.

A more elegant approach would be to implement some kind of Action pattern, where, once the object was identified you could create the proper action to take with it.

Some ideas consist of the Action/Executor pattern or IoC:

Here is an example pattern idea that runs parrallel to what I'm thinking:

Not for data persistence but for error handling by the client: The client decides how to handle the error once received based on the Action from a base library that takes place after deserialization.

my considered xml format would be something like this:

diff error:

<errorMessage>
<header>The header is not correct</header>
<body>

<diffErrorArray>
<diffItem message="NoChange">
<customMessage>Correct</customMessage>
<source>HeaderColumn1</source>
<destination>HeaderColumn1</destination>
</diffItem>

<diffItem message="Replace">
<customMessage>Changed</customMessage>
<source>HeaderColumn1</source>
<destination>Header_Column_1</destination>
</diffItem>

<diffItem message="AddDestination">
<customMessage>Unknown</customMessage>
<source></source>
<destination>Header_Column_1</destination>
</diffItem>

<diffItem message="DeleteSource">
<customMessage>Missing</customMessage>
<source>HeaderColumn2</source>
<destination></destination>
</diffItem>

</diffErrorArray>

</body>
</errorMessage>

string error:

<errorMessage>
<header>Bad news</header>
<body>
<stringErrorMessage>Something really bad happened.</stringErrorMessage>
<body>
</errorMessage>
share|improve this question
    
Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask –  gnat Mar 18 at 19:50
    
@gnat: Didn't he already put his proposed formats in the question? –  Robert Harvey Mar 18 at 19:54
    
@RobertHarvey meta.stackexchange.com/a/182380/165773 –  gnat Mar 18 at 19:56
1  
Some clues here: stackoverflow.com/q/12291801 –  Robert Harvey Mar 18 at 20:07
1  
What would be wrong with calling one format errorMessageType1 and the other errorMessageType2? Of course give more descriptive names than Type1, Type2. –  Dunk Mar 18 at 21:06

1 Answer 1

up vote 2 down vote accepted

Xml deserialization - at least in case of C# (you're not referring to it directly, but your links indicate it as your language of choice) - has type recognition built in. Why not make use of that?

See http://stackoverflow.com/questions/775647/how-do-i-deserialize-xml-without-knowing-the-type-beforehand for more details.

1: Make some super class that contains every possibility of contained types.

As demonstrated in the question I linked to above, all it takes is creating some common base class for your errorMessage objects. Then you need to use XmlInclude.

So the super class would only have to "contain every possibility" in the sense of knowing about all its subtypes (but not their implementation details). It's still all nice and neat in terms of OOP.

Note that if you feel that .NET serialization is too limiting, there's always more sophisticated alternatives such as SharpSerializer - better suited for polymorphic scenarios.

Again, this is not a language-agnostic suggestion, but if you used another programming language, the advice still applies: you can look for a good open-source library.

2: Make some mechanism for reading the xml first to identify what's in it.

You could also use reflection and retrieve the type in run-time (as Kirtan suggested) by the name of the root element, or some attribute of the root element.

Another option would be to create, or generate, XSD schemas for your errorMessage items, then use these schemas to validate the incoming messages - thus establishing their "type identity".

One advantage of this admittedly a bit more troublesome solution is that if the incoming xml was somehow broken, xsd validation could tell you exactly where and why (eg. some unexpected, unrecognized element), you don't have to handle this "manually".

Then there's dynamic typing and yet another interesting approach:

http://stackoverflow.com/a/13705918/168719

A more elegant approach would be to implement some kind of Action pattern, where, once the object was identified you could create the proper action to take with it.

That's what takes place after you deserialize the message, doesn't it?

With regard to this, I don't think one could come up with suggestions superior to what you have already found in this thread: http://stackoverflow.com/questions/298976/is-there-a-better-alternative-than-this-to-switch-on-type

I hope this gives you some inspiration. If not, the principle I go by is: when it's awfully hard to solve a problem, most likely the problem itself is badly posed from the very beginning. So if you are stuck, maybe it's time to step back and redesign. I don't know broader context, so I have no way of knowing how possible it is in your case.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.