Nella progettazione di gestione dei ruoli si è cercato di ottenere un’architettura fa-cilmente estendibile da incrementi di funzionalità futuri nel sistema. Inoltre, si è cercato di mettere in pratica una serie di best-practices del frameworkRuby on Rails.
L’approccio alla progettazione è basato sulla design patternMVC. La scelta è dovuta alla volontà di utilizzare il framework e il linguaggio al meglio delle loro possibilità, senza snaturare i comuni design pattern forzandone l’utilizzo e verrà trattata in modo approfondito nelle sezioni seguenti.
3.4.1 Soluzione
Model
Model è lo strato del sistema responsabile per rappresentare dati aziendali e la logica.
InRuby on Railsmeccanismi di pluralizzazione sono molto potenti, essendo in grado di pluralizzare (e singolarizzare) sia parole regolari e irregolari. Quando si utilizzano nomi di classi composte da due o più parole, il nome della classe del modello dovrebbe seguire le convenzioni diruby, utilizzando la formaCamelCase. Convenzioni di denominazione:
∗ Classe di Modello - Singolare con la prima lettera di ogni parola in maiuscolo (ad esempio, BookClub).
figura 3.3: Architettura generale del modello
Nome: User;
Descrizione: Classe che modella un utente del sistema;
Utilizzo: Fornisce tutte le informazioni di un utente nel sistema;
Relazioni principali con altre classi:
∗ has_one Role.
3.4. PROGETTAZIONE 13 Nome: Role;
Descrizione: Classe che modella un ruolo del utente;
Utilizzo: Fornisce tutte le informazioni di un ruolo nel sistema;
Relazioni principali con altre classi:
∗ belongs_to User;
∗ has_one Permission.
Nome: Permission;
Descrizione:Classe che definisce i metodi necessari per la gestione dei permessi;
Utilizzo: Fornisce tutte le informazioni sui permessi di un utente nel sistema;
Relazioni principali con altre classi:
∗ belongs_to Role.
Nome: UserAbilities;
Descrizione: Classe che modella permessi di un utente con ruolo base User ; Utilizzo: Fornisce tutte le informazioni sulle abilità di un ruolo con base User nel
sistema;
Relazioni principali con altre classi:
∗ extend Permission.
Nome: ModeratorAbilities;
Descrizione: Classe che modella permessi di un utente con ruolo base Moderator;
Utilizzo: Fornisce tutte le informazioni sulle abilità di un ruolo con base Moderator nel sistema;
Relazioni principali con altre classi:
∗ extend PermissionsList::UserAbilities.
Nome: AdministratorAbilities;
Descrizione: Classe che modella permessi di un utente con ruolo base Administrator;
Utilizzo: Fornisce tutte le informazioni sulle abilità di un ruolo con base Admini-strator nel sistema;
Relazioni principali con altre classi:
∗ extend PermissionsList::ModeratorAbilities.
Nome: SuperAdministratorAbilities;
Descrizione: Classe che modella permessi di un utente con ruolo base
SuperAdmini-14 CAPITOLO 3. GESTIONE DEI RUOLI Utilizzo: Fornisce tutte le informazioni sulle abilità di un ruolo con base
SuperAd-ministrator nel sistema;
Relazioni principali con altre classi:
∗ extend PermissionsList::AdministratorAbilities.
Controller
Dopo che router ha determinato quale controller da utilizzare per una richiesta, il controller è responsabile per dare un senso alla richiesta e produrre l’output appropriato.
Per fortuna, Action Controller fa la maggior parte del lavoro base per voi e usa le convenzioni intelligenti per rendere questo più semplice possibile.
La convenzione di denominazione di controller in Rails favorisce pluralizzazione del l’ultima parola nel nome del controller, anche se non è strettamente necessario (ad esempio ApplicationController). Ad esempio:
∗ ClientsController è preferibile rispetto a ClientController;
∗ SiteAdminsController è preferibile rispetto a SiteAdminController oppure Site-sAdminsController.
A seguito di questa convenzione consentirà di utilizzare i generatori di percorso di default (ad esempio "resources", etc) senza la necessità di qualificare ogni percorso al controller, e manterrà l’utilizzo diURL e ilhelpersdi percorso coerente in tutta l’applicazione.
figura 3.4: Architettura generale del controller
Nome: RolesController;
Descrizione: Questa classe permette di gestire la pagina di gestione ruoli;
Utilizzo: Fornisce tutte le informazioni da mostrare nella pagina di gestione ruoli;
3.4. PROGETTAZIONE 15 Relazioni principali con altre classi:
∗ extend Admin::BaseController Nome: UsersController;
Descrizione: Questa classe permette di gestire la pagina di gestione utenti;
Utilizzo: Fornisce tutte le informazioni da mostrare nella pagina di gestione utenti;
Relazioni principali con altre classi:
∗ extend Admin::BaseController View
View è responsabile di visualizzare la risposta o l’uscita su un browser. Nella sua forma più semplice, una view può essere un pezzo di codice HTML che ha qualche contenuto statico. Per la maggior parte delle applicazioni, avere solo contenuti statici può non essere sufficiente. Molte applicazioni Rails richiedono contenuti dinamici creati dai controller (controller action) da visualizzare nelle loro view. Ciò è reso possibile utilizzandoEmbedded Rubyper generare template che possono contenere contenuti dinamici.
Per impostazione predefinita, i controller inRuby on Rails fanno automaticamente renderingdelle view con i nomi che corrispondono a percorsi validi.
Per esempio, se si dispone di questo codice nella classe BooksController:
c l a s s B o o k s C o n t r o l l e r < A p p l i c a t i o n C o n t r o l l e r
end
E il seguente codice nel file routes.rb:
r e s o u r c e s : b o o k s
E si dispone di un file di view app/views/books/index.html.erb:
< h 1 > B o o k s are c o m i n g s o o n ! </ h 1 >
Ruby on Railsfa automaticamenterenderingdi file app/views/books/index.html.erb quando si accede al percorso /books dell’applicazione, sul schermo verrà visualizatto
"Books are coming soon!" .
Rails cercherà automaticamente il template action_name.html.erb nel percorso views del controller e cercherà di fare rendering.
16 CAPITOLO 3. GESTIONE DEI RUOLI
figura 3.5: Pagina gestione ruoli
figura 3.6: Pagina gestione utenti
Router
Uno dei strumenti molto potenti delRuby on Railsè il suorouter, che è molto facile da usare visto che si usa la paradigma a convenzioni. Quindi è sufficiente soltanto posizionare i file del modello e i rispettivi controller e dichiarare "resources :roles" e
"resources :users" nel file routes.rb per ottenere la seguente tabella dei routes.