🚀 go-pugleaf

Dnia 04.06.2010 Ghost <ghost@everywhere.pl> napisał/a:
>>
>> Ale oczywiście, możesz aplikację kliencką informować o błędzie walidacji 
>> numerem 500, jeżeli taką masz ochotę. Nie jest ważne co wyślesz w 
>> odpowiedzi, "źle", "dobrze", "dupa", ważne jak aplikacja zareaguje na 
>> komunikat. Jeżeli aplikacja zrozumie komunikat "500" jako błąd walidacji 
>> to i "500" będzie dobre.
>
> No wiec, ja sie zastanawiam nad dobrymi praktykami, bo to, ze w ogolnym 
> przypadku moge to wiem. 

Dobra praktyka to odpowieni forward błędu w protokole konkretnej warstwy.
Warstwa http przepycha do Ciebie 500/404 itd i Ty podejmujesz decyzje co z
tym robić dalej np dla 404 otwierasza jakiegoś defaulta albo pchasz ten błąd
wyżej w ostateczności na konsole usera np alert. Natomiast jak serwer odwalił
swoją robotę w http należycie, a przesyłasz błąd walidacji czegoś tam ze
serwera (Twojego np w cgi czy php) do klienta (Twój sktypt) to ubierz to w
swoje ramki.
Ja praktykuję wysyłanie danych w xml albo w poleceniach js (cel ajaxa w eval).
Wtedy błąd śle np w error='1.1 Błąd taki czy inny'; albo tag <blad/> dla xml

-- 
"A cóż to za sens kupować samochód, żeby jeździć po asfalcie? 
Tam, gdzie jest  asfalt, nie ma nic ciekawego,  a gdzie  jest 
coś ciekawego, tam nie ma asfaltu".
               Strugaccy - Poniedziałek zaczyna się w sobotę.