| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Общие вопросы > ViewState для PHP! |
| Автор: Crypton 4.12.2009, 05:43 | ||||||||
| Не знаю если это относится к "Для профи" или к "Общим вопросам" [hr] В ASP.NET есть обалденная вещь и называется она ViewState. HTTP связь с сервером как правило не поддерживает отношений между данными так что приходится извращаться с данными в форму, куки, сессию и пр. Однако некоторые вещи порой не подходят для реализации как, например куки и сессии которые одинаковы на все приложение. Единственное что можно сделать, это внести в форму (<form>) дополнительные скрытые поля, которые при запросе обратно к скрипту дадут ему понять, что делать с данными. В ASP.NET эта функция встроена и поддерживает сохранение любых объектов помеченных атрибутом Serializable в том числе и примитивных типов как string, Guid, и т.д. Пример свойства с сохранением идентификатора статьи:
Однако в PHP такой функции, к сожалению, нет, так что приходится прибегать к таким выкрутасам. Приведем логическую конструкцию: 1. Начало скрипта (inlude,require) 2. Обработка GET/POST, если они есть. 3. Вывод данных (HTML) 4. Конец Рассмотрим аспекты более детально. Нам необходим самый простой метод работы с данными. Можно, например, использовать ключевой массив ($array['key']) практически, как и в ASP.NET. Облегчает ситуацию еще и возможность сериализировать любой объект в php в строку. Потом всю эту строку еще и скормим в base64. Далее:
Получается, что все, что нам нужно будет сделать, это поставить эту строку в input type="hidden" и результат готов. При следующей загрузки страницы просто-напросто конвертируем обратно от base64 и десиарилизируем. Лучше всего сделать это в ООП подходе и создать класс. Ах да, вы наверное, хотели спросить про безопасность. Известно, что при малейшем изменении данных, хэш SHA критически меняется. Но вот как зафиксировать попытку изменения данных в форме кулцхакера? В конце-концов относим все в отдельный класс, viewstate.php:
А в основной странице,
[hr] Источник http://crypton-technologies.net/experiments/viewstate-dlya-php Вкратце, на одном проекте (эдакий магазин со службой поддержки), понадобилась такая функциональность. У клиента уже был сервак на линухе и менять ничего они не собирались прося такую супер-пупер функциональность на таких масштабах. Ну была-ни-была, клиент есть клиент. Очевидные минусы ViewState:
|
| Автор: Simpliest 4.12.2009, 08:36 |
| Не надо гонять viewState туда-сюда. хеш наружу и хранилище для viewState на сервере. Я использовал тупо сериализацию текущего enviroment. Для моих задач этого хватало. Хранилось все. Текущее состояние объектов, ошибки, данные ввода. При желании можно было организовать даже пошаговый просмотр всего сеанса работы пользователя. |
| Автор: Simpliest 4.12.2009, 12:47 | ||
что поделаешь, бесплатные пирожки только у бабушки Просто для небольших объемов данных, как мне кажется, достаточно сессии. viewState мне потребовался, когда данных стало весьма много и время их жизни стало много большим чем пару часов. Хеш в куки и работаем в приложении целый день. Закрыли его. Пришли завтра, авторизовались и открыли приложение на том же самом месте где окончили работу вчера. Со всеми данными и проч. А гонять дополнительно многие десяткикилобайт между клиентом и сервером - для меня было накладно. угу, и давно пора. |
| Автор: Crypton 4.12.2009, 17:34 | ||||||||
Хм, а как планируете хранить его на сервере? в Сессии или в определенном файле?
А если юзверь откроет сразу много форм? Как уже говорилось, практически невозможно отследить если окно браузера (форма) была закрыта. В конце-концов вьюстейт на то и создан чтоб храниться в форме. А так можно тупо использовать сессию.
Заявка хорошая, но с проектами над которыми я раньше работал (а они написаны по всем "стандартам" php3 лиж-бы работало), там и речи небыло про такое. А когда с клиентами разговаривал мол переходите на правильный путь они разводили руками и говорили "если работает, зачем менять?". |
| Автор: Simpliest 4.12.2009, 17:54 | ||
По вкусу и потребностям. Я хранил даже в БД, но при большой нагрузке это не самый лучший вариант. можно воспользоваться вариантом отсюда http://forum.vingrad.ru/forum/topic-281995/kw-cache-%D0%BA%D1%8D%D1%88-file--based-memcahed.html каждому хешу - свой файл. и? для каждой формы генерируется свой хеш с учетом timestamp и передается в урл или скрытом поле. да образуется много мусора(пользователь закрыл форму, а данные еще висят у нас), который, как справедливо заметил solenko, надо будет чистить. Но это решаемая задача. Правильно говорят. Только донеси им мысль, что добавить новую функциональность не так просто |
| Автор: Crypton 4.12.2009, 18:02 | ||||||||
Неплохой вариант. Мне даже самому нравится.
Может тогда написать сборщик мусора?
Им надо донести мысль что http://zylog.livejournal.com/679.html программировать не надо. |