[Rails] organizzare Controller e View tra "pubblico" e "privato"

[CozzaAmara]

Ciao a tutti,

avrei bisogno di qualche indicazione su come è meglio organizzare i propri file in un'applicazione Rails che preveda (come in un classico sito web) un aspetto "pubblico" (il sito visibile agli utenti) ed uno "privato" (di solito il CMS).

Con Rails è la prima volta che approccio ad un Framework ed è la prima volta che mi trovo di fronte al pattern MVC.

Mi spiego meglio: di solito sono abituato ad avere tutti i file template che compongono un sito sotto la root dello spazio web mentre l'interfaccia gestionale in una sottodirectory come ad esempio "/cms/".

Da ciò: ipotizziamo che tutto quello che creo in prima istanza con Rails Model/Controller/View siano considerabili come il CMS stesso, difatti non ho solo viste Index, Show ma anche New ed Edit.

Se, come molto probabile, volessi creare delle View o dei Controller appositi differenti per l'interfaccia "pubblica" come mi dovrei comportare?

es: Products => ho tutte le mie action e view come da prassi nelle varie sottodirectory ma se volessi mostrare all'utente dei template HTML diversi? Piuttosto che avere un Controller che non abbia, ovviamente, action come: new, update, delete ecc. da dove dovrei partire?

Non è facile da spiegare anche se in se quello che intendo è molto semplice.

Grazie in anticipo.

[andrea.paiola]

se vuoi l'amministrazione separata dal sito normalmente si sviluppa a livello di route e poi ovviamente views diverse ... dovrebbero esserci dei tutorial online

intanto guardati questo http://stackoverflow.com/questions/1...ation-in-rails

[CozzaAmara]

Ti ringrazio, è quello che avevo stavo leggendo anch'io.

Una soluzione pare quella di creare dei namespace per Controller e Viste.

Es:

ruby script generate controller admin/products

Questo genera automaticamente una sottocartella "/admin/" sotto la "app/controller" ed "app/views".

Un'altra soluzione che ho notato è quella di usare un'unico controller e gestire l'accesso ad azioni "sensibili" come: new/create/update/delete solo per un'eventuale amministratore loggato.

Il tutto gestito da dei "before_filter" in cima al Controller per verificare se un'utente ha o meno le credeziali per eseguire una determinata "action".

Tuttavia questa opzione lascia si il codice più centrallizzato ma ... pure troppo a mio modo di vedere, si rischia forse di avere "troppa carne al fuoco" in un'unico controller che dovrebbe gestire sia l'aspetto "public" che di "private" (CMS).

Che ne pensate?

[andrea.paiola]

penso che si voglia la libertà di scelta ed è quello che si ha

[weppos]

Molto dipende dalla tua applicazione. Se l'integrazione tra le aree di admin e l'area pubblica sono seamless allora usa un controller unico. Se prevedi un sistema classico stile CMS con aree pubbliche ed aree private ad esclusivo uso di admin/editori, allora sdoppia i controller.

[toraz]

Originariamente inviato da weppos
Se l'integrazione tra le aree di admin e l'area pubblica sono seamless

Perdona l'ignoranza, per seamless intendi?

Comunque la faccenda mi pare spinosa. Ovvero, se quello che si vuole gestire è modellato come una risorsa la cosa più ben fatta che si possa fare, secondo me, è usare un unico controller (con tutti i metodi del caso) per gestirla. Poi ci sarebbe da trovare un sistema raffinato per gestire diversi privilegi e il rendering di diverse viste tutto all'interno dello stesso controller. Per non parlare poi del fatto che ci sarebbe da accedere allo stesso metodo da URL diversi. Ho tutto piuttosto confuso in testa ma mi pare una faccenda interessante. Mi avete trovato un passatempo nuovo!

[weppos]

Originariamente inviato da toraz
Perdona l'ignoranza, per seamless intendi?

Mi spiego meglio con un esempio diretto che ci è capitato non più di qualche mese fa in azienda.

Immagina un prodotto tipo questo http://asp.weppos.it/asp/scripts. E' una semplice app che ho scritto in Rails che, tra l'altro, presenta ancora il "difetto" che vado a documentare.

Immagina che la tua app sia un progetto tipicamente editoriale (backend e front-end separati) ed abbia da un lato un'interfaccia pubblica e dall'altro una di amministrazione. Immagina che l'utente possa accedere solo all'action #show e #index mentre solo l'amministratore abbia accesso a #new, #edit, #update e #destroy.

Ci sono due modalità:

1. creare un unico controller e gestire all'interno i vari permessi miscelando frontend e backend
2. creare due controller, uno di admin ed uno pubblico

Quando le due anime sono nettamente separate, come in questo caso e nel caso del progetto che ho linkato, personalmente preferisco la seconda ipotesi. Prendi infatti l'azione #index.
Spesso all'amministratore si offre un layout semplice, magari a tutta pagina, con una comoda form di ricerca ed un listing senza fronzoli completo con funzioni avanzate. Ma come fare in questo caso, che la index è anche usata dal lato pubblico per mostrare la lista degli articoli corredata da categorie, pubblicità ed altro?

Non parliamo poi dell'action #show. In quel caso ci sono diverse complicazioni. innanzi tutto ho implementato i permalink che quindi non passano attraverso il classico identificatore params[:id]. In secondo luogo, l'app è una sola ma gestisce in contemporanea l'inglese e l'italiano (http://asp.weppos.it/asp/scripts, http://asp.weppos.com/asp/scripts). Io voglio dal lato amministratore gestire tutte le risorse in contemporanea, lato utente poterle invece filtrare a seconda della ligua in modo tale che http://asp.weppos.it/asp/scripts/motore-vbscript non esista all'indirizzo http://asp.weppos.com/asp/scripts/motore-vbscript o, meglio ancora, possa essere riutilizzato per identificare due risorse completamente identiche.

In questo caso, usare un controller unico è molto complicato. Finisci per infilare nel controller decine di action aggiuntive (#permalink, #index_admin ...), controlli rindondanti (admin_required except, user_required only)... In questo caso il mio consiglio è di andare assolutamente con due controller. Uno verrà mappato come resource classica mentre l'altro con namespace

map.resources :scripts
map.namespace :admin do |admin|
  admin.resources :scripts
end

Questo consente una gestione molto più flessibile. Ad esempio puoi scegliere di nidificare risorse in lato pubblico (scripts/1244/comments) ma lasciarli autonomi in admin per gestirli con più flessibilità).

Diverso è il caso in cui non esista una netta separazione tra lato pubblico ed admin. Dove, ad esempio, non esiste un solo amministratore ma l'utente è a sua volta amministratore ed utente a seconda della risorsa o del ruolo.
In quel caso l'admin diventa un tutt'uno con l'app e non ha senso sdoppiare i controller.

Ad ogni modo, a mio avviso è questione di pratica e scopo. La regola DRY non va mai portata all'eccesso. A volte, per riutilizzare un controller/parziale/elemento nel tentativo di non duplicarlo, si rischia di aggiungere più complessità che a clonarlo.

[toraz]

Diamine, così la complichi parecchio la faccenda!

[weppos]

Originariamente inviato da toraz
Diamine, così la complichi parecchio la faccenda!

Ti assicuro che è più complesso a dirsi che a farsi.
E soprattutto, è molto più flessibile e mantenibile.
Altri esempi http://www.akitaonrails.com/2007/12/...-full-tutorial

[CozzaAmara]

Scusate ancora una cosa: ho provato appunto a sdoppiare controller e viste come detto tramite un namespace "Admin::" e funziona tutto bene.

Poi mi sono detto, se avessi bisogno di sdoppiare anche i Model?

Avendo un Controller "Admin::ProductsController" ho notato che lo stesso si riferiva comunque al Model "Product", ho creato poi un Model "Admin::Product" e a quel punto ho notato che il Controller ha cominciato a prendere (immagino giustamente) quest'ultimo come riferimento.

La mia domanda è: questo comportamento è "by desgin" ciò è voluto o cosa?

Messa così sembra che il Controller cerchi un Model con lo stesso Namespace, se non lo trova passa al Model generico, può essere?

Spero che la mia domanda non sia troppo idiota ma devo cercare di capire bene ogni principio di RoR se possibile.