Главная > AJAX, Open Source, СУБД > PersistJS — снова, снова и снова про Сlient Side Storages

PersistJS — снова, снова и снова про Сlient Side Storages

23 мая 2008

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

Сегодня мы снова поговорим о теме клиентских систем хранения данных. Очень уж часто, при разработке современных веб-приложений, нам требуется возможность хранить достаточно большие объёмы данных на стороне клиента, которые бы были доступны при переходе между страницами или даже после обновления окна браузера или перезагрузки компьютера. Традиционно таком качестве выступали cookie, но с развитием веб-технологий их ограничения стали достаточно заметны. Мы уже не раз писали о разных системах Client-Side Storages, вы без труда найдёте их в блоге. Не случайно все новые браузеры содержат или будут содержать, когда выйдут релизные версии, различные механизмы для хранения данных, даже в стандарте HTML 5 предусмотрена более-менее попытка стандартизировать такое хранилище и интерфейс доступа к нему.

Но пока на рынке как то не было решения "здесь и сейчас", да ещё и чтобы поддерживались все возможные варианты хранения, включая экзотику вроде Google Gears или openDatabase из Safari 3.1. Раньше самым мощным вариантом было использовать модуль storages из пакета Dojo Toolkit, однако это решение не отличалось элегантностью, так как предполагало тянуть за собой существенную часть пакета Dojo. Один из моих коллег, разработчик технологии fullajax по сообщениям, вытянул все зависимости и собрал полностью независимую версию этого стораджа, но это достаточно сложная работа. Теперь же на рынке есть несколько решений, более универсальных и лёгких в использовании. Сегодня я расскажу об одном из них - PersistJS.

И так, у нас есть совершенно миниатюрный скрипт, менее 10 Кб размером, поддерживающий внушительный набор различных способов хранения данных:

  • хранилище на основе Flash (используется в Dojo Toolkit и один из первых механизмов стораджа)
  • Google Gears - пусть и не самое распространённое решение, но если честно, самое прогрессивное
  • HTML 5 LocalStorage - стандартный механизм стораджа из спецификации HTML5, для тех браузеров, которые уже поддерживают
  • whatwg_db - ещё один механизм стораджа из HTML5, на основе локальной базы данных
  • globalStorage - предыдущий механизм из того же HTML 5
  • userdata - механизм хранения данных в Microsoft Internet Explorer
  • cookie - ограничен, но реализован почти во всех браузерах

Странно, что не предусмотрели хранение в свойстве window.name, как это сделали в одном из конкурирующих проектов, о котором мы скоро напишем. А так покрыты видимо все возможные варианты, уж какой-то из них браузер точно поддержит. В планах - реализация поддержки сред для RIA,  частности, Adobe AIR (она построена на основе движка WebKit, который уже поддерживается, значит интеграция не будет сложной).

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

Данные хранятся и извлекаются по их ключу, но я бы сказал, что не хватает некоторых механизмов, например, пространств имён, хотя это актуально для сложных больших проектов. Кстати, интересен механизм поиска доступного хранилища - скрипт изначально пытается проверить, установлен ли Google Gears, а потом уже "снижает планку", пробуя другие варианты.

Насколько я разобрался, разрешено хранить только строковые значения, значит, объекты JS придётся вручную преобразовывать  строки в виде JSON-кода. Да и следует помнить, что разные механизмы накладывают свои ограничения - в случае cookie вам доступно лишь 4 Кб,  в то время как при использовании современных средств вроде Google Gears или Flash вам доступны уже мегабайты (почти неограниченный объем).

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

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

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

P.S. Гм, а что будет, если совместить ExtJS.MixedCollection/TaffyDB и такое хранилище? Я уже неоднократно об этой идее писал, может кто реализует?

  1. 23 мая 2008 в 19:38 | #1

    >с развитием __ЕБ__-технологий
    Исправьте, пожалуйста, на «с развитием __ВЕБ__-технологий», а то уж больно неприличная опечатка получается 😕

  2. 24 мая 2008 в 15:54 | #2

    Спасибо за статью, я анализировал http://pablotron.org/software/persist-js/ и http://browserpersistence.ru/. Действительно очень легкие маленькие и в то же время достаточно функциональные наработки. Вполне удобно их использовать. Но как всегда у них есть ряд недостатков. В данном обзоре уже было сказано что обьекты придется сериализовать и десериализовать вручную, нет пространства имен, непонятно что произойдет при большем попытке сохранить больше чем можно, прочее… Лично мое субъективное мнение что наработка Dojo все же впереди планеты всей, и именно Flash сторадж наиболее привлекателен. Тем более что после выделения Flash сторадж занимает 15кб со всеми примочками типа сериализатора/десериализатора, пространства имен, прочее..
    Я тоже готовлю статью на тему стораджа с уклоном на механизм управления обновленем данных на стороне клиента, после выхода статьи будут доступны исходники выделенного мною из Dojo стораджа.

  3. 25 мая 2008 в 13:42 | #3

    Алик Кирилович — спасибо, исправил! это кнопка с буквой В у меня западает 🙁

    Руслан — да, я к тем же выводам пришел, хоть в дожо именно с гирсом и флешем а здесь более шировое поле. Ждем твою статью!

  4. Антон
    26 мая 2008 в 13:44 | #4

    Автору respect!!! 🙂 О-о-очень интересно!!!! 😉 🙂

  5. 2 июня 2008 в 14:30 | #5

    Каким образом гарантируется безопасность в таких хранилищах? То же что в cookie или еще какие-то методы?

  6. 3 июня 2008 в 17:45 | #6

    Познавательно, автору респект

  7. 4 июня 2008 в 20:58 | #7

    спасибо за предоставленную полезную информацию! Днействительно, очень функционально. Но чем эта технология хр. данных отличается от cookie?

  8. 21 июля 2008 в 09:52 | #8

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

  9. 21 июля 2008 в 09:57 | #9

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

  10. 29 июля 2008 в 07:25 | #10

    Благодарю за инфу. Очень полезно!
    Респект!

Комментирование отключено.
Developers.org.ua