Witam
Czy można jakoś wpłynąć na kolejność pojawiania się błędów?
Mam kilka pól, i każde ma ustawione jakieś tam validate_of…
Pole_1, pole_2, pole_3 …
A błędy na liście pojawiają się w innej kolejności, bez żadnej prawidłowości.
Pozdrawiam.
Standardowo w Railsach kolejność walidacji niestety nie jest gwarantowana.
Mozesz to zmienic, wystarczy ze dla najnowszych Rails
ActiveModel::Errors z Hash stanie sie OrderedHash w teorii pewnie zadziala.
Jakis czas temu znalalazlem jeszcze cos takiego:
PAK a jak to wykonać, albo gdzie poszukać tematu?
Ten plik diff jest na stare railsy gdy Errors bylo jeszcze wewnetrznal struktural AR i korzystalo z grubsza ze zwyklego Hash, tam bylo latwiej. Teraz masz klase Errors ktora bazuje na ActiveModel podejrzewam ze jest wiecej zachodu ale z grubsza wystarczy ze zaimplementujesz swoja klase ActiveModel::OrderedErrors ktora dziedziczy po OrderedHash i ma te same metody co ActiveModel::Errors i jej uzyjesz w zamiast.
tak na szybko:
implementacja validacji, tam masz klase Errors ktora dziedziczy po
a tu jest klasa Errors ktora dzieczyczy po Hash
Zaimplementuj sobie OrderedErrors na bazie OrderedHash i jej uzyj
class ActiveRecord::Base
def errors
@errors ||= OrderedErrors.new(self)
end
end
To powinno sie znalesc w environment.rb po zaladowaniu twojej klasy OrderedErrors
Nie testowalem wiec nie wiem czy ActiveRecord::Base ma metode errors moze jest ona gdzie indziej, ale mysle ze to wlasiciwe miejsce.
Byc moze moj pomysl jest przekombinowany i mozna to zrobic latwiej dodajac kolejne api
http://www.chasingsparks.com/2008/01/ordering-error_.html
Jednak mi sie ten pomsyl nie podoba, lepiej wykorzystac jakos OrderedHash i kolejnosc w jakich validacje zostaly zdefiniowane, niz dodawac kolejne api do aplikacji. Warto sie tutaj pomeczyc troche.
Jak rozumiem mówisz o error_messages_for(model)
.
Dobrym rozwiązaniem jest nie używanie tej funkcji wcale. W zamian przy każdym polu umieść error_message_on
. W ten sposób problem się rozwiąże a jednocześnie formularz znacznie zyska na czytelności.
@Bragi, tylko, że jak masz więcej jak 5-7 pól to traci tą przejrzystość, nie mówiąc już o kilkudziesięciu.
Nie do końca sie z tym zgadzam. Przy tak dużej ilości pól lista błędów jedynie pogarsza sytuację, sprawiając, że formularz staje się jeszcze dłuższy.
Można uciec się do JavaScript i zrobić walidację na żywo. Wtedy każde pole jest sprawdzane w miarę wprowadzania i trudniej popełnić błąd - zwłaszcza jeśli formularz nie daje się wysłać zanim dane nie są wprowadzone prawidłowo.
Inna sprawa, że formularz nie powinien mieć kilkudziesięciu pól. Jeśli ma, to znaczy, że należy przemyśleć design - i go rozbić na drobne.
Przy okazji: utrzymywanie kolejności w liście błędów nie ma większego sensu. Oznaczałoby to, że designer jest zmuszony do umieszczenia pól na formularzu w kolejności definicji walidacji w modelu. I odwrotnie: chcąc przestawić pola w formularzu należałoby zmienić kolejność walidacji w modelu.
Na wielu znanych mi forach takie odpisywanie na prośbę o pomoc z konkretnym problemem jest traktowane na równi z trollowaniem 
“Jak zamontować w linuksie partycję NTFS z prawami zapisu?” “Olej linuksa, zainstaluj Windows” 
PS. Najgorsze jest to, że Bragi ma sporo racji: error_messages_for to naprawdę mało fajna zabawka