API bug? "html" types are not really XMLString?
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
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 |
|
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. |
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 |
|
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
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.