JavaScript API: индексируемая БД, local storage, кэширование веб-приложений

В прошлом номере "КВ" мы рассмотрели одну из возможностей грядущей эпохи HTML 5 - интегрированную в браузер систему управления базами данных Web SQL. Продолжим знакомство с организацией локальной работы с данными в браузерах нового поколения и рассмотрим IndexedDB - альтернативу Web SQL, простой механизм хранения информации Local Storage и возможность кэширования файлов для работы веб-приложений Application Cache.

IndexedDB

Рассматривая в прошлой статье технологию браузерных СУБД Web SQL, мы отметили, что развитие этой технологии приостановилось. Не всех производителей браузеров устраивает интерфейс встраиваемой СУБД SQLite. Вполне возможно, Web SQL может и не стать общим стандартом для локального управления структурированной информацией в браузере.

К тому же у технологии Web SQL имеется конкурент - это стандарт, получивший название Indexed Database. Консорциум опубликовал черновик этого стандарта в начале года (www.w3.org/TR/IndexedDB).

Стандарт Indexed Database решает те же задачи, что и Web SQL - это наличие у браузера механизма хранения и доступа к данным, не будучи подключенным к Сети. Такая возможность нужна многим обычным веб-приложениям. Наличие такого механизма поспособствует развитию и чистых офлайновых программ.

Как и СУБД Web SQL, концепция Indexed Database предполагает наличие в браузере баз данных (database). Но эти базы данных содержат в себе вместо таблиц так называемые хранилища (store). А информация записывается в эти хранилища в виде записей (records) "ключ - значение".

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

Но на данный момент есть одно "но". В отличие от Web SQL, практической реализации Indexed Database пока ни в одном браузере нет. Механизм Indexed Database существует в виде чистой спецификации. Разработчики Firefox обещали сделать поддержку Indexed DB в четвёртой версии этого браузера.

Поэтому в качестве примеров приходится довольствоваться только теоретическим "псевдокодом", демонстрирующим работу JavaScript API Indexed DB. Главное, что видно из примера, в механизме IndexedDB нет никаких SQL-запросов.

// Открываем базу данных
connection = db.indexedDB.open("Fruits", "A Fruit Database!");
// Создаём хранилище и индекс
fruits = connection.createObjectStore("A Fruity Object Store",
 "fruit", true);
fruitIndexByColor = fruits.createIndex("A Fruity Index",
 "color", false);
// Делаем записи в хранилище:
fruits.put({ fruit: "Apple", color: "Red" });
fruits.put({ fruit: "Tangerine", color: "Orange" });

На мой взгляд, несмотря на то, что IndexedDB пока ещё практически не реализован, именно этот стандарт станет всеобщим.

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

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

И, в-третьих, это функциональность InexedDB, даваемая индексацией. В API InexedDB заявлены средства для гибкого поиска значений по маскам и диапазонам, а также поддержка хранения нескольких значений, привязанных к одному ключу, включая возможность присвоения одному ключу одинаковых дублирующихся значений. Для организации работы индексов могут использоваться структуры данных, формируемые с использованием алгоритма B-tree. Индексы могут создаваться и удаляться для существующих хранилищ объектов в произвольном порядке, в зависимости от желания разработчика.

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

DOM Storage

DOM Storage (Web Storage) - ещё один механизм хранения и доступа к данным внутри веб-браузера.

Как механизм Web Storage значительно проще, чем предыдущие IndexedDB и СУБД Web SQL. Этот механизм обеспечивает хранение и выборку данных в виде "ключ-значение", но без всяких индексов и прочая.

Концептуально DOM Storage продолжает и развивает идею cookie - небольшого объёма данных, хранимых браузером на стороне клиента по запросу веб-сервера. Только, в отличие от cookie, механизм DOM Storage может хранить данные значительно большего размера - около 5 Мб на страницу. Также информацией в DOM Storage можно управлять.

Работа DOM Storage имеет два режима работы, которые реализованы в виде специальных DOM-об'ектов.

Объект window.sessionStorage предназначен для хранения данных на время существования вкладки браузера, То есть данные доступны из этого объекта, пока вкладка браузера не закрыта. Данные не восстанавливаются, если произошла исключительная ситуация или браузер был закрыт.

Объект window.localStorage предназначен для долговременного хранения данных для каждого домена и субдомена, причем домены и субдомены могут получать данные друг друга. Данные хранятся и после того, как браузер был закрыт. Пример работы механизма local storage дан в следующем листинге.

// Открываем локальное хранилище
var storage = window.localStorage;
// Делаем запись
storage['userName'] = 'Вася';
// Выводим значение по ключу
document.write(storage['userName']);

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

Работает механизм DOM Storage практически во всех браузерах последних версий.

Application Cache

Application Cache - самый простой для понимания механизм работы с информацией в браузерах в режиме офлайн, который заявлен для браузеров поколения HTML 5. Работа с этим механизмом даже не требует вызова JavaScript API.

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

Смысл Application Cache в том, что загруженное в браузер веб-приложение, например, Google Docs, может использовать для своей работы много дополнительных файлов - скриптов, файлов CSS, картинок, иконок и т.д. В случае отключения от Сети эти ресурсы для веб-приложения становятся недоступными. Стандарт Application Cache позволит веб-приложению самому управлять кэшированием файлов через специальный манифест. В этом манифесте описывают все нужные файлы, которые браузер в обязательном порядке кэширует для последующей работе в режиме офлайн.

Собственно, основная идея будущей спецификации Application Cache - обеспечить беспроблемную работу веб-приложения в случае отсутствия доступа к Сети.

Файл манифеста - это специальный текстовой файл с расширением manifest, в котором нужно перечислить все файлы для кэширования, например:

CACHE MANIFEST
clock.html
clock.css
clock.js
NETWORK:
login.php
FALLBACK:
images/images.php image.png

В данном примере управление кэшированием осуществляется через директивы CACHE, FALLBACK, NETWORK. Директива CACHE определяет файлы, которые следует кэшировать. Директива NETWORK определят файлы сайта, обращение браузера к которым требует обязательного подключения к Сети. И директива FALLBACK - это триггер, который привязывает файл из кэша к определённому файлу на сервере в случае отсутствия доступа в Интернет.

Загружается файл манифеста через специальную ссылку "manifest" в теге <HTML> главной страницы веб-приложения:

<! DOCTYPE HTML>
<html manifest="clock. Manifest">
<head> ...</html>

Заключение

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

Михаил АСТАПЧИК