|
Хранение состояния плагинов
#38371279
Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
|
Участник
Откуда: Харків, Україна
Сообщения: 7 838
|
|
Привет!
Когда проекты начинают двигаться в стороны RIA, это обуславливает создание плагинов, у которых можно выделить набор пользовательских настроек, предпочтений и всего прочего -- состояние плагина. И это состояние хорошо где-нибудь хранить.
На данный момент мне известны пять решений этой проблемы:
Хранить состояние частями или целиком в пользовательских предпочтениях (APEX_UTIL.%_preference, WWV_FLOW_PREFERENCES$).
+ использование встроенного API, что означает отсутствие каких-то дополнительных шагов по установке решений;
+/- состояние хранится на сервере;
- предпочтения превращаются в помойку данных;
- ограниченная длина данных в строке (4000 байт).
Один из предпочитаемых мной способов, если плагин одиночный, не объёмный, и состояние описывается десятком небольших закодированных в строки JSON-объектов.
Сохранять состояние в клиентских печеньках.
+ даже ленивые написали своё API для работы с ними;
+/- состояние хранится на клиенте;
- хлам в печеньках;
- ограниченный размер данных в печеньках как для одного экземпляра, так и на домен;
- все минусы, связанные с печеньками.
Local Storage . Особо не работал с этой фишкой HTML5, потому оценка не окончательная.
+ размер побольше;
+ наличие API в популярных JS-фреймворках;
+/- хранение без обращения к серверу.
Хранение в собственной таблице всего состояния, представленного в одном из популярных форматов (JSON, XML), в CLOB-поле.
+ на стороне сервера запись и выдача состояния достаточно просты;
+/- состояние хранится на сервере;
- работа с частью состояния сложнее других вариантов;
- для отправки состояния с клиента придётся всё равно резать состояние на части и склеивать его на сервере;
- предполагает создание дополнительных объектов БД (таблица и API для работы с ней).
Хранение в наборе таблиц, описывающих сущности и связи нормализованных состояний.
+ все плюсы нормализации с удобством запросов и DML;
+/- состояние хранится на сервере;
- сопутствующие расходы на создание API, продумывание модели и её изменение при добавлении/изменении плагинов;
- всё это придётся создавать на каждом экземпляре APEX с правами и прочим.
Всё больше склоняюсь к этому способу.
В хранении состояния на сервере или на клиенте есть как плюсы так и минусы. Если сервер не участвует, то не нужно его ставить в известность об изменении состояния теми же AJAX-вызовами и получать это состояние в ответ при создании страницы. С другой стороны, стоит сменить машину, браузер или даже неаккуратно почистить кэш -- прощайте, настройки под себя, любимого пользователя.
А хранение состояний на сервере подразумевает обращения к нему для сохранения изменений либо по желанию пользователя, либо автоматически. Первое подразумевает, что пользователь может забыть сохранить настройки, второе -- задалбывание сервера через AJAX... В общем, создание своего велосипеда по чертежам IR. :) APEX Team, как видим, предпочла два набора таблиц для хранения состояния: в рамках сессии и сохранённые пользовательские настройки.
Это всё длинная преамбула к короткому вопросу: кто какие способы использует для хранения состояний плагинов и на какие грабли наткнулся? Поделитесь, пожалуйста, не заходя за рамки коммерческой тайны.
Спасибо за внимание.
-------------------------------------------------------
When I say "RTFM" or "STFF" or "STFW",
the third letter means "Following" or "Fine"... |
|
|
