It's all about the answers!

Ask a question

API bug? "html" types are not really XMLString?


Ernest Crvich (19211917) | asked Apr 26 '09, 7:33 p.m.
The below was discovered with RTC 2.0 Beta 1 on Windows XP.

Note that IWorkItem.set/getHTMLSummary() and set/getHTMLDescription()), both use XMLString as the type to pass in and return.

The IAttribute objects you get back from IWorkItemClient.findAttribute() for "summary" and "description" claim they are indeed of type XMLString.

Unfortunately, they aren't being treated as such by IWorkItem.getValue() (which returns a bare String object) and IWorkItem.setValue() (which expects a bare String, and blows up with a ClassCastException if you try to pass in XMLString).

Is this a known bug?

4 answers



permanent link
Marcel Bihr, Jazz Work Item team (1.4k) | answered Apr 27 '09, 6:15 a.m.
JAZZ DEVELOPER
Hi
If you are using a 'html' attribute, you have to use XMLString.createFromXMLText(workitem.getValue(attribute)) to get an XML string and to write it to the work item xmlString.getXMLText().

Regards

Marcel
Jazz Work Item team

permanent link
Ernest Crvich (19211917) | answered Apr 30 '09, 4:16 p.m.
But why doesn't IWorkItem.getValue() return an XMLString object for the HTML-typed IAttributes? Wouldn't that make more sense if the returned value contains embedded XML text? The user has to do extra work on these situations to go back to the IAttribute object and do a clumsy string equals() comparison on getAttributeType(), rather than just do "instanceof" on the returned object.

Ditto for setValue(), the user would ideally pass in an XMLString since that's what's really needed.

That's how get/setHTMLDescription() and get/setHTMLSummary() work, so obviously it made sense in those cases.

permanent link
Patrick Streule (4.9k21) | answered May 04 '09, 4:48 a.m.
JAZZ DEVELOPER
getValue() and setValue() operate on the model types (a String in the case of description/summary etc.). The same applies to other primitive types that have a higher-level representation, e.g. Durations, which are represented as Longs in the model.

While I agree that the automatic conversion would be helpful, this would be a breaking API change (and one that can't be detected at compile time), and hence will not be changed.

--
Regards,
Patrick
Jazz Work Item Team

permanent link
Ernest Crvich (19211917) | answered May 08 '09, 1:28 p.m.
I seem to have come across a situation that is even worse than the above, maybe you can explain how to properly address this?

internalState and internalResolution are returned from getValue() as a String (instead of an Identifier<>, which it probably what it should have been), which in each case is just a number. And because the IAttribute type is also just "smallString", I have no way to know I must do a lookup to get the resolution/state names. IOW, I need "Duplicate" instead of "2", or whatever...the internal indices are of no use to me.

The only way this seems to be fixable is by doing a conditional based on the exact field name, which is obviously rather kludgey code. Keep in mind this code I'm writing is intended to be used for pretty much any work item, including custom ones. Ideally I don't want to make assumptions like this (based on the field name).

Your answer


Register or to post your answer.