Hello there,
today I updated to the RC version of the WebAPI and found that there was no real workable replacement for the FormatterContext.
Beside I have no idea why it had to be removed there are various reasons in my opinion as to why it should be there. As long as there is no other alternative to access some kind of request based context.
Perhaps a little information about our current setup will help to show about why we need it.
To support some kind of Versioning we decided to create a version based MimeType (ContentType). So that we can have special formatters for each version we support. This of course would still be possible without a context, but during the mapping of the objects to those versioned data transfer objects we enrich our response with various other information, for example with information we get from our SAP backend system. Now the problem is that the SAP Connector does only work if a HttpContext is available (Bad programming from their side but nothing we could change). With the FormatterContext I was at least able to get the HttpContext and set it for the current thread which will execute the SAP request. But of course this is not possible anymore now without such a context.
Also depending on the HttpLanguage Header the mapping engine used the Context to localize the response, which is again not possible as the Mapping Engine itself has no access to the HttpHeaders directly and relied on an existing Context to access.
At least for the later problem the workaround with the GetPerRequestFormatterInstance works as at least until now no localized object need to be deserialized.
With best regards,
Kay
Comments: 5) CanWriteType should be CanWriteObject(object instance) to allow a formatter to handle only certain instances of a type
today I updated to the RC version of the WebAPI and found that there was no real workable replacement for the FormatterContext.
Beside I have no idea why it had to be removed there are various reasons in my opinion as to why it should be there. As long as there is no other alternative to access some kind of request based context.
Perhaps a little information about our current setup will help to show about why we need it.
To support some kind of Versioning we decided to create a version based MimeType (ContentType). So that we can have special formatters for each version we support. This of course would still be possible without a context, but during the mapping of the objects to those versioned data transfer objects we enrich our response with various other information, for example with information we get from our SAP backend system. Now the problem is that the SAP Connector does only work if a HttpContext is available (Bad programming from their side but nothing we could change). With the FormatterContext I was at least able to get the HttpContext and set it for the current thread which will execute the SAP request. But of course this is not possible anymore now without such a context.
Also depending on the HttpLanguage Header the mapping engine used the Context to localize the response, which is again not possible as the Mapping Engine itself has no access to the HttpHeaders directly and relied on an existing Context to access.
At least for the later problem the workaround with the GetPerRequestFormatterInstance works as at least until now no localized object need to be deserialized.
With best regards,
Kay
Comments: 5) CanWriteType should be CanWriteObject(object instance) to allow a formatter to handle only certain instances of a type