#221 truly annoying toString

[Jens Villadsen]

I happen to use profile validtion for most of my HL7 hats'n'pipes which works fine, most of the time. However, when for instance I'm in my development environment (Eclipse) and I hover my mouse pointer over a message variable, the natural thing that eclipse does is to call the toString on the message, which happens to be the toString on AbstractMessage. However, lets say the message does not conform to the profile that I use - now what happens is that I'm now unable to inspect the actual content of the message as the toString happens to use the current context containing the profile which evidently ends up in the Parser line 619 because of profile validation errors - to the toString ends up being <some message="" class=""> - Failed to create toString(): Validation has failed

Argh!

Could the toString might instead use a vanilla parser in AbstractMessage, and let the parse and encode methods on the Parser do actual parsing of the message?

[Christian Ohr]

Got your point. Unfortunately, the parser instance attached to the message can be either PipeParser or XMLParser, and their ModelClassFactory might also be relevant for re-encoding into a string.

I was wondering, however, if AbstractMessage (or an "unmodifiable" wrapper class) could not just cache the "original" string and use this e.g. in toString() and encode() given that the message was not altered.

[Christian Ohr]

A while ago I committed ca.uhn.hl7v2.model.Unmodifiable, that allows to protect messages against accidential modification, unfortunatly at the cost of losing type information. As a side effect, when a string is parsed into an Unmodifiable message, it can be kept around and toString() is just returning it.