Форумы портала PHP.SU :: Реализация drag and drop html редактора

Программирую Drag&Drop HTML-редактор.
Все необходимые действия по добавлению, редактированию, удалению контента методами javascript запрограммировал. Встал вопрос о сохранении результатов работы в html-страницу, на котором я застрял. Задача весьма нетривиальная.
Собственно, как известно, напрямую из javascript сохранить результат работы в html файл невозможно.
Остается ajax+php. Как мне видется возможным сохранение контента:
1 вариант. При добавлении контента новый контент добавлять в таблицы mysql, организованные соответственно типу данных:
tables, divs, images, texts, forms.
При перенесении контента из одного места в другое менять родительский id. Получится организация объектов по виду древа.

2 вариант. Посла каждого изменении на страничке отправлять аяксом весь html сразу и хранить в одном файле.

Другие варианты ???
Как будет организовать гибче, проще?
(Добавление)
Если остановиться на сохранении контента в html-странице просто текстом, то тогда очень много придется использовать регулярных выражений для поиска и изменения атрибутов тегов, добавления новых параметров, переноса одних html-элементов в другие и т.д. и т.п. Потеряются все преимущества работы с базами данных, с выборками однотипных элементов, установкой ограничений допуска пользователей к редактированию контента. Зато появляется одно единственное преимущество - простота контроля сохраненных страниц, в том числе и как шаблонов. А также весьма упростится вставка пользовательского html-кода.

Если же использовать базы данных, то придется видимо очень долго ломать голову, чтобы предусмотреть все возможные варианты атрибутов и их значений для html-элементов, таких как float, position, display, visibility, таблицы с контентом станут избыточными, а если не предусмотреть все варианты, то сплошь и рядом будут ошибочные ситуации с отображением пользовательских html страниц. А главное - вставка пользовательского html в страницу станет сущим гемороем, так как получится создавать весьма нетривиальные запросы.

Что-то мне подсказывает что оба варианта не очень удачные....
(Добавление)
Опытные люди в сторону JSON указывают пальцем...