🚀 go-pugleaf

Użytkownik "Sergiusz Rozanski" <write-only-with-spf@sergiusz.com> napisał w 
wiadomości news:slrni0itsu.lv0.write-only-with-spf@dns.media-lab.com.pl...
> 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

Widze, ze sie nie dogadujemy. Dam wiecej szczegolow. Uzywam, jqGrid i edycji 
inline. Ma on taka ciekawa wlasciwosc, ze gdy cos nie bardzo uda sie w 
komunikacji AJAXem, przywraca automatycznie stara wartosc linijki. Niestety 
"cos nie tak" to sytuacja kiedy server zwraca blad (z tych htmlowych, np. 
500). Stad moej pytanie czyda sie pod to podpinac. Troche ono akademickie bo 
oczywiscie sa sposoby by to obejsc.