@ShadowVasiliy

Добрый день.

Делаю конструктор лендингов и не могу определиться с подходом к хранению контента.
Есть html-блоки из которых пользователь составляет страницу. В блоке он может менять текст и немного внешний вид.

Если не хочется читать, в конце есть выжимка.

Сильно упращенный блок выглядит так:
Проанализировав другие конструкторы, все они разделяют блок на "скелет" и данные блока. Скелет общий для всех, а изменяемые данные всегда разные. Если в конструкторе 100 блоков и 1000 раз их использовали, то будет 100 скелетов и 1000 данных.

При показе страницы они просто накатывают данные на скелет.

Разделенный блок выглядит так:
И отдельно в базе хранится его контент:
Текст блока, который меняет пользователь

Я же не понимаю почему никто не хранит весь html-блок с изменениями целиком. Без разделения.

Плюсы подхода с разделением на скелет и данные:

1. При разделении мы один раз храним скелет и сколько угодно изменений, что сильно снижает занятое место. Ведь html-код в 3-10 раз больше текста на сайте.
2. Мы ограничиваем пользователя на внесение непредвиденных данных. То есть пользователь не сможет испортить что-то за пределами разрешенной области.

Плюсы второго подхода (когда html блок хранится полностью):

1. При изменении архитектуры мы можем легко добавить в html дополнительные атрибуты, классы. В редакторе задать больше гибкости. Например, мы в редакторе не предусмотрели изменения атрибута action в теге form, а потом захотели дать доступ к этому атрибуту и нам не нужно пересоздавать все скелеты, так как весь блок является персональной копией одного пользователя.
2. Более простой механизм работы и хранения данных.

Сухая выжимка:
Нужно хранить html код блоков. Есть два способа хранения.
1. Разделить блок на общие данные (скелет) и приватные (изменения пользователя), при показе страницы накатывать изменения на скелет
2. Не разделять и харанить с каждым изменением весь html-код блока.

Большинство используют первый способ. Я склоняюсь ко второму из-за большей гибкости и простоты.

Какой бы вы выбрали способ и почему?

Ах да, прошу прощения за PHP, но не нашел более подходящего раздела с подходящей аудиторией. Вопрос о web и серверном программировании. Прошу понять.

0

@Phantom-84

ShadowVasiliy, граница достаточно условная. Можно путем настройки перетягивать как в одну, так и в другую сторону. Основные недостатки понравившегося вам способа вы верно обозначили:
- пониженная защищенность;
- повышенная избыточность хранимых данных (атрибуты и т.п. больше относятся к представлению, а представление нужно отделять от фактических данных).

Пример с h1 не самый удачный. h1 действительно чаще остается в шаблоне, а вот уже несколько h2 вперемешку с текстом в обычных абзацах вполне могут быть структурными данными, хранящимися в базе данных.

Добавлено через 6 минут
div по прямому назначению редко хранится в базе данных. Чаще это происходит в качестве технических заплаток, например для оборачивания адаптивных таблиц, хотя оборачивание можно делать и непосредственно перед выводом после извлечения данных из базы данных.

Добавлено через 4 минуты
Про form и action вы тоже что-то непонятное пишете. Не могу себе представить ситуации, когда это действительно нужно. Да, это все в шаблонах обычно хранится.

1

@ShadowVasiliy

Phantom-84, спасибо! Вы помогли построить мысли в правильном направлении
В итоге вопрос теперь стоит в перетягивании границы

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

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

0

@Phantom-84

Я за самый строгий вариант первого подхода. Ужасно наблюдать, когда в базе данных хранятся теги со множеством атрибутов для раскрашивания текста и т.п. Старайтесь обходиться основными тегами для форматирования текста. В крайнем случае добавляйте в список поддерживаемых теги с классами, как отдельные теги.

Изображения и прочие медиа-объекты внутри текста обычно хранятся в виде специальных кодов, но в общем-то допустимо их хранить и в виде тегов, только не нужно сразу к ним прикреплять код конкретных просмотрщиков, плееров и т.п. Делайте привязку перед выводом, а еще лучше сразу на JavaScript.

0