Хранение данных и обмен между клиентом и сервером в реализации CMS с поддержкой визуального редактирования html Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.(55+75)

Data Storage and Client-Server Exchange in the Implementation of CMS with Support for Visual HTML Editing

Kruchinin S.V. 1, Shikov O.Yu. 2

1 Wellborn LLC. 2 Novgorod State University named after Yaroslav the Wise

Abstract. The article proposes a mechanism for storing data in XML format on the server side and a client-server exchange mechanism in the development of a CMS with a mechanism for visual creation and editing of HTML-documents with the use of an object-oriented architecture. Documents can inherit elements of the parent document. The visual editor (JavaScript application) allows the user to edit Web pages in WYSIWYG mode, the server side makes changes and saves the pages. The finished pages generated from XML structure and data are sent by HTTP (HTTPS) protocol.

Keywords: XML, HTML, CMS, WYSIWYG, HTTP, HTTPS, template storage, client-server exchange.

Хранение данных и обмен между клиентом и сервером в реализации CMS с поддержкой визуального редактирования

HTML

Кручинин С. В. 1, Шиков О. Ю. 2

1 ООО «ВЭЛБОРН» 2 ИГУМ НовГУ им. Ярослава Мудрого

Аннотация. В статье предложен механизм хранения данных в формате XML на серверной стороне и механизм клиент-серверного обмена в разработке CMS с механизмом визуального создания и редактирования документов с применением объектно-ориентированного подхода. Документы могут наследовать элементы оформления родительских элементов. Визуальный редактор (JavaScript-приложение) предоставляет пользователю возможность редактировать вебстраницы в режиме WYSIWYG, серверная сторона вносит изменения и сохраняет сгенерированные страницы. По протоколу HTTP (HTTPS) отправляются готовые страницы, полученные из хранимой XML-структуры и данных.

Ключевые слова: CMS, WYSIWYG, XML, HTML, клиент-серверный обмен, хранение шаблонов.

Введение. Проблема дружественного к пользователю (user friendly), визуального (WYSIWIG) редактирования - одна из актуаль-

ных проблем современной теории и практики веб-разработки. Многие современные CMS (такие как Wordpress) предлагают два режима работы (просмотр и редактирование), значительно отличающиеся друг от друга. Главное особенностью такого подхода является не наглядность и не визуальность режима редактирования. Существуют некоторые попытки создания визуального режима. Довольно ограниченный режим (только контента) присутствует в Ю-Bitrix. При этом на практике все равно применяется «административная панель». Более удачными вариантами являются немногочисленные системы визуального редактирования, такие как Wix, или менее известный Hollpee (hollpee.ru) [1].

Актуальность. Отметим, что задача визуального редактирования не тривиальна. Простейший способ сохранить результат визуального редактирования с приписыванием каждому элементу HTML CSS-свойства position:absolute [1] делает документ не поддерживаемым и не редактируемым, а гибкое определение взаимного положения элементов может быть сложной задачей ввиду неоднозначности вариантов задания положения в CSS одного и того же элемента.

Авторы убеждены, что визуальное редактирование, прозрачность и наглядность позволят улучшить общее качество предоставляемых в сети услуг. Это подтверждается и опытом решения аналогичных задач (создание САПР на принципах визуального редактирования [3]) и наличием существующих попыток создания наглядных редакторов (как в Hollpee [2]).

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

Цель настоящего исследования - построить модель клиент-серверного взаимодействия и хранения шаблонов для реализации CMS с поддержкой визуального редактирования. Разработанное решение может использоваться как контейнер для модулей, надстраиваемых веб-приложений (например, при реализации вебинар-плат-формы или сервисов потокового вещания с применением HTML5 и CSS3 [4]).

Основные положения исследования. Общие представления об управлении веб-документами нами были представлены в ряде публикаций (например, [5]). В данной работе мы остановимся на архитектуре более детально. Основные положения архитектуры заключаются в применении концепции объектно-ориентированного проектирования к иерархии документов. Веб-документы генерируются приложением (PHP-скриптом), но благодаря ЧПУ («человек-понятный URL») для посетителя сайта структура ресурса выглядит как набор директорий и файлов.

Новизна нашей концепции заключается в том, что и для редактора/администратора структура также предстает в виде «виртуальной файловой системы», где в качестве директории выступает некий набор элементов, который характеризует не только принадлежность вложенных документов/файлов и директорий данной директории, но и определяет внешний вид и структуру дочерних элементов.

Фактически элемент «директория», называемый нами как «раздел», содержит HTML и CSS-шаблон, который хранится во внутреннем представлении системы. Каждая дочерняя директория и каждый дочерний документ может (и по умолчанию) наследует свойства родительского раздела, аналогично как наследуемый класс в ООП наследует свойства и методы родительского класса. Аналогично же ООП в нашем случае свойства могут быть переопределены, виртуа-лизированы, добавлены новые для дочернего документа.

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

Для реализации такого подхода мы определи элементы, составляющие раздел/документ. В целом эти элементы аналогичны HTML-элементам, но наделены рядом дополнительных свойств, управляющих наследованием и переопределением элементов.

Для возможности управления у CMS также должно присутствовать два режима работы: обычный и административный. Разница с существующими приложениями заключается в том, что административный режим отображает документ также, как и в режиме просмотра, но дополнительно появляется панель инструментов, позволяющих править документы в режиме WYSIWYG, а также управлять вложенностью/наследуемость.

Наиболее интересный пример: создание нового пункта в меню не только добавляет элемент «ссылка», но и создает связанный дочерний документ. Нет потребности добавлять документ отдельно, и указывать на него ссылку отдельно, что делает редактирование значительно user friendly.

Несмотря на значительную схожесть режима просмотра и режима администрирования, принципиально они различны. Если в режиме просмотра пользователь получает статичный документ, в режиме редактирование пользователь работает с JavaScript-редактором, который отрисовывает новые элементы на лету, отправляя на сервер (используя Ajax) измененные данные. Тем не менее внешне для пользователя оба режима выглядят одинаково (за исключением возможности правки).

Введение в архитектуру системы. Для упрощения назовем рассматриваемую систему DynamicViewGenerator, или, сокращённо, DVG. Наша система предназначена для удобной генерации HTML страниц с использованием XML для внутреннего представления и наследования. Самая большая структурная часть именуется представлением (view). Представление есть ничто иное как XML документ, хранимый в БД и имеющий свой уникальный для системы идентификатор ViewID (id).

Тело каждого представления состоит из элементов (elements). Каждый элемент имеет свой ElementID (eid), который уникален в рамках своего представления.

Рисунок 1. Схема элементов системы

<?xml version="1.0" encoding="UTF8" ?> <view next-eid="1">

<content>

</content>

</view>

Листинг 2. Минимально требуемый код представления

В листинге 1 предоставлен минимально требуемый XML код представления. Тэг view корневой и содержит все остальные тэги. В

том случае, если это корневое представление, оно обязано содержать маркер будущего элемента - атрибут next-eid, который содержит число - ElementID следующего добавляемого элемента.

После каждого добавления элемента должен инкрементиро-ваться.

Тэг content содержит все наши элементы, которые в дальнейшем будут отображаться в элементе body результирующего HTML.

<?xml version="1.0" encoding="UTF8" ?> <view next-eid="8"> <content>

<div eid="1">

<h2 eid="5">Приветсвую, MMp!</h2> <p eid="3">

<b eid="4">Consectetur</b>

</p> </div>

<img src="/logo.png" eid="6" />

</content> </view>

Листинг 2. Пример представления с контентом

В листинге 2 мы видим пример самого простого представления. Каждый элемент имеет свой атрибут eid, содержащий уникальный для этого представления ElementID. Так же мы видим, что элементов 2 и 7 нет, но при этом next-eid содержит число 8, а значит следующий добавленный элемент будет с eid 8, а не 7.

Почему отсутствует элемент 7?

Не сложно сделать вывод, что он был полностью удален и никогда уже не будет присутствовать в нашем представлении, иначе это вызывало бы коллизии и непредсказуемое поведение, о которых мы поговорим позже.

Наследование представлений

Представление (View) может переопределять ранее созданное представление, то есть иметь родителя (parent). Одно представление может иметь только одного родителя, но при этом количество детей не ограничено.

Так же представление может переопределять представление, которое в свое время то же переопределяет представление.

View 1 View 2

View 3 ■ View 4

View 5

Рисунок 3. Схема наследования представлений

На данной схеме у представления с ViewID1 наследников нет, а у представления с ViewID2 целых два наследника - ViewID3 и ViewID4. ViewID4 не имеет наследников, а представление с ViewID3 имеет одного наследника.

Самая главная цель наследования - это то, что наследники получают все элементы (elements) своих предков.

К примеру, ViewID5 с нашей схемы уже имеет в себе все элементы представлений View2 и View3, и, если изменить элемент в представлении View2, это незамедлительно отобразиться на его детях.

Но просто наследование было бы не столь интересно, поэтому наследники могут переопределять либо весь элемент родителя, либо только его атрибуты, либо «удалить» его у себя.

Переопределять можно не только атрибуты и содержимое, но и сам элемент.

К примеру, в родителе это был p, в ребенке стал span. Главное, чтобы сохранился ElementlD. При добавлении нового элемента в ребенка, в его родителе инкрементироваться маркер будущего элемента next-eid.

При переопределении элемента в ребенке, никаких действий с маркером не происходит.

<?xml version="1.0" encoding="UTF8" ?>

<view parent="1">

<content>

<div eid="#1">

<h2 eid="#5">0 нашем сайте<^2>

<span eid="#3">

Ab aperiam architecto beatae eligendi hic sit.

</span>

</div>

</content>

</view>

Листинг 3. Пример представления - наследника

В листинге 3 мы видим представление, которое наследует представление из листинга 2. Оно обязано иметь атрибут parent и не иметь маркера будущего элемента (атрибута next-eid), так как next-id у него тоже наследуется от родителя. Элемент img с ElementID 6 из листинга 2 здесь отсутствует, а значит он без изменений будет взят из родителя. Элемент b с ElementID 4 из листинга 2 тоже здесь отсутствует, но он совсем пропадет из нашего представления, так как его контейнер - элемент 3 был полностью переопределен.

Символ управления наследованием. Из приведенных листингов видно, что в eid перед каждым ElementID есть символ #. Это символ, управляющий наследованием. Есть несколько возможных вариантов управления наследованием, за каждый из которых отвечает своей символ перед ElementID в атрибуте eid:

1. Отсутствие управляющего символа либо символ # - жесткое (полное) переопределение элемента. Полностью переопределяется как его атрибуты, так и его содержимое. Если в родителе присутствовали атрибуты у элемента, а у наследника их нет, считается что их нет. Если в родителе присутствовали внутренние элементы у элемента, а у наследника их нет, считается что их нет.

2. Символ @ - мягкое переопределение элемента. Если отсутствуют все атрибуты либо только в части, недостающие атрибуты берутся из родительского представления. Если полностью отсутствует содержимое элемента, оно перейдет из родителя. Для возможности мягкого переопределение необходимо, чтобы в элементе отсутствовали текстовые элементы, не входящие в другие элементы, так

как в таком случае порядок следования и переопределения элементов будет непредсказуем. Для решения данной проблемы следует ввести дополнительный элемент для описания простого текста.

Маркер будущего элемента.

Подведем итоги с маркером будущего элемента - атрибутом next-eid, который содержит число - ElementID следующего добавляемого элемента. После каждого добавления элемента должен инкре-ментироваться.

1. Маркер храниться в атрибуте next-eid тэга view корневого представления.

2. У представлений, наследующих другие представления такого атрибута нет - они наследуют маркер у корневого родителя.

3. С маркером возможна всего одна операция - инкрементация. Он не может уменьшаться.

4. При добавлении нового элемента в дочерний элемент, родительский маркер так же инкрементироваться. Это необходимо для корректного наследования элементов.

5. Он всегда больше самого большого ElementID данного представления как минимум на единицу. В двух ситуациях он может быть больше, чем на единицу: если элемент с максимальным ID был удален из представления либо если элемент был добавлен в ребенка этого представления.

Содержимое элемента.

Как было уже сказано ранее, каждый элемент обязан иметь свой уникальный ID в рамках представления. Он необходим для того, чтобы при наследовании иметь возможность корректно указать, какой элемент мы переопределяем.

Любой элемент может содержать в себе:

1. Любое количество любых элементов, которые так же обязаны иметь свой уникальный EID. Но при этом такой элемент не может содержать в себе обычный текст.

2. Любое количество простого текста, но при этом не может содержать другие элементы.

Как мы уже выше написали, для решения неоднозначности при наследовании при нахождении в элементе и текста и вложеных элементов, необходим дополнительнй элемент для текста. Если необходимо, что бы элемент содержал и текст и другие элементы, необходимо текст вставить в элемент textelement.

Виды элементов.

Доступны все элементы, которые доступны в HTML в тэге body, но поведение некоторых скорректировано. Так же добавлены новые элементы со своим поведением.

1. Null - «несуществующий тэг». Необходим, чтобы при наследовании удалить родительский элемент.

2. Parent - «полностью наследуемый тэг». Имеет только один атрибут - eid - и полностью наследует элемент без родителя без изменений.

3. Include - «тэг-включение». Благодаря этому тэгу можно полностью вставить одно представление в другое. Содержит в себе ViewID.

4. Textelement - «текстовый элемент». Может содержать в себе только текст. Не может содержать другие элементы.

5. A - «ссылка». Тот же тэг из HTML, но с небольшим отличием. Вместо атрибута href содержит атрибут href-view, который должен содержать в себе ViewID.

Клиент-серверное взаимодействие. В то время, как получение документа в режиме чтения, по большей части на прикладном уровне модели OSI/ISO выглядит, как запрос контента методом GET с указанием конкретного ресурса (имитирующего путь к документу в файловой директории в нашей «виртуальной файловой системе), редактирование представляет более сложный процесс в виде распределенного клиент-серверного приложения. На стороне сервера приложение представлено PHP-скриптом на базе фреймворка Laravel, на клиенте JavaScript-приложение, напрямую работающее с деревом DOM, ведущее историю изменений в рамках текущей сессии, получающий и отправляющий на сервер данные об изменениях. Механизм изменений представлен REST-API с XML в качестве формата взаимодействия на прикладном уровне, таким образом HTTP решает задачи транспорта. Такой подход не вполне укладывается в модель OSI/ISO, так как прикладной уровень сам состоит из двух подуровней: собственно механизм взаимодействия клиент-сервер, и сам протокол HTTP (а в случае шифрованного соединения HTTPS, фактически он и будет использоваться, в особенности в режиме редактирования).

Этапы осуществления взаимодействия.

Упрощенно механизм обмена можно описать следующим способом: клиент (редактор) получает от сервера набор XML представления страниц, отрисовывает по ним DOM-дерево, и после визуального редактирования (WYSIWYG) данные в формате XML представления отправляются обратно на сервер.

В зависимости от того, создается ли новый документ, или редактируется существующий логика запросов-ответов может варьироваться.

В случае, если создается новый документ, клиент запрашивает у сервера данные о родительской странице, для использования в качестве шаблона (Рис. 3.1). Затем, после создания на ее основе новой страницы, данные отправляются на сервер и сохраняются в БД.

Клиент

Передача данных

Сервер

1)

В случае создания стр а н и цы -н а сл едн и ка. запросы на сервер

i

ХМ1. представление страниц -предков

Получение из БД отправка страниц-предков

Создание новой страницы

i

ХМЬ представление страниц

Сохранение >т1-сграницы е ЕД

Рис. 3.1. Механизм обмена в случае создания новой дочерней страницы

Рис. 3.2. Механизм обмена для редактирования страницы

В случае редактирования страницы происходит обращение к серверу и для получения данных родительской страницы, и для получения информации о редактируемой страницы. После редактирования данные также отправляются на сервер и сохраняются в БД. Как мы видим, при редактировании обмен происходит во внутреннем формате, HTML генерируется на клиентской стороне. В случае же запроса страницы посетителем, возможны два варианта работы CMS

Рис. 3. Механизм обмена при запросе страниц посетителем: 3) первый запрос, 4) последующие

Если посетитель впервые запрашивает сохраненную в редакторе страницу, на серверной стороне происходит генерация документа - компиляция из внутреннего формата XML файлов HTML и CSS (и при необходимости js). Клиенту уже отправляются сгенерированные статичные файлы (рис.3.3)

При последующих обращениях посетители будут получать за-кешированные сгенерированные файлы (рис.3.4). Так как это статичное содержимое, CMS будет работать быстро и с возможность обеспечивать работу при высоких нагрузках при использовании вебсервера Nginx.

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

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

Заинтересованных в разработке описанного решения приглашаем к сотрудничеству: cms@scirep.ru

Библиографический указатель:

1. Почему конструкторы сайтов выдают плохой код? // Habra-habr.ru Опубликовано 17.04.2017 г. [Электронный ресурс] Режим доступа: URL: https://habrahabr.ru/post/326664/

2. Hollpee - создание адаптивных сайтов без знания кода [Электронный ресурс] Режим доступа: URL: http://hollpee.ru

3. Вишняков А.В., Зотов С.В., Кручинин С.В. Опыт разработки архитектуры программного обеспечения САПР вычислительных сетей // Теория и техника радиосвязи. - 2013. - № 1. - С. 98-104.

4. Кручинин С.В. Интеграция онлайн-трансляций в современные браузеры //Научно-исследовательские публикации. 2014. №13(17). С.32-37.

5. Кручинин С.В. Разработка математической модели информационной системы управления электронными документами//Кибер-нетика и программирование. -2014. -2. -С. 78 -87. URL: http://www.e-notabene.ru/kp/article_11553.html DOI: 10.7256/2306-4196.2014.2.115 53

Об авторах:

Кручинин Сергей Владимирович - главный научный сотрудник ООО «ВЭЛБОРН»; siblis@yandex.ru.

Шиков Олег Юрьевич - студент юридического факультета Новгородского государственного университета имени Ярослава Мудрого