Copyright © 2012 Kaltura Inc.
All Rights Reserved. Designated trademarks and brands are the property of their respective owners.
Use of this web site constitutes acceptance of the Terms of Use and Privacy Policy.
EduVideo.org
Schema problem: KalturaModerationFlagListResponse contains bad element name
Tue, 08/25/2009 - 00:16
When using the v3 API to get a list of moderation flags, the server responds with:
<?xml version="1.0" encoding="utf-8"?>
<xml>
<result>
<objectType>KalturaModerationFlagListResponse</objectType>
<objects>
<item>
<objectType>KalturaModerationFlag</objectType>
<id>11</id>
<partnerId>1</partnerId>
<userId>0</userId>
<objectType>2</objectType> <!-- PROBLEM -->
<flaggedEntryId>iqhubczu14</flaggedEntryId>
<flaggedUserId></flaggedUserId>
<status>1</status>
...SNIP...
</item>
</objects>
<totalCount>1</totalCount>
</result>
<executionTime>0.183758020401</executionTime>
</xml>
<xml>
<result>
<objectType>KalturaModerationFlagListResponse</objectType>
<objects>
<item>
<objectType>KalturaModerationFlag</objectType>
<id>11</id>
<partnerId>1</partnerId>
<userId>0</userId>
<objectType>2</objectType> <!-- PROBLEM -->
<flaggedEntryId>iqhubczu14</flaggedEntryId>
<flaggedUserId></flaggedUserId>
<status>1</status>
...SNIP...
</item>
</objects>
<totalCount>1</totalCount>
</result>
<executionTime>0.183758020401</executionTime>
</xml>
Notice that, under "item", there are two "objectType" elements. That's a problem. There should only be one. I think the first one is okay based on what PlaylistListResponse looks like. The second "objectType" looks like it contains the value of the "ModerationObjectType" enum. So I think the element needs to be renamed from "objectType" to "moderationObjectType" and the schema changed accordingly.
Jeff
Wed, 08/26/2009 - 15:17
#2
Yeah, this creates a problem when the Java client tries to instantiate a result object from the returned XML. I'm working around this by catching the exception that gets thrown when Java tries to parse the first objectType as an integer. It just ignores the exception. When it gets to the second objectType it successfully parses the int and sets the objectType to the appropriate enum.
It would be nice if someone would fix this on the server side and in the schema, but this workaround will be fine until that happens.
Jeff
Mon, 08/31/2009 - 13:15
#3
Hi Jeff,
It is a bug, but maybe we can work around this without catching the exception.
The .NET client is working with the same XML and it's working fine.
Here's how the KalturaModerationFlag object is parsed:
public KalturaModerationFlag(XmlElement node)
{
foreach (XmlElement propertyNode in node.ChildNodes)
{
string txt = propertyNode.InnerText;
switch (propertyNode.Name)
{
case "id":
this.Id = ParseInt(txt);
continue;
/* ... */
case "objectType":
this.ObjectType = (KalturaModerationObjectType)ParseEnum(typeof(KalturaModerationObjectType), txt);
continue;
case "flaggedEntryId":
this.FlaggedEntryId = txt;
continue;
/* ... */
}
}
}
{
foreach (XmlElement propertyNode in node.ChildNodes)
{
string txt = propertyNode.InnerText;
switch (propertyNode.Name)
{
case "id":
this.Id = ParseInt(txt);
continue;
/* ... */
case "objectType":
this.ObjectType = (KalturaModerationObjectType)ParseEnum(typeof(KalturaModerationObjectType), txt);
continue;
case "flaggedEntryId":
this.FlaggedEntryId = txt;
continue;
/* ... */
}
}
}
The enum parsing is using the TryParse (ParseInt internally use the TryParse) method so no exceptions are thrown. (At least it is hidden by the framework).
Because Kaltura backend is build on PHP, which is a very dynamic language and as much as we are trying to make sure that all the responses are "strongly typed" in all the scenarios, it is still better to parse the results in a "safe way".
Mon, 08/31/2009 - 13:50
#4
Thanks for the response Roman.
However, I feel this a bit different in Java.. see this @link where it states: "The Java case is more difficult - there is no direct equivalent to 'TryParse'"...
But it also provide a function that identify the type..so maybe it is possible in Java as well.
Jeff - what you think?
Mon, 08/31/2009 - 13:58
#5
In either language, until the bug is fixed, that case block is going to get executed twice, once for the legitimate element and once for the duplicate element. In one case the integer will be parsed successfully and the other it won't. In the case of .NET it sounds like .NET is swallowing the failure. Java throws an exception, but if I catch it and swallow it, that's functionally equivalent to how .NET is behaving, so it seems like the workaround is okay as-is.
Once I've checked in the Java client code we can revisit if needed. Hopefully the bug will be fixed by then so it will be a non-issue.
Jeff
Again... Nice spot!