You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. privatestaticDictionary<string,string>VocabularyNamespaceMappings=newDictionary<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(varstream= 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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: