Передача данных после Header ("Location: ");

[zerkms]

Зачем долгосрочно хранить сообщение "пароль успешно изменён"? ))))))

 

[melo]

triumvirat
Хорошо, GET'ом понятно, а что если постом произошла ошибка при валидации данных?

 

[Духовность™]

triumvirat
Хорошо, GET'ом понятно, а что если постом произошла ошибка при валидации данных?

Суть та жа - объект класса Base_Redirect (который скоро переименую в Base_Notification для наглядности) просто впрыскиваю во View, в метод setRedirect(), который просто транслирует объект редиректа во View. Единственное отличие - не происходит HTTP заголовка Location

		// POST errors 
        if ($this->getView()->err = $validator->getErrors())
        {
            $redirect = new Base_Redirect();
            $redirect->setType('alert');
            $redirect->setMessage('post_errors');
            $this->getView()->setRedirect($redirect);
        }
        else // ok 
        {
          	// сохранили инфу 

            $redirect = new Base_Redirect();
            $redirect->setMessage('data_saved');
            $redirect->setRedirectUrl($this->getRequest()->getRequest()->getUri());
            return $redirect; // application ловит этот $redirect; и выполняет Location: $redirect->getRedirectUrl()
        }

 

[melo]

Я просто склоняюсь к тому, что если я разработчик и взял твою систему, то твои ошибки лежат в базе, а есть только их айдишники, вот например, у меня возникла ошибка и я хочу отыскать в коде, то место, где она получилась. Как мне найти это место?

 

[Духовность™]

Я просто склоняюсь к тому, что если я разработчик и взял твою систему, то твои ошибки лежат в базе, а есть только их айдишники, вот например, у меня возникла ошибка и я хочу отыскать в коде, то место, где она получилась. Как мне найти это место?

ты про какие ошибки говоришь?

 

[melo]

ну например есть популярная система А.
Я с ней начинаю работать, и у меня вылезла ошибка - В вашем заказе есть товар Б, но он запрещен к продаже.
Система в которой куча сервисов, и они могут отдовать свои ошибки.
Как мне найти то место в коде, которое сгенерировало эту ошибку? Ведь id я не знаю.

 

[iceman]

zerkms
с чего ты решил, что это не нормально? переадресовали на страницу с ошибкой, и что тут такого?

 

[zerkms]

iceman: потому что ты наружу выставил служебную информацию. можно показать ошибку и не изменяя урл, тогда пользователь сможет сохранить ссылку и зайти по ней завтра, когда проблема будет уже решена.

 

[tz-lom]

triumvirat: тут дело в другом, зачем в базу в принципе ложить что-то на 1 раз?

а почему нет?
не знаю как triumvirat, а я и сессионные данные в базе держу,скорость доступа нормальная,такие таблицы при необходимости можно перекинуть на оперативку,никаких проблем ни с переездом между серверами ни с несколькими серверами (и не важно авторизация или нет)
очистка сессий дело быстрое и не хлопотное,в отличии от сессий на диске
и да,ФС может медленно работать при 100500 файлах в одной папке,с БД такой проблемы нет
с другой стороны мне как пользователю всегда хочется получить ожидаемую реакцию,а не обламываться что мол сообщение не пришло из за того что я открыл страницу с ноута
и последнее
представьте себе допустим вы слажали и сессия начала загаживаться такими сообщениями,а пользователь всё ходит по сайту и ходит,а сессия всё тяжелеет и тяжелеет
в БД вы сможете мониторить такие ситуации,и легко их исправлять,а с файловыми сессиями?

 

[zerkms]

"с другой стороны мне как пользователю всегда хочется получить ожидаемую реакцию,а не обламываться что мол сообщение не пришло из за того что я открыл страницу с ноута"
флеш-сообщения имеют смысл только сейчас. если ты сразу же мгновенно закрыл страницу, не увидев сообщения - тогда не надо уже показывать пользователю через неделю, что его пароль таки изменен.

"и да,ФС может медленно работать при 100500 файлах в одной папке,с БД такой проблемы нет"
ага, субд это такая волшебная система реального времени, которая при любых обстоятельствах имеет гарантированное время отклика. это можете рассказывать новичкам, они, может, и поверят.

"представьте себе допустим вы слажали и сессия начала загаживаться такими сообщениями,а пользователь всё ходит по сайту и ходит,а сессия всё тяжелеет и тяжелеет"
ы? флеш-сообщения всегда хранятся в одной переменной. посмотрел сейчас в один из проектов - для авторизованных сессия весит около 150-200байт, это да, это просто пипец как загажено, нуну.

давайте не будем за уши притягивать ситуации, когда программер балбес, ок?

как мы промониторим - да так же как и вы, по весу сессионного файла. вас научить в линуксе выводить файлы отсортированные по размеру, или вы считаете, что это сделать сильно сложнее, чем в базе отсортировать записи по длине строки/числе записей на пользователя?

если у нас вдруг случится затык с фс (или другие проблемы) - мы всегда сможем прописать хандлер для хранения сессий в бд или (внимание) в мемкэш, а вот у вас без модификации бизнес-кода уже ничего не получится сделать.

 

[Духовность™]

zerkms, извини, но твоя реплика "Варианты с гетом я считаю как минимум кривыми, как максимум - непрофессиональными." - это ппц просто. Мир не рухнет от того, что я среди кучи других параметров передам переменную notif=123. И вдвойне не рухнент, если страница с таким URL будет запрошена ещё раз.

 

[AmdY]

уж если на то пошло, в нормальном приложении может даже не выполняться ни одного запроса к базе, зачем ради сообщения открывать коннекшин с бд и делать запрос, если сессия всё-равно открыта. без сессий я пока не научился обходиться.

triumvirat
мир не рухнет, если бы не будем совать в гет, то что нужно отобразить единожды. тем более флэш сообщения могут быть встроенны в приложения. у меня есть дивчик над контентной частью страниц, который зажжет сообщение с какой бы страницы и на какую не редиректнули, кроме того в контентную страницу можно встроить и вывести красиво с html, а не клепать каждый раз велосипед.

 

[zerkms]

triumvirat: мир рухнет - я не понимаю зачем пользователю в урл пихать служебную информацию. В этом смысле мне очень нравится REST, потому как очень воспитывает людей.

Примерно так же, как питон воспитывает нормально форматировать код.

 

[Духовность™]

triumvirat: я не понимаю зачем пользователю в урл пихать служебную информацию.

Затем, что это веб. Тут все так устроено, что параметры в сценарий передаются через вопросик. Сортировка по полю, выборка по базе и т.д. - это тоже все СЛУЖЕБНАЯ информация, однако мир до сих пор не упал.

уж если на то пошло, в нормальном приложении может даже не выполняться ни одного запроса к базе, зачем ради сообщения открывать коннекшин с бд и делать запрос

В нормальном приложении всегда есть запросы к базе. Запросов к базе нет разве что на narod.ru хостинге.

 

[zerkms]

Отнюдь нет. Указание направления сортировки - это клиентские данные. Равно как и поисковая строка.

А вот код ошибки - это информация служебная.

 

[AmdY]

triumvirat
и что мне теперь делать, переписать всё приложение и выбросить к чёрту кэш, чтобы было не как на народе? может всё же у тебя проблема в подходе?

 

[Духовность™]

проблем у меня нет. у меня отличный подход, работающий быстро и надежно. и я не вижу проблемы в том, что отлично работает и не приносит абсолютно никаких минусов.


все. мне надоело с вами спорить. отстаньте.

 

[zerkms]

Минусы тут скорее всего субъективные и "стилистические". Лично я предпочитаю в урле таскать только то, что запросил пользователь.

Т.е. если пользователь запросил страницу "профиль пользователя triumvirat" - тогда в урле будет /users/triumvirat. И даже если этот пользователь закрыл для просмотра свой профиль - то всё равно урл таким и будет, хоть и на экране отобразится ошибка.

Почему? Потому что пользователь набрал такой урл, и я достаточно уважаю пользователя, чтобы не редиректить его на страницу, которую он не запрашивал.

Пример из жизни: http://tvfedor.ru/triumvirat/privet/posmotri_kak_ya_delayu

 

[С.]

проблем у меня нет. у меня отличный подход, работающий быстро и надежно. и я не вижу проблемы в том, что отлично работает и не приносит абсолютно никаких минусов.

Есть один минус, который лично для меня портит все: нужен дополнительный сборщик мусора.