Closed ipjohnson closed 4 years ago
This is implemented
@ipjohnson thanks for this feature 🙏
Priority
method overrides the order of decorators registrations. This is still globally ordering the decorators and one cannot customize it per implementations, right?
Consider the following rare scenario:
public interface ICommand<T>{
void Handle(T data);
}
[Audit]
[Log]
public class FirstCommand: ICommand<string> { ... }
[Database]
[Log]
[Audit]
public class SecondCommand: ICommand<string>{ ... }
And there are three other decorators implementing the ICommand<T>
and with .When.MeetsCondition
, an example discussed earlier, they have been customized to be created on the existence of the corresponding attribute on top of the implementations. Is there any way that the order of decorators being based on the order of attributes? For instance, when creating decorators for FirstCommand
the order be Audit -> Log
but for the SecondCommand
it should be the other way: Database -> Log -> Audit
.
is it at all possible and reasonable?
Thanks.
Sadly attribute order is not preserved as part of the language specification.
"The order in which attributes are specified in such a list, and the order in which sections attached to the same program entity are arranged, is not significant. For instance, the attribute specifications [A][B], [B][A], [A,B], and [B,A] are equivalent."
Current you can prioritize exports but you can't prioritize decorators. It should be easy enough to add a fluent configuration method to allow this.
This was brought up in issue #253