Комментарии 6
Спасибо. Хотя Prototype и не пользуюсь, но будет о чем задуматься при отладке скриптов на jQuery
а если сервер ввиду какой-то мегабаги сформировал пустую выдачу?
проверять надо наличие данных, а не статус ответа.
проверять надо наличие данных, а не статус ответа.
Это уже вторая проверка, на то, что данные есть и они правильные.
Я, например, сначала смотрю на код, если это 500, значит ошибка, пытаюсь вытащить данные об ошибке оттуда в определенном формате. Если 200, значит все оки-доки, пытаюсь вытщить ответ (в общем случае, я уже знаю, что все прошло, но мне нужны «подробности»)
Я, например, сначала смотрю на код, если это 500, значит ошибка, пытаюсь вытащить данные об ошибке оттуда в определенном формате. Если 200, значит все оки-доки, пытаюсь вытщить ответ (в общем случае, я уже знаю, что все прошло, но мне нужны «подробности»)
Ну, проверять надо и то и другое, в принципе, как уже упомянули выше, но дело то немного в другом. Фреймворк то, IMHO, подглючивает. Callback в onSuccess при лежачем сервере не есть гуд. Именно эту особенность prototype программист и пытался донести...:)
в Asp.net для этого в ScriptManager есть OnTimeout, здесь такого же нету?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Prototype & Ajax.Request: важный момент при отлове проблем на сервере