1 Reply Latest reply on Nov 22, 2010 7:08 AM by heikobraun

    GWT eventing API proposal

    heikobraun

      Hi,
      I'm am nearly done. The idea I have needs some discussion.
      For client - server communication, Inbound is a redundant qualifier, which is not required. Correct me, if I am wrong, but @Observes AccountActivity handles also @Observes @Inbound AccountActivity. It is consistent with the reference, it also works this way.


      For server - client communication some additional qualifier or event type is required.
      We can't observe all Objects, because event dispatcher needs to distinguish between events from server and events from client.
      In my understandance, the sequences are:
      client sends the Event to dispatcher with ErraiBuis. Dispatcher fires event using beanManager. BeanManager notifies observers on the client side.
      server fires the bean using BeanManager. BeanManager is on the server side, which can't communicate directly with FraudClient (what would be the project rationale if it can?). It uses observer method to pass the event to EventDispatcher. EventDispatcher extracts the payload and sends the message to observer on the client side.


      In my opinion we can keep Outbound to keep event payload and the only thing we need to get rid of is this:



      @Inject @Any Event<Outbound> event; event.fire(new Outbound(...));




      Server should not need to box the payload with Outbound object, the final version should be:



      @Inject @Any Event<Fraud> event; event.fire(new Fraud(...));




      The solution which sends the event from server to client without boxing would be using alternate version of EventImpl.


      I tried



      @Inject BeanManager manager;
      manager.fireEvent(new Outbound(new Fraud(System.currentTimeMillis())), new AnnotationLiteral<Any>() {});




      in AccountService and it worked, FraudClient got notified.


      To make it consistent with weld-reference I tried to Inject my custom implementation of Event with the producer method. Unfortuantelly, it did not work. EventImpl was still injected into AccountService. My provider was following:
        


      @Produces @Any @SessionScoped
         public Event provide() {
             return new Event() {
      




      I checked with Weld sources, Events are instantied with EventBean (which is probably why I can't overide it). Can you help me?
      There is still a question remaining, whether altering EventImpl with the other implementation of event interface is what we're looking for.


      Best,
      Filip

        • 1. Re: GWT eventing API proposal
          heikobraun

          Right, I believe we need to separate the events that are send to the client. The foremost goal is to keep client traffic to a minimum, hence the discrimination on Outbound. But that is merely a first draft.


          Another possible approach would be to drop both Outbound and Inbound qualifiers and instead keep a reference of client interests. Let me give you an example:




          public class FraudClient extends LayoutPanel {
          
            @Inject
            public Event event;
          
            [...]
          
            public void processFraud(@Observes Fraud fraudEvent) {
              responsePanel.setText("Fraud detected: " + fraudEvent.getTimestamp());
            }
          } 



          This client registers for Fraud events. If this call would create a server side subscription (amp of references), we would know what clients are actively interested in events without having to specify it on the server side.


          It also means a subscription would only be created when the LayoutPanel is actually been created. Opposed to the current solution, that sends event across the wire upon creation, regardless if there is somebody listening.