Organizzare una app per differenti usi

In questo senso:

Gli amministratori devono poter gestire in toto i dati
dell’applicazione, un CRUD completo.
In fase di amministrazione ho un determinato layout.
La stessa applicazione deve mostrare una lista dei prodotti e in
questo caso devo usare un layout ad hoc, i prodotti possono solo
essere visualizzati.
In pratica i controller e le action sono le stesse per ambedue le
situazioni, cambiano i layout e devo impedire la possibilita’ di
creare o modificare i prodotti se in fase di visualizzazion.
In questi casi e’ meglio utilizzare gli stessi controller e views
inserendo dei controlli per impedire l’uso delle action/views create,
update, ecc.
o sarebbe meglio creare direttamente dei controller/views specifici?

2011/11/21 Mauro [email protected]

In questo senso:

Gli amministratori devono poter gestire in toto i dati
dell’applicazione, un CRUD completo.
In fase di amministrazione ho un determinato layout.
La stessa applicazione deve mostrare una lista dei prodotti e in
questo caso devo usare un layout ad hoc, i prodotti possono solo
essere visualizzati.

Scusate tutti, mi butto :smiley:

E’ possibile dividere i layout tra fase di amministrazione e fase di
visualizzazione? Perch se la amministrazione la metti sotto un uri del
tipo ‘http://ilmiosito.it/amministrazione’ hai gi risolto in fase di
routing, visualizzi layout diversi.

Altrimenti ci sono un bel po’ di plugin ed helper gi pronti che ti
possono
aiutare in questo, per in questo caso lascio la parola ai pi esperti,
sono ancora troppo poco bravo.

Saluti
Riccardo

2011/11/21 Duncan [email protected]:

2011/11/21 Mauro [email protected]

In questo senso:

Gli amministratori devono poter gestire in toto i dati
dell’applicazione, un CRUD completo.
In fase di amministrazione ho un determinato layout.
La stessa applicazione deve mostrare una lista dei prodotti e in
questo caso devo usare un layout ad hoc, i prodotti possono solo
essere visualizzati.

Si ok, visualizzare layout diversi in base al path, al controller,
ecc. non e’ un problema.
Mi chiedevo invece se fosse il caso di utilizzare gli stessi
controller/actions/views per entrambe le situazioni inserendo dei
controlli per inibire alcune actions se si e’ in fase di
visualizzazione oppure se sia meglio creare direttamente dei
controller/actions/views appositi per la parte dedicata alla sola
visualizzazione.

2011/11/21 Mauro [email protected]

essere visualizzati.

Duplicare il codice sempre da evitare, sempre meglio un controllo in pi
che due oggetti che fanno cose simili, almeno personalmente.

Saluti
Riccardo

Il 21 novembre 2011 12:32, Mauro [email protected] ha scritto:

In pratica i controller e le action sono le stesse per ambedue le
situazioni, cambiano i layout e devo impedire la possibilita’ di
creare o modificare i prodotti se in fase di visualizzazion.

Ciao,
ma solo questione di layout? Cio, ci sono i layout di
visualizzazione che non mi mostrano i link, ma io vado lo stesso alle
action giuste, che succede? Riesco a modificare le cose?

Cosa distingue la fase di amministrazione dalla fase di visualizzazione?

pietro

2011/11/21 Duncan [email protected]:

La stessa applicazione deve mostrare una lista dei prodotti e in
visualizzazione.

Duplicare il codice sempre da evitare,

Pero’ alle volte rende le cose piu’ semplici da gestire.

Se non vuoi duplicare il codice, forse una via potrebbe essere usare
cancan
https://github.com/ryanb/cancan

Luigi

Ciao,

perch non sfruttare l’ereditariet? Da un controller di base erediti
due controller, specializzandoli per i diversi contesti in cui gli
utenti devono lavorare.

Ciao,
Silvano

2011/11/21 Mauro [email protected]:

creare o modificare i prodotti se in fase di visualizzazion.
In questi casi e’ meglio utilizzare gli stessi controller e views
inserendo dei controlli per impedire l’uso delle action/views create,
update, ecc.
o sarebbe meglio creare direttamente dei controller/views specifici?


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Considera l’ambiente prima di stampare questa email. Be a total user
rather than a complete waster.

. . . Silvano S. . . .
email: [email protected]
site: http://www.sistrall.it

On Mon, Nov 21, 2011 at 2:31 PM, Luigi M. - grigio.org <
[email protected]> wrote:

Se non vuoi duplicare il codice, forse una via potrebbe essere usare
cancan
https://github.com/ryanb/cancan

  • lo consiglio anche io

2011/11/21 Pietro G. [email protected]:

Cosa distingue la fase di amministrazione dalla fase di visualizzazione?
Che a parte il layout la fase di amministrazione e’, appunto di
amministrazione, cioe’ viene chiesta una user e password e gli admin
possono creare, modificare, cancellare e ovviamente anche visualizzare
i prodotti.
La fase di visualizzazione invece non prevede un login e gli utenti
via internet possono solo visualizzare la lista dei prodotti e i
relativi dettagli oltre a poter fare delle ricerche, non devono in
alcun modo poter intervenire sui dati.

Ciao Mauro,

se vai qui: http://guides.rubyonrails.org/layouts_and_rendering.html,
2.2.12.3 Conditional Layouts, puoi vedere come caricare layout
differenti in base alla action. Per quanto riguarda filtrare le action
in base all’utente, se admin oppure no, puoi usare un semplice before
filter:

before_filter :require_admin, :only => [:create]

private

def require_admin
  redirect_to '/' unless admin?
end

CanCan ti permette di dare i permessi in modo piu` granulare, ma per
quello che vuoi far te ti basta un admin? nel model user.

2011/11/22 Mauro [email protected]

   %th= t "name".titleize

quindi non un admin, quindi con un layout dedicato alla
%th= t’ quantity’

scusa e se questi dettagli aggiuntivi li metti in una partial view e li
dentro metti il controllo se l’user admin o meno, nel template
principale
ti rimane solo la chiamata per il redering della partial
oppure fai il controllo nella view principale e fai due partial diverse
a
seconda che l’utente sia o meno admin

2011/11/22 Riccardo T. [email protected]:

private

def require_admin
redirect_to ‘/’ unless admin?
end

CanCan ti permette di dare i permessi in modo piu` granulare, ma per
quello che vuoi far te ti basta un admin? nel model user.

Si e’ vero posso fare un controllo in base ai ruoli.
Pero’ mi trovo nella situazione in cui o dupplico il codice usando un
controller apposito oppure riempio le views di if.
Esempio molto semplice:
Nella index di product ho:

%table
%thead
%tr
%th= t “name”.titleize
%th= t ‘category’.titleize
%th= t ‘price’.titleize
%th
%th
%th
%tbody
= render @companies

Ora supponiamo che nella visualizzazione di questa tabella volessi
avere maggiori dettagli se viene richiamata da un utente qualsiasi,
quindi non un admin, quindi con un layout dedicato alla
visualizzazione dei prodotti su internet.
Dovrei fare qualcosa del genere:

%table
%thead
%tr
%th= t “name”.titleize
%th= t ‘category’.titleize
%th= t ‘price’.titleize
- if !user_signed_in?
%th= t’ quantity’
%th= ‘…’
%th
%th
%th
%tbody
= render @companies

Dovrei quindi riempire di controlli del genere tutte le view se le
devo personalizzare in base alla situazione.
A questo punto penso sia meglio fare un controller/view apposito, o no?

Il 22 novembre 2011 10:48, Mauro [email protected] ha scritto:

Dovrei quindi riempire di controlli del genere tutte le view se le
devo personalizzare in base alla situazione.
A questo punto penso sia meglio fare un controller/view apposito, o no?

Ciao,
a questo punto solo questione di gusti/comodit: alcuni preferiscono
tenere completamente separati sito pubblico e backoffice, anche con
stili totalmente differenti; altri apprezzano di pi che gli admin
abbiano lo stesso sito ma “arricchito”.

Gusti a parte, per, la prima opzione in genere pi semplice da
realizzare, sia perch si hanno meno controlli (fai un
Admin::BaseController che filtra gli utenti e poi tutti gli altri
controller admin discendono da quello, e cos niente pi if
dappertutto), sia perch cos non devi preoccuparti che il layout stia
bene sia con i controlli aggiuntivi che senza.

pietro

Se il problema è eliminare le “if” dai template il discorso è diverso.

Puoi fare dei partial per utente, amministratore,… header, footer
riguardanti la tabella o i campi in cui differiscono e poi richiamarli
dove servono

show.html.erb

<%= render “header_#{user.role}” %>

.. <%= render "fields_#{user.role}" %> ...

quindi implementare:
_header_amministratore.html.erb
_header_utente.html.erb
_fields_amministratore.html.erb
_fields_utente.html.erb

Quindi ad un’azione comune c’é un solo workflow che viene montato a
seconda della tipologia di utente… e senza if.

2011/11/22 Luigi M. - grigio.org [email protected]


Quindi ad un’azione comune c’ un solo workflow che viene montato a
seconda della tipologia di utente… e senza if.

bella soluzione, me la devo segnare, un uso delle partial che non avevo
mai trovato

Sì, come soluzione rimane pulità, devi solo fare attenzione che l’utente
abbia un valore di default e che il template esista anche se non
aggiunge niente alla vista.

Luigi

Riccardo L. wrote in post #1033088:

2011/11/22 Luigi M. - grigio.org [email protected]


Quindi ad un’azione comune c’ un solo workflow che viene montato a
seconda della tipologia di utente… e senza if.

bella soluzione, me la devo segnare, un uso delle partial che non avevo
mai trovato

2011/11/22 Luigi M. - grigio.org [email protected]

S, come soluzione rimane pulit, devi solo fare attenzione che l’utente
abbia un valore di default e che il template esista anche se non
aggiunge niente alla vista.

Luigi

Si, infatti, bisogna avere queste attenzioni, eventualmente, forse,
meglio dividere le partial in cartelle per profilo utente, aggiungerne
uno
diventa semplicemente copiare una directory e personalizzare le view,
ma
veramente una bischerata, come si dice da noi :smiley:

2011/11/23 Mauro [email protected]

Puoi benissimo intercettare dentro la chiamata role e verificare li se
c’
un valore valido e decidere cosa fare di conseguenza. Se uno non fa il
login poi puoi prevedere un utente di default.

2011/11/22 Luigi M. - grigio.org [email protected]:

S, come soluzione rimane pulit, devi solo fare attenzione che l’utente
abbia un valore di default e che il template esista anche se non
aggiunge niente alla vista.

Se l’utente non ha un valore di default, nel senso che per la sola
visualizzazione non faccio login (uso devise con ldap), devo per forza
controllare…if…se esiste una sessione utente oppure no per
visualizzare un partial piuttosto che un altro.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs