2012-10-27 13 views
5

Sto finalmente iniziando a "ottenere" GWT. In qualsiasi momento, un PlaceChangeEvent possono essere licenziati in di app EventBus in questo modo:GWT: Granularità di luoghi e ActivityMappers

History.newItem("token-for-some-new-place"); 

Questo aggiunge l'evento al bus, per cui un iscritto ActivityManager scoop su e consulta la sua interna ActivityMapper per dargli la Activity associato con PlaceChangeEvent's Place.

Il Activity (simile ad un oggetto presentatore o regolatore da MVP/MVC) ottiene quindi tutti i dati che è necessario (tramite chiamate RPC al server) ed esegue qualsiasi logica aziendale e configura la vista finale (tipicamente un Composite di alcuni sort) da visualizzare.

Finché stiamo parlando di un'app GWT super-semplice che ha solo una regione di visualizzazione nella sua pagina host, quindi come ho detto, "lo capisco".

Dove sto soffocando ora è ciò che accade quando si dispone di un'app che contiene più aree di visualizzazione (aree che possono essere aggiornate in modo asincrono l'una dall'altra).

Allora io mi chiedo:

  1. Come granulare sono ActivityMapper s dovrebbe essere? Esiste solo uno AppActivityMapper a livello di applicazione che esegue il mapping di tutti i Place s a tutte le Activity o dovrebbe esserci una sorta di gerarchia/decomposizione ActivityMapper, in cui sono presenti più mappatori? (E se la vostra risposta a questo è qualcosa sulla falsariga di "questo dipende dalle esigenze della vostra applicazione", quindi si prega di spiegare quali requisiti/bisogni di auto l'adeguato livello di granularità!)
  2. Se un Place rappresenta un token URL nella tua app (allo scopo di rendere lo stato di un segnalibro Place), cosa succede quando hai un'app più complessa con più aree di visualizzazione (D1, D2, D3). In che modo un token URL (ad esempio http://myapp.com/#token-for-some-new-place) esegue la mappatura su D1, D2 e ​​D3? Non significherebbe che ActivityMapper#getActivity dovrebbe essere in grado di restituire un elenco di attività (List<Activity>) i cui metodi start(AcceptsOneWidget, EventBus) verranno richiamati?

Grazie per qualsiasi aiuto qui - esempi di codice sempre rock.

+1

Se si utilizza luoghi, io vi consiglio di usare * solo * posti ('PlaceController. goTo() '), non il' livello' di basso livello. –

+0

Grazie Thomas ma questa è una risposta a una domanda che non ho chiesto. –

+0

Ed è per questo che lo aggiungo come commento ;-) –

risposta

5

A Place rappresenta, beh, un posto. Risponde alle domande esistenziali di da dove vengo?, dove sono? e dove sto andando?.

Per un dato luogo, lo schermo che viene visualizzato all'utente può essere complessa, ed è suddiviso in una serie di regioni di visualizzazione . Ognuno è governato da un ActivityManager, che chiede ad un di utilizzare per un dato luogo, rendendo tutto accoppiato sciolto (le attività non devono (devono) sapere dove sono utilizzate, per quale posto, quali altre attività sono in esecuzione simultanea, ecc.)

Quindi, non si avrà un mapper che restituisce un elenco di attività, ma un elenco di mappatori che restituiscono ciascuna un'attività.

See:

+0

Grazie a @Thomas Broyer (+1) - tuttavia, qui stai dicendo che esiste un "posto" a livello di pagina/schermo, mentre "ActivityManagers" e 'ActivityMappers' esistono a livello di area di visualizzazione (dove uno * schermo * è costituito da 1+ * aree di visualizzazione *). ** Ma come è possibile? ** Se le regioni di visualizzazione D1, D2 e ​​D3 possono esistere ognuna in 5 stati di segnalibri, e appartengono tutti allo stesso schermo, allora lo schermo può esistere in 5^3 = 125 stati con segnalibri! Come può un singolo posto (a livello di schermo) rappresentare 125 stati! –

+2

Non capisco cosa stai dicendo qui, ma la mia risposta incerta sarebbe: tutte le regioni di visualizzazione cambiano nello stesso momento (ciò non significa che * devono * cambiare, è possibile che alcune di esse mostrino lo stesso attività come per un altro posto, ma comunque è stata chiesta l'attività da mostrare per il posto corrente). Qui su StackOverflow, la barra dei menu (con il logo), la sezione "taggata" in alto a destra, il "bollettino della comunità", l'annuncio e il "relativo" sotto, e infine l'area principale con la domanda e le risposte; 1 URL (luogo) determina ciò che appare in ciascuna area (attività). –

+0

Ahhh ... quindi per utilizzare il mio esempio sopra, se le regioni di visualizzazione D1, D2 e ​​D3 possono esistere ognuna in 5 stati bookmarkable, allora viene fornito un URL di, ad esempio, 'http: // myapp.com/# some-state' , avranno ciascuno i propri mappatori indipendenti che sanno cosa mostrare "Activity". Ha senso, grazie! –