-
Notifications
You must be signed in to change notification settings - Fork 160
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
[Request] Add support for arbitrary models in custom actions #848
Comments
@julealgon Actually, I had a rough design for a similar situation. Correct me at https://github.com/OData/AspNetCoreOData/blob/main/src/Microsoft.AspNetCore.OData/Formatter/FromODataBodyAttribute.cs It's not finished yet until I have more clear customer usages. Any thoughts? |
That's certainly a start right there! Personally, I think it would be awesome if we found a way to do it without requiring a custom attribute or at least a way to default to that attribute for action complex type parameters similar to how standard MVC routes default to I don't precisely know how the convention was created with |
Forgot to link this with the other issue were we discussed about it and I mentioned I'd open it: @habex-ch FYI |
How does FromODataBodyAttribute help? The action does not show in swagger and I get a 405 when I try it. If I remove the parameter from the model then the swagger is fine and I can call the function but the parameter is missing from $metadata |
Custom functions today are very cumbersome to use: they require the use of parameters that are bound to a custom dictionary-like structure,
ODataActionParameters
. The consumer then needs to read the parameters from this object to use them.This goes against standard MVC model binding which allows (and recommends) binding your parameters directly into a strongly typed model object that represent them.
I think adding native support in OData to bind the body of the action to an actual custom model (like MVC does) would make the framework vastly easier to use.
From the docs: https://learn.microsoft.com/en-us/odata/webapi-8/fundamentals/actions-functions#bound-action-1
Instead of:
We'd do:
This would naturally also open the door for standard validation using DataAnnotations or FluentValidation, making it much more seamless when coming from a normal MVC route.
When specifying the EDM for the function, I'm not entirely sure what would need to be done there, but maybe something that would generate the required EDM automatically based on the complex type could be achieved?
The
Parameter
method could identify that the type is not a primitive type, and apply the rules as needed (either transparently transform it into multipleParameter<primitiveType>
calls for each property, or just support this natively at the EDM level as well.The text was updated successfully, but these errors were encountered: