You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All Extensions/Fragments are explicitly defined in the solution configuration of a component
Current Behaviour
When components are invoking extensions they currently use two methods to determine the extensions that should be invoked
Using the Component Name/Instance/Version to generate a matching extension name
Explicit definition by a user using the Extensions attribute on components which support extension based management
The first is not documented and is more a magic approach, If you don't know it exists it can cause issues ( such as naming two related components that have different component types and then a fragment specifcally targetting a given component type is used on another type )
Possible Solution
Remove support for the name based approach and require that all extensions are explicitly defined through the Extensions component attribute
Context
This simplifies the configuration and understanding of how extensions and components work. With the introduction of the various ways we can now manage configuration applied to components the use for a "magic"/implied implementation isn't really required.
The text was updated successfully, but these errors were encountered:
I support this change. It also means the current magic behaviour of a value starting with _ also disappears - it is just an exact match on whatever name you provide.
Expected Behaviour
All Extensions/Fragments are explicitly defined in the solution configuration of a component
Current Behaviour
When components are invoking extensions they currently use two methods to determine the extensions that should be invoked
The first is not documented and is more a magic approach, If you don't know it exists it can cause issues ( such as naming two related components that have different component types and then a fragment specifcally targetting a given component type is used on another type )
Possible Solution
Remove support for the name based approach and require that all extensions are explicitly defined through the Extensions component attribute
Context
This simplifies the configuration and understanding of how extensions and components work. With the introduction of the various ways we can now manage configuration applied to components the use for a "magic"/implied implementation isn't really required.
The text was updated successfully, but these errors were encountered: