2013-02-26 5 views
7

Sto leggendo nella scelta del framework lato client corretto per segmentare/modularizzare il mio codice di frontend in Widget.Moduli di marionette di backbone come widget simili a Twitter Flight

Fondamentalmente quello che ho/voglio è:

  • un sito web complesso con molteplici pagetypes, quindi nessuna applicazione di una sola pagina.
  • tutte le pagine sono in grado di visualizzare una pagina completa SENZA l'uso di javascript. IOW: javascript è usato solo come arricchimento.
  • Un sacco di pagine ha un modo molto dinamico in cui i widget possono essere visualizzati sullo schermo. Per superare la complessità a livello di server-side che ho modulare il mio codice in widget (composite), in cui ogni widget è responsabile per il proprio:
    • lato server codice del controller
    • lato server di template (utilizzando Hogan/baffi)
    • endpoint di routing, se dovesse avere bisogno di essere chiamato dal client
    • css strutturale (css converning la struttura del widget in contrasto con l'aspetto & feel)
  • un lato server Regio n Manager in definitiva decide quali widget sono renderizzati e dove vengono visualizzati sullo schermo. Endresults è che RegionManager sputa l'intero html (generato dal server) come il composito del rendering di tutti i suoi widget.

Ora, alcuni di questi widget hanno una logica lato client e richiedono il rerendering sul client. Prendi una pagina di ricerca, ad esempio, che deve essere in grado di aggiornare tramite ajax. (Ho descritto questo processo, che utilizza i modelli DRY su client e server, here)

Quello che alla fine voglio è che, dato che utilizzo già il pattern composito sul server, estendilo in qualche modo al client in modo che un Widget (1 blocco logico particolare sullo schermo) contiene tutto il codice lato server menzionato, più tutto il codice lato client necessario.

Spero che abbia senso.

Marionette sarebbe adatta per essere utilizzata come struttura client side in questo scenario? Chiedo perché non sono sicuro al 100% se il concetto di un modulo marionette è quello che descrivo come un widget nello scenario sopra. (Menziono Twitter Flight nella mia domanda, dal momento che ritengo che sarebbe un errore, ma al momento è così nuovo che sono titubante ad accettarlo al momento_

Penso sostanzialmente a ciò che sto chiedendo è se qualcuno ha qualche esperienza facendo qualcosa in questo modo:

+2

Twitter ha affermato di aver già utilizzato Flight nelle proprie applicazioni web, quindi mentre il suo open-sourcing è nuovo, non è di per sé nuovo di per sé. Se pensi che sia adatto a te, dovresti provarlo. Penso che si adatti al "Javascript è usato solo come arricchimento" più di Marionette. – Greg

+3

Non ho esperienza con Flight, quindi non posso parlarne. 'Marionette' è probabilmente eccessivo per quello che stai cercando di fare, ma un' Backbone.View' può essere utile per la manipolazione del DOM. L'uso di un modulo 'Backbone.View' aiuta a organizzare il codice e ad estendere le manipolazioni del DOM a un elemento. – mnoble01

risposta

2

Penso che usare Backbone.js sia perfetto per questo tipo di applicazione che stai descrivendo, probabilmente lo hai già letto, ma la maggior parte della letteratura backbone è incentrata su le tue visualizzazioni hanno associato i modelli e le collezioni JSON generati dal server, quindi utilizzando la funzione di rendering Visualizza per generare (sul client) l'interfaccia utente HTML che rappresenta il modello/collezione

H tuttavia non è possibile utilizzare in questo modo. In effetti, non c'è nulla che ti impedisca di collegare viste a elementi esistenti che già contengono contenuti, il che ti offre tutti i vantaggi della modularità di Backbone, del sistema di eventi e così via. Uso spesso viste che non hanno modelli o collezioni, semplicemente perché mi piace la conformità dello stile.Ho anche utilizzato un approccio come quello che descrivo di seguito nei casi in cui ho dovuto lavorare con vecchie applicazioni esistenti che non hanno ancora ottenuto, o che non avranno mai una bella API REST, ma forniscono contenuto in HTML.

In primo luogo, consente di assumere il seguente codice HTML rappresenta uno dei i widget:

<div id="widget"> 
    <div class="widget-title"></div> 
    <div class="widget-body"> 
     <!-- assume lots more html is in here --> 
     <a href="/Controller/DoWidgetStuff">Do something!</a> 
    </div> 
</div> 

In questo caso, è possibile utilizzare la spina dorsale con un unico Widget modello. Questo sarebbe un modello molto semplice, in questo modo:

App.WidgetModel = Backbone.Model.extend({ 
    intialize: function() { 
     this.url = this.options.url; 
    } 
}); 

Prendere atto del fatto Widget riceve un URL come parametro per la sua funzione di costruzione/inizializzazione. Questo modello di widget rappresenterebbe molti dei tuoi widget (e ovviamente potresti adottare questo approccio generale con modelli più complicati e cogliere dati diversi dall'HTML reso). Quindi, per le tue opinioni. Come probabilmente saprai, normalmente passi la maggior parte delle visualizzazioni di un modello o di una collezione quando le istanziate. Tuttavia, in questo caso, è possibile creare il modello Widget in del vostro vista funzionale inizializzazione e passarlo un URL dal pre-rendering HTML come segue:

App.WidgetView = App.View.ComboboxView = Backbone.View.extend({ 

    initialize: function() { 

     this.model = new App.WidgetModel({}, { url: this.$("a").attr("href") }); 

    } 

    // rest of the view code 

}); 

Così istanziare la vista sarebbe qualcosa di simile:

new App.WidgetView({el: $("#widget")})' 

Eseguendo tutto quanto sopra, puoi fare praticamente tutto ciò che ti offre il backbone e il suo modulare e incapsulato, che è quello che cerchi.

Il risultato finale di tutto questo approccio è:

  1. Hai reso il Widget UI come puro HTML che (presumo) è funzionale senza JavaScript.
  2. Si allega una visualizzazione all'HTML esistente.
  3. Si passa alla vista come opzioni, contenuto estratto (come un URL) dall'HTML di rendering con jQuery.
  4. La vista è responsabile dell'istanziazione del modello che trasmette le opzioni pertinenti richieste dal modello (come un URL).
  5. Ciò significa che tutto il contenuto dinamico del lato server è contenuto inizialmente nell'HL reso e il tuo View è un componente JavaScript modulare che può fare roba ad esso, che credo sia il risultato finale che stai cercando.

Quindi hai detto che ti piacerebbe avere la funzionalità AJAX per i tuoi widget e che va bene anche con questo approccio. Utilizzando questo approccio, ora puoi utilizzare le funzioni standard Backbone fetch e save sul modello Widget per ottenere nuovi contenuti. In questo esempio è dall'URL recuperato dall'HTML reso. Quando ottieni la risposta, puoi utilizzare la vista, la funzione di rendering o altre funzioni a grana fine per aggiornare l'HTML sulla pagina come richiesto.

alcuni punti:

L'unica cosa da guardare fuori per è che è necessario cambiare il tipo di contenuto dei fetch e save funzioni di "text/html", se questo è ciò che il server è fornendo. Ad esempio:

this.model.fetch({ 
    type: "POST", 
    contentType: "text/html" 
}); 

Infine, il modello che ho proposto è istanziato senza contenuto.Tuttavia, se le tue chiamate ajax sono un tipo di contenuto di "text/html", potresti aver bisogno di giocare con il tuo modello in modo che possa archiviare correttamente questo contenuto nella sua collezione di attributi. Vedere this answer per ulteriori informazioni.

+0

Scusate la risposta accidentalmente inviata prima della fine. Modifica in corso :) – dcarson

+0

Tutto finito ora grazie – dcarson

+1

Inoltre, la tua domanda è piuttosto vecchia, quindi sarebbe bello sapere cosa hai effettivamente finito se lo hai già fatto. :) – dcarson

Problemi correlati