Errai
  1. Errai
  2. ERRAI-485

Use Errai Magic to create "Registry" Objects

    Details

    • Type: Feature Request Feature Request
    • Status: Open Open (View Workflow)
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.0.M1
    • Fix Version/s: None
    • Component/s: ErraiIOC
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      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:

      public interface ErraiRegistry<O> {
      
        public O getRegistered( Object type );
      }
      

      The developer would then create a registry as follows:

      public interface DashboardRegistry extends ErraiRegistry<DashboardWidget> {
      
      }
      

      where DashboardWidget is an interface as well.

      Then, to have "DashboardWidgets" registered with the DashboardRegistry, we could do:

      @RegisterWith( registry=DashboardRegistry.class, type="weather")
      public class WeatherDashboardWidget implements DashboardWidget {
      
      }
      

      where type is optional, defaulting to the class name. Finally, to use the registry, one would simply inject it:

      @Dependent
      public class Dashboard {
        
        @Inject DashboardRegistry dashboardRegistry;
      
        public void loadDashboard( Object id ) {
      
          DashboardWidget dw = dashboardRegistry.getRegistered( id );
          addWidgetToDashboard(dw);
        }
      }
      

      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:

      @ApplicationScoped
      public class DashboardRegistryImpl implements DashboardRegistry {
      
         @Inject Provider<DashboardWidget1> dashboardWidget1;
         @Inject Provider<DashboardWidget2> dashboardWidget2;
      
      
         public DashboardWidget getRegistered( Object o ) {
      
            if( o.equals("w1")) {
               return dashboardWidget1.get();
            }
            else if (o.equals("w2") ) {
               return dashboardWidget2.get();
            }
         }
      }
      

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Mike Brock
            Reporter:
            Josh B
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: