Ruolo EventBus in GWT

Question

Ho letto di questo interessante event management in GWT utilizzando EventBus e fino ad ora mi piace molto. Ma non capisco davvero il concetto quando dovrei usarlo. Tutto il tempo? Posso abusarne? Dovrei usarlo per tutto ciò che riguarda gli eventi? (?? Come comunicare tra la vista e lo strato conduttore in MVP O posso usarlo con l'evento onMouseMove Come pesante è?)

Così in una domanda: Che cosa è esattamente il ruolo di EventBus in GWT?

Answer 1

Penso che l'uso del globale EventBus per la comunicazione interna tra le parti MVP di un singolo widget sia un po 'eccessivo. Ciò renderebbe il tuo widget dipendente dal eventbus. (Se il bus degli eventi non si trovava nel GWT principale sarebbe più ovvio inaccettabile.) Considero l'eventbus come il mezzo di comunicazione tra diversi widget di diverse parti dell'applicazione.

Answer 2

Sarebbe piuttosto inutile usarlo tra la vista e il presentatore, invece di fare in modo che il presentatore inviti direttamente un metodo di visualizzazione.

Credo che EventBus sia valido quando i componenti non si riferiscono tra loro, ad esempio presentatori di 2 schermate diverse.

Answer 3

Probabilmente avete visto questa presentazione I/O di Google: Google Web Toolkit Architecture: Best Practices For Architecting Your GWT App.

Esso copre le tecniche pulite per rendere più gestibile il lavoro con progetti GWT di grandi dimensioni, come l'utilizzo del modello di comando per le chiamate RPC, il pattern MVP, l'iniezione delle dipendenze e il disaccoppiamento dei componenti utilizzando il pattern EventBus. Ora ci sono diversi framework GWT che implementano questi schemi, (GWT-spedizione per il modello di comando, GWT-presentatore e GWT-piattaforma per MVP, GIN & Guice per DI), ma la cosa che mi piace del Il concetto di EventBus è che fa parte del core framework GWT (HandlerManager), quindi non devo aggiungere ulteriori dipendenze a progetti GWT più piccoli.

penso che il concetto EventBus è legato alla Observer modello di design, nel senso che si sta disaccoppiamento dei componenti Vista responsabile per ottenere l'input dell'utente dai componenti Presenter che hanno bisogno di essere avvisati su tali azioni. Il punto è che il tuo oggetto ListBox non deve sapere di tutti i componenti che sono interessati al suo cambiamento di stato, semplicemente lancia un evento sull'EventBus, e i componenti interessati riceveranno quell'evento e agiranno come vogliono.

Non penso che tu debba sempre fare le cose attraverso l'istanza di HandlerManager. Supponiamo di avere un widget personalizzato DateRangePicker, che consente agli utenti di selezionare intervalli di date personalizzati. Ogni volta che un intervallo di date viene raccolto, il widget può fare qualcosa di simile nel suo metodo onSomethingChanged():

NativeEvent event = Document.get().createChangeEvent(); 
DomEvent.fireNativeEvent(event, this); 

Poi i componenti interessati al cambio della selezione di date potrebbe semplicemente registrare callback hander alle istanze di widget DateRangePicker.

dateRangePicker.addDomHandler(new ChangeHandler(){ 
    @Override 
    public void onChange(ChangeEvent event) { 
     refresh(); 
    } 
}, ChangeEvent.getType()); 

credo che questo sia un bel design debolmente accoppiati e non fa uso di un'istanza HandlerManager.

Una progettazione errata sarebbe quella di chiamare tutti i metodi refresh() del componente interessato nel metodo onSomethingChange() di DateRangePicker invece di attivare un evento. (O peggio ancora: chiamare tutti i metodi onSomethingChange() del subcomponente dell'oggetto DateRangePicker.)