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

Extended parameter attributes for handlers & generic [Entity] attribute #1073

Open
jeremydmiller opened this issue Oct 14, 2024 · 0 comments
Labels
enhancement New feature or request
Milestone

Comments

@jeremydmiller
Copy link
Member

jeremydmiller commented Oct 14, 2024

The HTTP support has this:

/// <summary>
///     Base class for attributes that configure how an HTTP endpoint on a parameter is handled by applying
///     middleware or error handling rules
/// </summary>
[AttributeUsage(AttributeTargets.Parameter)]
public abstract class HttpChainParameterAttribute : Attribute
{
    /// <summary>
    ///     Called by Wolverine during bootstrapping to modify the code generation
    /// for an HTTP endpoint with the decorated parameter
    /// </summary>
    /// <param name="chain"></param>
    /// <param name="parameter"></param>
    /// <param name="container"></param>
    public abstract Variable Modify(HttpChain chain, ParameterInfo parameter,
        IServiceContainer container);
}

Which is used for the [Document] and [Aggregate] attributes in the Marten integration. Good stuff IMO. But there's nothing for that in the message handlers, and nothing like that for the EF Core or RavenDb support.

What if we had something more generic Wolverine core for message handlers that could also be helpful to HttpChains as well? And extend the IPersistenceFrameProvider abstraction to help generate code for a more generic [Entity] attribute?

There's another wrinkle. The existing [Document] attribute for Marten HTTP integration has the concept of being Required, and will return a 404 if not found. Maybe the HandlerChain / HttpChain model has some concept of "early exit" so that the same basic code can be used in both places, but let the chain alter based on whether or not it's HTTP or a message chain.

@jeremydmiller jeremydmiller added this to the 3.0 milestone Oct 14, 2024
@jeremydmiller jeremydmiller added the enhancement New feature or request label Oct 14, 2024
@jeremydmiller jeremydmiller modified the milestones: 3.0, 4.0 Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant