Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support custom annotation registration beyond Core and Capabilities #17

Open
dotnet-bot opened this issue Jan 30, 2015 · 1 comment
Open

Comments

@dotnet-bot
Copy link
Collaborator

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:

        // 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.

@TheRealPiotrP
Copy link
Contributor

@Sridhar-MS does the current annotations design cover this scenario? Or is this still a future enhancement?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants