[web, flame] где хранить инфу? в странице или в куках? [re: php]
Скрытые инпуты для сохранения какой то инфы между реквестами - это песец, если только sessionid (и то лучше в куки).информация относится к странице, поэтому она и должна хранится в странице, а не в сессии и не в куках
но это все равно wrong way 
Постоянно возникает такая потребность, постоянно прописываю хиддены на странице и корю себя за это
Постоянно возникает такая потребность, постоянно прописываю хиддены на странице и корю себя за это но это все равно wrong wayпочему? hid-поля и сделаны для того, чтобы хранить данные в странице
слишком открыто имхо, в куках же хранить безопаснее, они для того и придуманы
в хидденах можно хранить что-то вроде action, todo и прочих вещей, которые и так понятны, видны, но никак не зависят от userID.
куки предназначены для хранения данных о пользователе на стороне самого пользователя.
о пользователе!, а не об отдельной странице.
если инфу, которая предназначена для страницы, хранить в куке или в сессии, то сразу перестает работать куча сценариев: например, перестают нормально работать кнопки вперед/назад
о пользователе!, а не об отдельной странице.
если инфу, которая предназначена для страницы, хранить в куке или в сессии, то сразу перестает работать куча сценариев: например, перестают нормально работать кнопки вперед/назад
вот этим, кстати, меня бесит ФБ: при просмотре фоток я "вперед-назад" ухожу совсем не туда, куда хотел бы
информация относится к странице, поэтому она и должна хранится в странице, а не в сессии и не в кукахВ общем то, для php, при подходе "пляшем от страницы, и всё, что касается страницы - в одном .php" это вполне справедливо. Как только начинаем следовать MVC - это становиться чушью. А MVC как подход - гораздо менее WRONG WAY чем "пляшем от страницы, и всё, что касается страницы - в одном .php".
Как только начинаем следовать MVC - это становиться чушью.не понятно, почему ты придумал, что для MVC хранить данные в странице - это моветон..
При чём тут MVC?
MVC определяет внутреннюю структуру приложения, причём даже скорее требует, чтобы точка входа в приложение была общей. А внешний интерфейс не должен сильно зависеть от того, как внутри приложение реализовано.
Чем больше управляющих переменных в куки выносится, тем меньше возможностей работать с приложением в многооконном режиме. А без него веб уже не полноценный веб. Поэтому в куки лучше выносить лишь те переменные, которые именно в куках и нужны, которые должны быть глобальными.
MVC определяет внутреннюю структуру приложения, причём даже скорее требует, чтобы точка входа в приложение была общей. А внешний интерфейс не должен сильно зависеть от того, как внутри приложение реализовано.
Чем больше управляющих переменных в куки выносится, тем меньше возможностей работать с приложением в многооконном режиме. А без него веб уже не полноценный веб. Поэтому в куки лучше выносить лишь те переменные, которые именно в куках и нужны, которые должны быть глобальными.
не понятно, почему ты придумал, что для MVC хранить данные в странице - это моветон..Он увидел "в странице" и подумал "в .php-файле".
слишком открыто имхо, в куках же хранить безопаснее, они для того и придуманы
Вот такие вот умельцы и гадят в куках.
Конечно же надо вовсю использовать hid-поля форм. А в куках стандартный сайт имеет право хранить только id сессии, не более. Допустимо ещё хранить всякие штуки типа источника трафика, но скромно, и до того момента пока человек не авторизуется (дальше — по логину вполне всё можно хранить и восстанавливать в сессии).
так появляются новые холиворы 
(дальше — по логину вполне всё можно хранить и восстанавливать в сессии).Почему до авторизации нельзя всё хранить в сессии ? Зачем юзать хидден инпуты _только_для_того_чтобы_сохранить_что_то_между_реквестами_ ? Неужели это удобнее, чем сохранить всё в сессии ?
Зачем юзать хидден инпуты _только_для_того_чтобы_сохранить_что_то_между_реквестами_ ?что будет при этом с кнопкой back?
что будет если пользователь одновременно два раза открыл страницу, и пытается параллельно и там, и там что-то делать?
Неужели это удобнее, чем сохранить всё в сессии ?в данном случае, речь идет об удобстве использования, а не об удобстве программиста.
почему ты придумал, что для MVC хранить данные в странице - это моветон..Наверное читал не те интернеты ...
но всё равно считаю, что моветон.
В странице должны быть только те данные, которые нужны только для функционирования страницы в текущем виде (данные отображаемые на страницы + данные нужные для перехода страницы из этого состояния в другое). Складировать в хидден инпуты инфу, которая может понадобиться на других разделах сайта, или на этой же странице " в случае если юзер щас в форме 1 выберет значение 2, а потом в форме 5 значение 3 и потом нажмет кнопку вернуться к шагу 2 ..." ( т.е. хранить всю цепочку выборов (c) в хидден инпутах) - это имхо неправильно.
Если это не так - объясните почему.
ps. веб разработкой занимаюсь не более года, могу в чём то сильно ошибаться.
Почему до авторизации нельзя всё хранить в сессии ? Зачем юзать хидден инпутыПоявилось ещё вот какое соображение: данные сессии - либо в памяти сервера, либо даже в БД, следовательно хранить что-то в сессии до авторизации значит увеличивать шансы успешной DOS-атаки. Логично?
что будет при этом с кнопкой back?Если специалльно заморочацца - то всё ок с ней будет
что будет если пользователь одновременно два раза открыл страницу, и пытается параллельно и там, и там что-то делать?Я буду знать, что это _один_ пользователь открыл два окна в браузере и пытается что то делать - и я смогу это обрабатывать так, как захочу. А вот ты не будешь знать, что это один и тот же юзер открыл два окна. Для тебя это будет 2 разных пользователя.
данные сессии - либо в памяти сервера, либо даже в БД, следовательно хранить что-то в сессии до авторизации значит увеличивать шансы успешной DOS-атаки. Логично?наверное логично, но наверняка легко контрится.
в общем, всё свелось тому, что каждый говорит о своём, не понимая, что хотят сказать другие. Я вот уже совсем не понимаю, о чём мы, собс-но, говорим 
имхо, можно к трём основным целям использование переменных свести:
1) переменные, которые должны идентифицировать пользователя, то есть браузер. Для этого лучше всего подходят cookie. Одна переменная распространяется на все окна.
2) переменные, которые должны идентифицировать окно, состояние окна, чтобы веб-приложение могло генерировать ответ для конкретной страницы в зависимости от текущего состояния этой страницы.
3) наконец, хранение данных между запросами.
hid-поля нужны для задачи-2, cookie для этого мало применимы.
А для задачи 3, с учётом, что сейчас не 2005 год, и даже не 2009, есть специальные инструменты, а именно, localStorage. На сегодня уже менее 10% браузеров его не поддерживают (самый главный — ie7). Для этой задачи инструмент на порядок больше возможностей предоставляет, чем куки и хиддены вместе взятые. В общем, имхо, надо переходить на него.
имхо, можно к трём основным целям использование переменных свести:
1) переменные, которые должны идентифицировать пользователя, то есть браузер. Для этого лучше всего подходят cookie. Одна переменная распространяется на все окна.
2) переменные, которые должны идентифицировать окно, состояние окна, чтобы веб-приложение могло генерировать ответ для конкретной страницы в зависимости от текущего состояния этой страницы.
3) наконец, хранение данных между запросами.
hid-поля нужны для задачи-2, cookie для этого мало применимы.
А для задачи 3, с учётом, что сейчас не 2005 год, и даже не 2009, есть специальные инструменты, а именно, localStorage. На сегодня уже менее 10% браузеров его не поддерживают (самый главный — ie7). Для этой задачи инструмент на порядок больше возможностей предоставляет, чем куки и хиддены вместе взятые. В общем, имхо, надо переходить на него.
Да ! по пункту 1) и 2) - всё так. Я лишь хотел сказать, что для п. 3) хранить данные в сессии имхо разумнее, чем в хидден инпутах.
Про localStorage ничё не знаю.
Про localStorage ничё не знаю.
вот возьмем форум и команду ответить на сообщение.
данная команда инициирует цепочку страниц: Reply -> Preview -> Preview -> Preview -> Post.
на странице Reply спрашивается хотим ли мы проверить орфографию, так же до этого было запомнено на какой пост отвечается и т.д. - где всю эту информацию ты предлагаешь хранить?
чем это
отличается от этого:
данная команда инициирует цепочку страниц: Reply -> Preview -> Preview -> Preview -> Post.
на странице Reply спрашивается хотим ли мы проверить орфографию, так же до этого было запомнено на какой пост отвечается и т.д. - где всю эту информацию ты предлагаешь хранить?
чем это
В странице должны быть только те данные, которые нужны только для функционирования страницы в текущем виде (данные отображаемые на страницы + данные нужные для перехода страницы из этого состояния в другое).
отличается от этого:
на этой же странице " в случае если юзер щас в форме 1 выберет значение 2, а потом в форме 5 значение 3 и потом нажмет кнопку вернуться к шагу 2 ..."?
Возможно хреновый пример привёл.
Ок.
На странице 10 форм которые пользователь должен пройти последовательно (причем в зависимости от выбранного в начале меняется вид последующих форм и какие то мб пропускаются). Только после этого есть смысл обрабатывать этот пользовательский ввод. Когда страница в состоянии 10-й формы - то в ней в hid инпутах должны быть значения всех выбранных элементов в предыдущих 9-и формах?
Ок.
На странице 10 форм которые пользователь должен пройти последовательно (причем в зависимости от выбранного в начале меняется вид последующих форм и какие то мб пропускаются). Только после этого есть смысл обрабатывать этот пользовательский ввод. Когда страница в состоянии 10-й формы - то в ней в hid инпутах должны быть значения всех выбранных элементов в предыдущих 9-и формах?
то в ней в hid инпутах должны быть значения всех выбранных элементов в предыдущих 9-и формах?скорее - да, иначе достаточно тяжело выполнить сценарий, когда пользователь оставил 8-ую страницу открытой и уехал в отпуск на месяц, а потом вернулся и хочет продолжить дальше.
в данном случае, задача оконная, то есть у одного пользователя должна быть возможность работать с несколькими окнами. Приложению, чтобы сгенерировать следующую страницу, необходимо знать состояние текущей. Соответственно, два варианта — либо хранить в каком-нибудь hid id конкретного сеанса, либо передавать состояния всех полей каждый раз при перезагрузке страницы.
хранить id — плохо то, что нужно хранить состояние окна на сервере, лишние ресурсы потребляются. Но, зато в иногда можно избежать лишних запросов к БД, например, дополнительный контроль появляется. Нужно смотреть на конкретную задачу и выбирать. ИМХО, в большинстве случаев проще всё сделать на hid.
хранить id — плохо то, что нужно хранить состояние окна на сервере, лишние ресурсы потребляются. Но, зато в иногда можно избежать лишних запросов к БД, например, дополнительный контроль появляется. Нужно смотреть на конкретную задачу и выбирать. ИМХО, в большинстве случаев проще всё сделать на hid.
на странице Reply спрашивается хотим ли мы проверить орфографию, так же до этого было запомнено на какой пост отвечается и т.д. - где всю эту информацию ты предлагаешь хранить?Если значений не 2 (проверить орфографию и ид поста) а 10+ - то я предлагаю завести в сессии объект со всей этой инфой, а ключ того объекта - в хидден инпут или в GET часть ссылки перехода в след. состояние / action формы (это если важно чтобы в разных окнах разный ввод обрабатывался, иначе можно вообще тупо в сессию складировать )
Долго предыдущий пост писал ...
Нужно смотреть на конкретную задачу и выбирать. ИМХО, в большинстве случаев проще всё сделать на hid.Проще, если данных мало. Если их много, или есть вероятность что они будут добавляться или меняться - проще ИМХО сразу сделать на id сеанса.
я предлагаю завести в сессии объект со всей этой инфойи сколько времени его хранить в сессии? 30 минут? до перезапуска сервера? сутки? месяц?
скорее - да, иначе достаточно тяжело выполнить сценарий, когда пользователь оставил 8-ую страницу открытой и уехал в отпуск на месяц, а потом вернулся и хочет продолжить дальше.Почему ? из БД пропадёт запись сессии пользователя ? мб. Но если это важно, то этого не произойдёт.
и сколько времени его хранить в сессии? 30 минут? до перезапуска сервера? сутки? месяц?Сколько нада - столько и хранить. А когда процесс связанный с этим объектом завершится (пользователь пройдёт всю цепочку ввода и нажмет save) - то удалить этот объект руками (ну в смысле удалить явно в процедуре обработки завершения того самого процесса).
Я правда не знаю, можно ли куки браузера заставить хранить sessionid в течение неограниченно долгого периода.
Почему ? из БД пропадёт запись сессии пользователя ? мб. Но если это важно, то этого не произойдёт.т.е. если пользователь закроет браузер на середине, то данные в БД будут лежать вечно?
Сколько нада - столько и хранить.А как определить сколько надо?
Если есть место - то почему бы и нет ? сколько места займет в таблице пара sessionid, сжатый blob сериализованного объекта с парой десятков полей/списков/словарей и прочих простых структур хранения данных ? сколько таких мертвых сессий нужно чтобы выжрать ощутимо большое колво места на винте ?
А как определить сколько надо?ну блин, пока нужны - хранить. Я ответил в предпредыдущем посте на это.
Если есть место - то почему бы и нет ?А зачем нужно хранить?
Зачем тратить место в БД (сами данные + индексы тратить ресурсы на оптимизацию, писать дополнительные процедуры сохранения и оговаривать соответствующее поведение?
Технически намного проще просто сохранить всю ветвь ответов и каждый раз воспроизводить её. Есть какой-то перерасход запросов в БД (быстрых запросов, на чтение да, конечно. Хотя при необходимости, можно и всякие механизмы кеширования прикрутить. Работа намного упрощается.
сколько таких мертвых сессий нужно чтобы выжрать ощутимо большое колво места на винте ?100тыс. заходов в день, половина мертвая, хранится килобайт, итого за год 18гб
всё это ради чего? ради того, чтобы не передавать 1кб вместе со страницей в 50кб?
Технически намного проще просто сохранить всю ветвь ответов и каждый раз воспроизводить её.Не понял куда её проще сохранить, должно быть одинакого по сложности. Простота и прозрачность работы с сессиями - это забота фреймворка (готового или самописного - не важно).
Вон в django сессия - это вообще python словарь тупо, request.session. С этой точки зрения в него проще поместить инфу чем в хидден инпуты.
Не верю, что подобного нет ни в одном php-фреймворке.
100тыс. заходов в день, половина мертвая, хранится килобайт, итого за год 18гбМне кажется это не очень весомый аргумент. Если клиент важный - то его сессия не потеряется, а если мёртвый - то его сессию можно и убить. Нужно лишь решить задачу выяснения важности клиента. Это задача возникнет далеко не сразу, и решить её имхо будет не так уж и трудно.
всё это ради чего? ради того, чтобы не передавать 1кб вместе со страницей в 50кб?
так ради чего все эти усложнения?
По ходу обсуждения я подумал, что действительно пофиг куда сериализованный объект сохранять ... в БД или в hid input.
Для первого варианта во многих фреймфорках есть соответсвующая инфраструктура, для второго - скорее нету, чем есть. (хотя это ни в коем случае не является проблемой).
Ну с сессиями проще разруливается вариант - пользователь прошёл 8 форм и у него выключился свет. Через час - свет дали, и пользователь включив комп, продолжил с того места, где закончил. Ну и развивая вариант с отъездом в отпуск - можно прдусмотреть вариант с тычкой на сайте, чтобы он смог продолжить заполнять форму сидя в шезлонге с коктейлем и каким нить айпедом. На другом конце палки - 18 Гб в год, или задача определения важности клиента.
Наверняка и та и та концепции обладают ещё кучей плюсов/минусов.
Короче, будем считать, что я слил.
Для первого варианта во многих фреймфорках есть соответсвующая инфраструктура, для второго - скорее нету, чем есть. (хотя это ни в коем случае не является проблемой).
Ну с сессиями проще разруливается вариант - пользователь прошёл 8 форм и у него выключился свет. Через час - свет дали, и пользователь включив комп, продолжил с того места, где закончил. Ну и развивая вариант с отъездом в отпуск - можно прдусмотреть вариант с тычкой на сайте, чтобы он смог продолжить заполнять форму сидя в шезлонге с коктейлем и каким нить айпедом. На другом конце палки - 18 Гб в год, или задача определения важности клиента.
Наверняка и та и та концепции обладают ещё кучей плюсов/минусов.
Короче, будем считать, что я слил.
Неужели это удобнее, чем сохранить всё в сессии ?В сессиях хранят только универсальные вещи. Ну типа "Вася, 25см, пришел из Яндекса".
А то, что меняется (пример — порядок сортировки писем в ящике) — хранится в хидденах и гет-параметрах. Иначе две странички с листалкой не организуешь.
В сессиях хранят только универсальные вещи. Ну типа "Вася, 25см, пришел из Яндекса".Не так, в сессиях хранят именно параметры сессии (типа ip, browser ибо если ты залогинишься с другого компа или браузера ты не перестанешь быть Васей и размер не изменится.
А то, что меняется (пример — порядок сортировки писем в ящике) — хранится в хидденах и гет-параметрах. Иначе две странички с листалкой не организуешь.А потом "внезапно становится необходимо" запоминать сортировку (в случае писем это наверное и не очень нужно, но в других выводах почти наверное может понадобиться) и количество писем на странице (кстати в Яндексе почему-то не нашёл).
Оставить комментарий
Alena_08_11
Скрытые инпуты для сохранения какой то инфы между реквестами - это песец, если только sessionid (и то лучше в куки).А вообще, пора ТС-у искать фреймворк с поддержкой как минимум сессий (а заодно ОРМ, ЭмВэЦэ, и прочие плюшки). Всё таки на дворе не начало 2000-х. А с текущим багажом знаний, лучше вообще забить на пэхэпэ, а брать сразу python и учить к примеру django.
ps. Имхо, в том, что страница по сто раз перезагружается ничего криминального нету. В некоторых случаях без js по другому и не сделаешь.