HTML plugin: can't add menu items to custom objects that live under scheme that differs from "urn"

[mheidemeyer]

I had a problem for a few days, where I was not able to add options to custom objects and I managed to reproduce it on the sampleB:

If you replace "urn:cr" with "abc:cr" in the bundle-context.xml of the service as well as in the ModelObjectUriResolver (replace SCHEME with "abc"), then a right click on a Chassis in the view won't show any menu items. Replacing "urn:cr" with "abc:cr" means that the Chassis objects will live under a scheme that is different from "urn".

If this is a bug on the vSphere side, then it is not possible to create list views for custom objects that have IDs that begin with anything that is different from "urn". This was possible in the Flex plugin. In our project we have lots of custom objects that begin with a scheme that is different from "urn" and currently we can't create list views for them. It would be great if someone could verify this.

Btw. sorry for modifying this post so many times.. just wanted to make it as clear as possible!

Thanks for the support.

[_vladi_ · Accepted solution]

Hi,

It is required that the object URI scheme starts with "urn:". Afterwards you can append any custom scheme format.

For example: "urn:cr", "urn:abc" and "urn:abc:cr" are valid but "abc:cr" is not.

Cheers,

Vladi

[mheidemeyer]

This only applies to the HTML plugin, correct? I don't see this documented anywhere. Also, this contradicts the documentation in the ModelObjectUriResolver of sampleB:

/** * The URI scheme can be the form "acme" or "urn:acme", but not "urn" alone * which is reserved. Here we use the namespace "cr" for chassis-rack. * Note: "urn:vim25" and "urn:vri" are reserved too. */

[mheidemeyer]

What if we have existing custom objects that live under a namespace that is different from "urn" (the Flex plugin allows this) and we want to create list views for those in HTML? Shouldn't the HTML plugin also allow to have custom objects outside of the "urn" namespace?

[_vladi_]

You are correct that the documentation in the ModelObjectUriResolver is not completely correct. As it stands at the moment "acme" is not supported by the vSphere Client. Instead you should use "urn:acme" and append any other additional tags to do you own namespacing within the "urn" namespace.