atrybuty oznaczane jako safe i unsafe

Tworzę proste logowanie biorąc pod uwagę tutorial chris-backhouse.com/Cook-your-own-User-Authentication-in-Yii-–-Part-1/989

Mam w bazie m.in. pole z uprawnieniami użytkownika, więc niedopuszczalne jest, aby użytkownik zmodyfikował formularz i podczas rejestracji zmienił to pole. Jeżeli pojawi się jakiekolwiek warunek w rules() to automatycznie pole oznaczane jest jako "safe"?

Jaki jest najlepsze podejście, aby takie pola były automatycznie przypisywane tylko dla określonych akcji, a dla reszty ignorowane?

Najlepszym sposobem jest wykorzystanie scenariuszy.

Zerknij na to http://www.yiiframework.com/wiki/266/understanding-scenarios/

Ok. Mam pytanie odnośnie kwestii dobrego podejścia przy większej ilości scenariuszy. W przypadku użytkowników mamy m.in. logowanie, rejestrację, aktualizacja profilu, przypomnienie hasła, aktualizacja profilu przez administratora. Tworzenie 5 scenariuszy trochę imho zaciemni reguły.

Jak Wy do tego podchodzicie? Trzymacie się scenariuszy, tworzycie osobne modele czy po prostu korzystać z -> zamiast przypisywać wszystko automatycznie?

@Bizley: dzięki za odpowiedź.

Dla logowania i rejestracji stwórz osobne modele dla formularzy, bo te działania nie modyfikują modelu bezpośrednio, nie ma sensu pchać ich do AR.

Czemu myślisz że 5 scenariuszy zaciemni ci reguły?

Po prostu będzie dużo wpisów.

Czemu? Jedna reguła może dotyczyć kilku scenariuszy, więc nie jest tak, że aktualną liczbę reguł mnożysz przez liczbę scenariuszy. Wystarczy odpowiednio rozplanować reguły i akcje.

Dziękuje za odpowiedź i przede wszystkim za fajne podejście.

Jeszcze zapytam odnośnie dobrych praktyk. Tworzysz osobne modele dla formularzy zawsze w konkretnych przypadkach czy raczej to podejście tzw. na oko? ;)

Jeśli formularze nie modyfikują danych bezpośrednio, zawsze tworzę dla nich osobne modele formularzy. Jeśli modyfikują tylko niektóre pola modelu (np zmiana hasła), to różnie. Czasami wygodniej jest wszystko obsłużyć w jednym modelu, czasami lepiej stworzyć nowy model dziedziczący po głównym i nadpisujący tylko reguły, a czasami lepiej stworzyć FormModel z własną obsługą zapisu do głównego modelu. Kwestia sytuacji i podejścia, ale na pewno walidacja w kontrolerze to kiepski pomysł.