There are certain use cases where there are certain classes of objects that would benefit from being added to a registry of some sort. Examples include Places, Data Providers, or Dashboard Widgets - In general, when there is a great deal of runtime configuration.
To do this now, the developer must build a registry himself, a relatively tedious task. Trying to do so while using Errai-CDI is even more complex, especially with 3.0 moving to an Asynchronous interface.
The errai framework could really provide a benefit by making the creation of such registries dead-simple. Here is an example of how it could go:
Have an errai registry interface:
The developer would then create a registry as follows:
where DashboardWidget is an interface as well.
Then, to have "DashboardWidgets" registered with the DashboardRegistry, we could do:
where type is optional, defaulting to the class name. Finally, to use the registry, one would simply inject it:
To summarize, in my example implementation, I have one new errai interface, and one new errai annotation.
There are a couple of benefits to this over using the IOC Bean manager directly,
- it is more formalized by type
- allows for the creation of beans from something other than the class (for example, a predefined string)
- it actually allows for a synchronous call even when using the AsyncBeanManager.
How this differs from Named Beans
Named beans would allow you to access beans based on a name (provided by the @Named annotation). Using the AsyncBeanManager, these beans would still need to be created asyncronously once the AsyncBeanDef was returned. The idea with the registry is that the registry would be injected (or retried from the AsyncBeanManager asynchronously), but the call into the registry for a bean would be synchronous, regardless of the type of IocBeanManager that was being used.
Conceptually, I am picturing code generated to the effect of: