Verify i dane z modeli?

Wybaczcie za kolejne pytanie z serii"How to do it in Rails way?".

Wyobraźmy sobie system w którym użytkownicy posiadają przedmioty, mogą je dodawać, edytować i usuwać.

I w którym miejscu w kodzie powinno się “zabronić” edycji przedmiotów nie należących do użytkownika?

Wstawienie w akcjach edit,update,delete kodu “if item.user != @user” nie jest DRY (czyli jest FE :slight_smile: )
W modelu też chyba raczej tego nie powinno się robić.
A verify nie ma dostępu do zmiennych akcji (mylę się?).

A może poprostu za dużo kombinuję ? :slight_smile:

Nie wiem jak konkretnie wygląda twój kod, więc nie podam przykładu, jednak wg. mnie powinieneś skorzystać z filtrow (before_update, before_destroy, before_save) w twoim modelu, tam wpisz kod który sprawdza czy item nalezy do usera i w zaleznosci od tego pozwala wykonac operacje lub nie.

Krótko: http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M001024

Rzecz nazywa się scope. Przykład z api

Article.with_scope(:find => { :conditions => "blog_id = 1" },// :create => { :blog_id => 1 }) do Article.find(1) # => SELECT * from articles WHERE blog_id = 1 AND id = 1 a = Article.create(1) a.blog_id # => 1 end
Rzecz jest bardzo przyjemna i spełnia Twoje wymagania.

Dodatkowo wlasciwie bedzie tez pobierac tylko to co nalezy do usera np:
current_user.items.find …

A w roznych przypadkach moze przydac sie prosty helper w stylu:

def owner?
item.user == current_user
end

if item.owner?

[quote=tczubinski]A w roznych przypadkach moze przydac sie prosty helper w stylu:

def owner?
item.user == current_user
end

if item.owner?[/quote]
Proponujesz sprawdzać czy user jest właścicielem pobranych itemów? Jeśli tak to nie ma potrzeby w chwili gdy założysz scope. Piękno tego sposobu polega na tym, że aplikacja nie pobierze nic, czego user nie jest właścicielem (jeśli oczywiście taki postawisz warunek). Nie ma potrzeby duplikować funkcjonalności ani sprawdzać warunków, które zawsze będą prawdziwe.

Dzięki chłopaki!

Tutaj trochę więcej o with_scope
http://habtm.com/articles/2006/02/22/nested-with_scope

Na wielu blogach sa dyskusje n.t with_scope aby uzywac tylko za potrzeba.

Zgadzam sie takze z Marcinem, ze tutaj bedzie idealny with_scope.