If it understand it correctly, notification handlers now have to be registered during the startup ( so in configure services or a composer). So i am after some advice on how this pattern might fit into Umbraco 9 land.
for uSync we have SyncHandlers each one is responsible for the management of an Umbraco entity, and capturing changes when people save, move, delete those elments in Umbraco.
We load these handlers in a collection (using a collection builder) during start
Advantages to this is we don't have to register them all, and we can dynamically add new ones (such as support for vendr, or forms) without the core needed to know about it.
Within the handlers we (in v8) have a method to initialize (and cleanup) listening for the the static events:
During initialization of the app (in a component's Initialize method), we load in the valid handlers (based on configuration this might be a subset of the handlers available). and we call the InitilizeEvents on each on to register the notification handler.
var handlers = handlerFactory
.GetValidHandlers(new SyncHandlerOptions(handlerFactory.DefaultSet, HandlerActions.Save))
.ToList();
foreach (var syncHandler in handlers)
{
syncHandler.Handler.Initialize(syncHandler.Settings);
}
v9 - and notifications
in v9 - this code would live in a UmbracoApplicationStarting Notification handler, once the app is started we could in theory loop through the configured handlers but as i understand it we cannot/should not add new NotificationHandlers at this point?
The question then is :
How do we dynamically get the valid handlers to register for save/delete notifications - without putting them manually into
composers/configure methods ?
My thoughts so far include:
Registering a super notification handler for all the core events and and has the SyncHandler collection injected into it - it could then find the valid for an event and trigger the correct method when it happens. Sort of how the UserNotificationHandler is doing this in the core code (but it isn't dynamically loading new events based on actions).
Making the handlers mange their own Notifications and having some way of triggering code to add the relevant notification handlers for each of the SyncHandlers in a collection during a compose method ?
A way of adding NotficationHandlers outside of configure (but not sure if we can or really if we should).
Each of these has its own pros and cons, but i just wanted to check if there are any other ideas/best practice as to how this type of thing should be done in Umbraco 9
Intrestingly i just stumbled across this comment in the ModelsBuilder code in the Core:
// TODO: I feel like we could just do builder.AddNotificationHandler<ModelsBuilderNotificationHandler>() and it
// would automatically just register for all implemented INotificationHandler{T}?
I think the intent is that Composers and Components will still live and work fine in v9. However, since it is .NET Core, you can also use the pipeline configuration methods and have .AddXXX and .UseXXX methods which are added to the Startup class to both register and then use handlers.
NotificationHandler pattern for collections
Hi,
If it understand it correctly, notification handlers now have to be registered during the startup ( so in configure services or a composer). So i am after some advice on how this pattern might fit into Umbraco 9 land.
for uSync we have SyncHandlers each one is responsible for the management of an Umbraco entity, and capturing changes when people save, move, delete those elments in Umbraco.
We load these handlers in a collection (using a collection builder) during start
Advantages to this is we don't have to register them all, and we can dynamically add new ones (such as support for vendr, or forms) without the core needed to know about it.
Within the handlers we (in v8) have a method to initialize (and cleanup) listening for the the static events:
for example the Macro Handler has :
During initialization of the app (in a component's
Initialize
method), we load in the valid handlers (based on configuration this might be a subset of the handlers available). and we call theInitilizeEvents
on each on to register the notification handler.v9 - and notifications
in v9 - this code would live in a
UmbracoApplicationStarting
Notification handler, once the app is started we could in theory loop through the configured handlers but as i understand it we cannot/should not add new NotificationHandlers at this point?The question then is :
My thoughts so far include:
Registering a super notification handler for all the core events and and has the SyncHandler collection injected into it - it could then find the valid for an event and trigger the correct method when it happens. Sort of how the UserNotificationHandler is doing this in the core code (but it isn't dynamically loading new events based on actions).
Making the handlers mange their own Notifications and having some way of triggering code to add the relevant notification handlers for each of the SyncHandlers in a collection during a compose method ?
A way of adding NotficationHandlers outside of configure (but not sure if we can or really if we should).
Each of these has its own pros and cons, but i just wanted to check if there are any other ideas/best practice as to how this type of thing should be done in Umbraco 9
Intrestingly i just stumbled across this comment in the ModelsBuilder code in the Core:
See ( see UmbracoBuilderDependencyInjectionExtensions.cs#L99 )
So maybe there is a direction there some where.
I think the intent is that Composers and Components will still live and work fine in v9. However, since it is .NET Core, you can also use the pipeline configuration methods and have .AddXXX and .UseXXX methods which are added to the Startup class to both register and then use handlers.
is working on a reply...