Priority set to critical because it prevents using Blossom with 5.4.

Background

Blossom creates its dialogs on demand when they're needed. Every time a dialog is to be displayed its definition is created from scratch. This allows the dialog creation code to adapt to the current context, for instance who's using it and what content it is being used for. The context is captured by a custom FormDialogPresenter and picked up by the dialog provider. It is therefore impossible to get the definition of a blossom dialog without a context. The definition can only be acquired from the provider when called from the custom FormDialogPresenter.

Magnolia 5.4

In 5.4 the whole registry and provider concept changes. These changes break Blossom because:

• There's no longer a getPresenterClass() on the provider. It is instead read directly from the definition, which cannot be acquired. This is done in FormDialogPresenterFactoryImpl and in DialogDefinitionRegistry.
• There's no way to register a legacy dialog definition provider. There needs to be a register() method in DialogDefintionRegistry for the legacy provider interface. The method should wrap the legacy interface to adapt it to the new interface. The new provider keeps an in memory representation of the definition which is acquired when the provider is created. This must not happen when registering a legacy provider.

In 5.4 TemplateDefinitionRegistry has a backwards compatible register method. It works fine for Blossom because its template definitions are created once at startup and then never changed. Having said that, its design makes it impossible for implementations to have a provider that created the definition on demand.

I have implemented very hackish workarounds for these issues and will commit them on branches. Should at least serve as some kind of example.