9. Конструювання нових типів контенту в CMS

CMS

Незважаючи на велике розмаїття програмних систем, що застосовуються для керування контентом, актуальним завданням залишається розробка та вдосконалення засобів універсального керування інформаційними об’єктами Web-ресурсів, що дозволяє спростити створення нових ресурсів різного призначення, а також забезпечує ефективні механізми їх супроводження та налаштування. Зокрема актуальним є розв’язання наступних задач: створення спеціалізованих інформаційних об’єктів із користувацьким набором полів, керування відображенням таких об’єктів, сортування, фільтрація та навігація по сховищу створених об’єктів, інтеграція сховища інформаційних об’єктів із загальним сховищем контенту, керування ієрархією об’єктів, класифікація та групування об’єктів тощо.

Серед систем з відкритим кодом Drupal надає найширші можливості по виконанню вказаних задач. Недоліком системи є така організація структури даних та програмного коду, яка зумовлює велике навантаження на сервер баз даних. Це в свою чергу сповільнює швидкість генерації Web-сторінок ресурсу та вимагає великого ступеня кешування, що не завжди доцільно. Крім того в даній системі ускладнена робота по налаштуванню відображення інформаційних об’єктів, а також робота по загальному адмініструванню сайту.

Загалом проблема подання спеціалізованих інформаційних об’єктів в контексті CMS є дотичною до напрямку об’єктно-реляційного відображення ORM (Object-relational mapping), об’єктно-реляційних баз даних та інших напрямів, пов’язаних із моделюванням даних та знань.

Створення спеціалізованих інформаційних об’єктів із користувацьким набором полів в CMS є затребуваним завданням при побудові складних інформаційних веб-ресурсів.

Загальні елементи контенту

Ключовою інформацйною сутністю систем керування вмістом сайтів (CMS) є сторінка або елемент контенту. Як правило, в базі даних CMS-системи існує спеціальна таблиця, що представляє дану сутність, характеризуючи її певним набором полів. Основними полями загального елемента контенту є заголовок, html-текст, анотація та ін. В залежності від системи по-різному можуть бути реалізовані ієрархічні та структурні зв’язки між елементами контенту. В Drupal загальний елемент контенту позначається терміном Node (вузол), у Wordpress – Post (допис), в Joomla – матеріал. Доцільним вважається таке проектування системи, де сутністю, що відповідає за сторінки є множина елементів контенту V={v_i}.

Інтеграція і розмежування спеціалізованих інформаційних об’єктів із загальними елементами контенту

Спеціалізовані інформаційні об’єкти веб-ресурсу можуть реалізовуватись двома шляхами: (1) як доповнення до набору полів загального елемента контенту – приєднання до контенту; (2) як окрема незалежна сутність, не пов’язана напряму з елементами контенту загального типу – розмежування контенту та спеціалізованих об’єктів (рис.16).

Приєднання до загального контенту вигідно використовувати у випадках, коли сутність, яку потрібно представити, є незначним розширенням сторінки загального типу і повинна грати роль деякого інформаційного елемента контенту, аналогічного сторінкам сайту. В Drupal це може бути реалізовано за допомогою функціональності Content types, що стала стандартною у версії 7 даної CMS. Wordpress реалізує згадані функції за допомогою додатка Custom Post Type. Для Joomla існує цілий набір розширень, що реалізують дану функціональність, найбільш відомим з яких є K2. K2 додає більше десятка таблиць в базу даних і фактично підмінює систему створення контенту в Joomla.

Рис. 16. Способи реалізації спеціалізованого інформаційного об’єкта у відношенні до загальних елементів контенту

Розмежування загального контенту та спеціалізованих об’єктів в CMS передбачає наявність незалежних сутностей в БД системи, що відповідають за подання таких об’єктів. При цьому редагування даних об’єктів відбувається за допомогою окремого інтерфейсу, а набір полів не обтяжується стандартним набором полів загального елемента контенту. Спосіб відображення даних об’єктів на сайті повинен налаштовуватись за допомогою спеціальних засобів. Таким чином відбувається керування виглядом таких об’єктів, налаштування способів навігації по їх сховищу та інші спеціалізовані функціональні можливості.

Розмежування загального контенту та спеціалізованих об’єктів у згаданих CMS можна порівняти із розширенням стандартного набору полів для такої сутності CMS як елемент таксономії. Таксономія в математиці – це деревоподібна структура класифікацій деякого набору об’єктів. Таксономія в CMS використовується для різних типів класифікацій елементів контенту: для створення ієрархії розділів сайту, для оргінізації міток (тегів), для організації меню та навігації, для тематичної класифікації контенту.

Drupal та Wordpress містять засоби створення таксономії (Wordpress використовує термін «категорії»). У цих системах на основі згаданих вище модулів для елементів таксономії можуть створюватись додаткові поля, у такому випадку окремі розділи таксономії можуть розглядатися як набори спеціалізованих інформаційних об’єктів.

Порівняно із стандартними елементами контенту, елементи таксономії не будуть містити значного переліку стандартних полів, тому такий метод опису спеціалізованих об’єктів можна розглядати як варіант розмежування контенту та відповідних об’єктів. Натомість слід зазначити, що такий спосіб не є строгим розмежуванням, і маніпуляції з новоствореними об’єктами будуть обтяжуватись стандартним шаром обробки, характерним для кожного елемента таксономії.

Реляційна реалізація спеціалізованих інформаційних об’єктів CMS

Робота по керуванню спеціалізованими інформаційними об’єктами в контексті CMS передбачає опис нового типу контенту як нової сутності в інформаційній системі, що повинно включати:

загальний опис створюваної сутності, що включає такі характеристики як ім’я для програмного опрацювання та підпис для відображення користувачам;

опис набору полів, які повинні характеризувати відповідні інформаційні об’єкти, що включає власне перелік полів, а також опис кожного окремого поля із зазначенням його імені, підпису, типу даних та ін. інформації;

створення інфраструктури для збереження екземплярів новостворюваної сутності, тобто безпосередніх об’єктів із значеннями їх полів;

налаштування способу відображення об’єктів на сайті, їх адміністрування, а також будь-яких інших засобів роботи з ними.

Таким чином спеціалізовані об’єкти в БД CMS-системи декомпонуються на такі сутності, які повинні певним чином обов’язково відображатися в системі:

«тип об’єкту»;

«поля об’єкту»;

«об’єкти» (або екземпляри);

«значення полів» об’єктів.

У випадку, коли для створення об’єкта застосовується спосіб приєднання до контенту, роль «об’єкту» виконуватиме сторінка загального типу, до якої буде приєднано спеціалізовані «значення полів» відповідно до «типу об’єкту». У випадку розмежування спеціалізованих об’єктів та контенту, «об’єкт» буде представлено окремою сутністю в базі даних.

Реляційна логіка та можливості сучасних SQL-систем допускають велике розмаїття способів реалізації спеціалізованих інформаційних об’єктів в контексті бази даних CMS. Основні способи подані на рис. 17 у вигляді прототипів інформаційно-логічних моделей реляційної бази даних CMS-системи. Деякі моделі вимагають застосування інструкцій DDL (створення таблиць) на етапі додавання нових типів об’єктів. Розглянемо кожну із поданих моделей.

Готова об’єктно-реляційна надбудова (рис.17., модель 1). Без застосування DDL-інструкцій. Недоліком моделі є використання однієї таблиці для збереження значень різних спеціалізованих полів, що вимагає або використовувати різні колонки для збереження значень різних типів, або накладати обмеження на тип даних спеціалізованих полів. Іншим варіантом є застосування окремих таблиць для кожного з типів даних.

Об’єктно-реляційна надбудова «Нове поле – нова таблиця» (рис.17., модель 2). Потребує застосування DDL з метою створення окремих таблиць для зберігання «значень полів». Дана модель є природним розвитком попередньої – тут вирішується згадана проблема подання полів різних типів. Відбувається це за рахунок створення спеціалізованих таблиць для кожного з полів. Недоліком даної моделі є складність «збирання» об’єкта, так як об’єкт виявляється розподіленим між різними таблицями, і його композиція вимагає значних SQL-витрат.

Природна реляційна модель «Новий тип об’єктів – нова таблиця» (рис.17., модель 3). Потребує застосування DDL для створення таблиць, що представляють об’єкти стандартним для реляційних БД чином – кожен запис таблиці представляє об’єкт, кожне поле – значення поля об’єкта. Додаткова мета-інформація про тип об’єктів та налаштування полів можуть зберігатися у відповідних таблицях. Якщо застосовується приєднання об’єктів до контенту, тоді між таблицею сторінок та таблицею певного типу об’єктів існуватиме зв’язок «один-до-одного» (1–0..1). З іншого боку дана модель є найбільш природним рішенням у випадку розмежування контенту і інформаційних об’єктів. При цьому для реалізації спеціалізованої бізнес-логіки для маніпуляції об’єктами доцільним є наявність в CMS відповідного API для роботи із спеціалізованими об’єктами.

Модель тегів (рис.17., модель 4). Без використання DDL. Застосовується принцип тегування: сторінці, що є об’єктом, призначається набір міток, кожна з яких представляє деяку характеристику об’єкта, тобто значення деякого поля. Тут кожна мітка в таблиці тегів відповідає деякому одному значенню поля. Значення полів (тобто теги) можуть групуватися в словники, тоді словник представлятиме деяке поле, а теги – область його значень. Даний підхід має значні обмеження у виразності опису об’єктів, проте він є дуже зручним у випадку, коли спеціалізовані об’єкти використовуються для фільтрації та групування контенту за деякими ознаками. Кожне значення поля отримує свій власний ідентифікатор, тому формування URL та відповідні SQL-запити по видобуванню об’єктів виконуються технічно просто.

Рис.17. Способи реляційної реалізації спеціалізованих інформаційних об’єктів CMS

© Титенко С. В. Інформація курсу по матеріалам:
Web-орієнтовані інформаційні системи. Методичні вказівки до вивчення дисципліни для студентів напряму підготовки 6.050103 «Програмна інженерія» / Титенко С. В. – К.: НТУУ «КПІ» 2015. – 51с.