Type: Feature Request
Status: Open (View Workflow)
Affects Version/s: 3.0.0.M1
Fix Version/s: None
Similar Issues:Show 10 results
ERRAI-532 Errai fails to find array marshallers for non-concrete types in DevMode ERRAI-444 Implement JSON marshalling tests without using Errai JSON ERRAI-230 [Eclipse Integration] GPE's "GWT Compile" doesn't create the errai classes ERRAI-685 Create an Errai subsystem for speeding deployment in WildFly ERRAI-414 Errai JAX-RS may not be used without Errai Bus and Errai IOC ERRAI-602 Bugs in Errai Reference Guide ERRAI-261 Create an Errai module that exposes HTML 5 sensor events using CDI ERRAI-704 Errai Navigation never destroys @Dependent scoped @Page instances ERRAI-678 Separate templated widgets from Errai IOC ERRAI-571 Document transitive dependencies of Errai Navigation on Errai CDI
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: