2012-12-20 11 views
5

Sto ancora imparando Extjs e mvc quindi ho una domanda di progettazione che sono sicuro che qualcuno possa rispondere per me. La mia domanda è:Extjs4 idee di progettazione mvc

Ho 2 controller che gestiscono due viste differenti. Uno dei due controller viene chiamato per rendere la vista corretta in base al tipo di utente. Quindi nel mio caso, se l'utente è admin, otterrà la visualizzazione admin in base alle credenziali e se la persona un utente standard otterrà la visualizzazione standard. La logica decisionale dovrebbe essere inserita nell'app.js o dovrebbe esserci un altro controller che decide quale controller chiamare?

Un modo sto pensando:

regolatore per admin

Ext.define('adminController', { 

     // handles admin 
}) 

controller per utente standard

Ext.define('standardController', { 

     // handles standard 
}) 

App.js

Ext.application({ 
    name: 'MTK', 
    autoCreateViewport: true, 

    if(admin) { 
     controllers: ['adminController'] 
    } 
    else(std){ 
     controllers: ['standardController'] 
    } 
}); 

Un'altra idea:

regolatore per admin

Ext.define('adminController', { 

    // handles admin 
}) 

controller per utente standard

Ext.define('standardController', { 

    // handles standard 
}) 

controller principale

Ext.define('mainController', { 

    if(admin){ 
     call adminController 
    } 
    else(std){ 
     call standardController 
    } 
}) 

risposta

2

Io non lo farei (o almeno troppo di questo) questo in t lui frontend. Immagino che dovresti essere in grado di conoscere il ruolo dell'utente nel momento in cui l'utente sta effettuando l'accesso.

Per me lo faccio in questo modo, ma devo dire che ho un ACL molto più complesso e non disturberò un utente con moduli o viste in cui il back-end rifiuterà qualsiasi accesso.

Sto usando questi due approcci:

  • ricarica/redirect alla vista dell'applicazione (back-end!) Dopo un login riuscito. Il server sa cosa a portata di mano-back dalla sessione utente
  • ritorno di una configurazione dopo una strega login riuscito contiene informazioni che cosa richiede prossima (questo potrebbe essere solo un controller o alcune più classi)

entrambi gli approcci risultato in meno codice, caricamento più veloce e più facile debugging

Spero che questo ti punti nella giusta direzione.

+0

Ho già un reindirizzamento di login in atto. Credo che avrei dovuto dirlo già ma comunque, ho una sessione che ottengo le informazioni ldap dell'utente. Quindi penso che potrei usare un altro controller per determinare quale vista renderizzare. – reagan

+0

@rob Sicuramente non si potrebbe fare a meno di molte decisioni riguardanti i ruoli degli utenti o l'accesso ai controller di frontend. Dovresti risolverli sul lato server e, come ho detto, reindirizzare dopo l'accesso, una vista che viene configurata per ruolo o restituire informazioni rolena al login-cmp che cosa caricare dopo – sra

+0

grazie per il tuo aiuto – reagan

2

Interessante domanda, sono d'accordo con @sra che non è forse il modo giusto di farlo attraverso la logica lato client, anche se non è detto che non funzionerebbe.

In un'applicazione a cui ho lavorato abbiamo utilizzato l'approccio di definire tutti i controller che possono essere richiamati o meno in un controller di stile "nav".Questo è l'unico che istanziamo direttamente e quindi si basa su valori predefiniti e quindi, le interazioni dirette abbiamo scelto di rendere i controller e le viste appropriati che è un po 'come il secondo approccio suggerito da @sra.

Penso che il primo approccio di sra sia ragionevole in generale, ma il problema si presenta quando forse si ha una vista che come amministratore deve essere modificabile e come utente deve essere di sola lettura. Non vuoi scrivere due viste in questa situazione.

Una cosa che non ho provato (ma questa domanda mi ha fatto venire voglia di! nella stessa vista (per salvare il bisogno di due viste) o b) per restituire un modello più complesso con ogni proprietà dei dati accompagnata da un flag "modificabile". Questo potrebbe quindi essere usato per rendere campi diversi, o campi in diverse modalità nell'app ..... Sono consapevole che questo non risponde alla domanda, interessato all'approccio scelto e ai risultati che ti interessa segnalare!

+0

Per quanto riguarda l'output di un modello diverso: in realtà lo sto facendo nella mia prima parte, ma è un po 'complesso all'inizio. Ma posso dirti che il lavoro ha un certo fascino e che fuori dalla scatola è completamente integrato nell'ACL – sra

+0

Da uno specifico POV di implementazione, come hai scelto di produrre il modello? Forse un modello con una bandiera 'modificabile' per campo a cui la vista risponde? o una selezione di proprietà 'nome' (reso come casella di testo) e 'readonlyname' (reso come un campo di visualizzazione?) e la vista preleva solo i campi che trova? Il nostro problema più comune in Ext è il rendering delle viste in modalità ro/rw e il modo di soddisfarle, molto interessato a vedere qualsiasi pensiero sull'argomento – dougajmcdonald

+0

Proverò a spiegarlo un po 'più dettagliato: comincio guardando ogni entità come un modulo (frontend come back-end). Ciò significa che ognuno ha almeno il proprio backendcontroller (alcuni hanno solo modelli/negozi all'interno del frontend). Sotto i dati il ​​controllore può anche restituire le classi di frontend che si verificano in base all'ACL dell'utente ed è supportato dal sistema di memorizzazione nella cache per ridurre il tempo di caricamento. L'ACL ne fa un po 'parte perché è progettato per essere facilmente mainatainable da un utente (non ho bisogno di configare nulla). Questo funziona per il caricamento lento e il caricamento completo dell'app. – sra

0

Penso che, come giustamente sottolineato sra, il server ti invii le giuste informazioni sul tipo di utente che ha effettuato l'accesso. Sul lato client, lascia che un controller decida quale vista visualizzare. Questo dovrebbe essere lo stesso controller che gestisce la pagina di accesso. CARD VIEW è il layout che puoi usare a questo scopo. dopo che la pagina è stata renderizzata, l'altro controller si occuperà degli eventi attivati ​​in quella vista

E in qualsiasi modo il controller non dovrebbe eseguire la parte di rendering che è il lavoro di visualizzazione utilizzare il controller solo per reagire agli eventi attivati ​​in la vista

Problemi correlati