Our code writers will only need to consume annotations for Capabiltiies and Core vocabularies. Although it's not general or extensible, it's acceptable at the moment to hard-code references to these vocabularies. This entails registering a mapping from the vocabulary namespace to a namespace that contains implementations of complex types:
// TODO: Extend / modify this to more clearly support custom annotation registration.
private static Dictionary<string, string> VocabularyNamespaceMappings = new Dictionary<string, string>()
{
{ "Org.OData.Capabilities.V1", ViprCoreVocabularyRoot + ".Capabilities" }
};
Additionally, this requires loading the Edm Model that defines entities in the referenced vocabulary.
// TODO: As above, Extend / modify this to more clearly support custom annotation registration.
using (var stream = Assembly.GetExecutingAssembly().GetManifestResourceStream(CapabilitiesXmlFilePath))
{ /*etc...*/
Reasons to fix
In the future, if we have consumers of Vipr that would like to write custom writers which use custom annotations for code generation (SAP may find this functionality useful, for example), this design will need to be changed.
A possible fix is to refactor registration to a static method that can be invoked with the namespace mapping and a path to the vocabulary definiton; the remainder of the vocabulary parsing code should be general enough to handle this case.
Issue by MrTomWhite Friday Jan 23, 2015 at 23:08 GMT Originally opened as https://github.com/Microsoft/vipr-old/issues/59
Status Quo
Our code writers will only need to consume annotations for Capabiltiies and Core vocabularies. Although it's not general or extensible, it's acceptable at the moment to hard-code references to these vocabularies. This entails registering a mapping from the vocabulary namespace to a namespace that contains implementations of complex types:
Additionally, this requires loading the Edm Model that defines entities in the referenced vocabulary.
Reasons to fix
In the future, if we have consumers of Vipr that would like to write custom writers which use custom annotations for code generation (SAP may find this functionality useful, for example), this design will need to be changed.
A possible fix is to refactor registration to a static method that can be invoked with the namespace mapping and a path to the vocabulary definiton; the remainder of the vocabulary parsing code should be general enough to handle this case.