CMS — системи керування вмістом  →  Розробка систем керування контентом (CMS) – архітектурні та інфологічні засади

10. Адміністративна частина сайту та автоматизація побудови інтерфейсу редагування БД

Додати до моєї бази знань

CMS

Структура класів бібліотеки автоматизованої побудови інтерфейсу редагування БД

Клас поля – Field

Клас Field інкапсулює усю логіку роботи з полем таблиці, що включає:

• відображення поля в режимі перегляду;
• створення елементу керування для редагування поля в режимі редагування;
• отримання значення поля із http-параметрів запиту після редагування запису;
• подання значення поля у коректному форматі для SQL-запиту.

Ключові властивості класу:

• ім’я поля;
• тип поля;
• підпис поля;
• значення;
• значення по замовчуванню;
• автоінкрементне поле – прапор;
• налаштування видимості поля в різних режимах відображення таблиці;
• префікс –для іменування поля в html-формі;
• налаштування відображення – CSS-стилі, тощо.

Ключові методи класу:

• конструктор;
• публікація елементу керування для режиму редагування;
• отримати коротке значення – для режиму перегляду;
• отримати значення для SQL;
• отриати значення для елемента керування (поля html-форми);
• записати значення поля, отримане після редагування запису – видобувається із масиву POST.

Клас таблиці – Table

Клас таблиці інкапсулює логіку роботи з таблицею:

• публікація таблиці в режимі перегляду із навігаційними посиланнями для редагування записів;
• формування html-коду форми редагування обраного запису;
• завантаження результатів редагування у внутрішні об’єкти;
• генерація SQL-запитів для перегляду та редагування таблиці.

Ключові описові властивості класу таблиці:

• ім’я таблиці;
• масив об’єктів-полів таблиці;
• підпис;
• ім’я ключового поля;
• спосіб сортування – для перегляду таблиці.

Властивості класу для організації різних режимів відображення та обробки дій:

• ім’я скрипта, через який відбуватиметься уся робота з таблицею – для коректного формування URL;
• дія, яка виконується в даний момент:
  • перегляд;
  • публікація форми редагування;
  • публікація форми додавання запису;
  • виконання дії: редагування, додавання або видалення.

Ключові методи класу:

• конструктор;
• додавання нового поля в масив полів та інші, пов’язані з мета-описом та налаштуванням інтерфейсу, методи;
• головний метод публікації і обробки дій;
• публікація таблиці в режимі перегляду;
• публікація форми редагування/додавання запису;
• отримати SQL-запит SELECT для отримання даних для перегляду таблиці;
• перенесення даних із HTTP-параметрів відправленої форми до внутрішніх об’єктів – полів таблиці;
• генерація SQL-запиту для редагування запису – UPDATE;
• генерація SQL-запиту для додавання запису – INSERT;
• генерація SQL-запиту для видалення запису – DELETE;

Організація роботи застосунку з точки зору HTTP-параметрів

Ключовим параметром HTTP, який сповіщає про наміри користувача, є параметр action – у ньому передається на сервер дія, яку виконує користувач (рис.18). Якщо параметр дії не встановлено, застосовується дія по замовчуванню – перегляд таблиці.
Коли параметр action містить деяку дію, відмінну від browse, також передається ідентифікатор запису, для якого дану дію потрібно застосувати. 

Рис.18. Схема роботи скрипта редагування таблиці БД

Особливості форми редагування запису

Для успішної реалізації редагування запису разом із новим значенням ключового поля потрібно також обов’язково передавати старе значення. Старе значення ключового поля попередньо публікується у формі редагування у прихованому вигляді (hidden). Таким чином, після надсилання форми на сервер об’єкт таблиці має можливість коректно побудувати SQL-запит на зміну запису, вказавши в секції WHERE старе значення ключового поля.

Підготовка скрипта та мета-опис таблиці

На етапі мета-опису таблиці необхідно здійснити наступні кроки:

1. Створити PHP-файл і включити в нього бібліотеку з класами таблиці і поля.
2. Створити об’єкт таблиці і задати ім’я, підпис та ключове поле.
3. Послідовно додати і описати поля таблиці (метод addField).
4. Задати необхідні налаштування, такі як спосіб сортування таблиці тощо.

Режим перегляду таблиці

Для відображення таблиці в режимі перегляду виконуютьсч наступні дії:

1. Формується і виконується SQL-запит на отримання даних таблиці з урахуванням сортування;
2. Друкується описовий заголовок – підпис таблиці;
3. Початок виведення html-таблиці;
4. Цикл по масиву полів – виведення підписів колонок таблиці;
5. Цикл по записам таблиці:
   • Виведення першої комірки з діями – редагувати запис:

   • 
     				<a href=’script.php?action=edit&id=<?=$id?>’>Редагувати запис</a>

   • Завантаження значень полів запису до об’єктів полів;
   • Цикл по масиву полів – виведення комірки із значенням даного поля;
6. Завершення виведення html-таблиці.

Обробка даних html-форми та генерація SQL-запитів

Після приходу даних форми на сервер у вигляді POST-запиту клас таблиці запускає необхідний метод.

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

• завантаження даних форми в об’єкти полів;
• ініціалізація змінної, що зберігає старе значення ідентифікатора запису, який редагується (дане значення разом з усіма полями також повинно надсилатися через форму – через GET-параметр або черех приховане поле);
• генерація події onBeforeUpdate класу таблиці (опціонально); обробник події повинен мати можливість заборонити виконання UPDATE за необхідності;
• генерація SQL-запита UPDATE з використанням мета-інформації з об’єктів-полів та із значеннями, що отримуються за допомогою геттерів getSqlValue() кожного із об’єктів-полів;
• виконання запиту; обробка помилки, якщо вона виникає;
• генерація події onUpdate класу таблиці (опціонально).

Якщо, форма надіслана з метою додавання запису, метод-обробник додавання здійснює такі кроки:

• завантаження даних форми в об’єкти полів;
• генерація події onBeforeInsert класу таблиці (опціонально) з можливістю зупинки подальшого виконання запиту;
• генерація SQL-запита INSERT з використанням мета-інформації з об’єктів-полів та із значеннями, що отримуються за допомогою геттерів getSqlValue() кожного із об’єктів-полів;
• виконання запиту; обробка помилки, якщо вона виникає;
• генерація події onInsert класу таблиці (опціонально).

Якщо, форма надіслана з метою видалення запису, метод-обробник видалення здійснює такі кроки:

• отримання значення ідентифікатора запису для видалення;
• генерація події onBeforeDelete класу таблиці (опціонально) з можливістю зупинки подальшого виконання запиту;
• генерація SQL-запита DELETE з використанням мета-інформації про ідентифікатор запису та його значення;
• виконання запиту; обробка помилки, якщо вона виникає;
• генерація події onDelete класу таблиці (опціонально).

Lookup-поля вибору як засіб реалізації зв'язку один-до-багатьох в інтерфейсі редагування

Lookup-поля та реляційна модель

Під lookup-полем або полем підстановки розуміють такий елемент введення даних в поле запису таблиці, який дозволяє обрати значення із списку, а сам список формується на основі даних іншої таблиці (рис.19).

Рис. 19. Приклад lookup-поля

Lookup-поле відповідає реляційному відношенню один-до-багатьох. Lookup-поле належить таблиці, що представляє сторону «багато» та фактично служить для редагування значень зовнішнього ключа (рис.20). Щоб надати користувачу зручний інтерфейс у вигляді випадаючого списку підписів та позбавити його необхідності оперувати із значеннями зовнішнього ключа створюється даний елемент інтерфейсу. У формуванні lookup-поля беруть участь три поля:

1. поле зовнішнього ключа таблиці, що редагується;
2. поле первинного ключа таблиці-джерела значень;
3. поле, що є підписом із таблиці-джерела значень.

Таблиця зі сторони «один» є джерелом значень для зовнішнього ключа таблиці «багато». Відповідно значення отримуються із колонки первинного ключа. Значення для відображення в інтерфейсі редагування отримуються із колонки підписів. Значення первинних ключів не відображаються в інтерфейсі користувача-редактора таблиці, натомість редактор оперує підписами, замість яких на рівні html-форми та SQL-запиту підставляються значення ключів. 

Рис. 20. Реляційна схема побудови lookup-поля

Реалізація lookup-поля в бібліотеці автоматизованої побудови інтерфейсу редагування БД

Для реалізації lookup-поля в бібліотеці достатньо внести необхідні доопрацювання в клас поля Field, який буде інкапсулювати в собі усю логіку роботи з даним елементом керування. На рівні класу таблиці робота з полем підстановки відбуватиметься прозоро та не потребуватиме додаткових змін у коді класу.

На рівні класу Field слід передбачити:

1. ідентифікацію даного поля як lookup-поля – певний булевий прапорець (isLookup);
2. мета-опис lookup-поля (у методі setLookup), що містить:
   • назву таблиці-джерела (lookupTableName);
   • назву поля-джерела значень (lookupKeyName);
   • назву поля-джерела підписів (lookupCaptionName);
3. підготовку елементу редагування lookup-поля для html-форми:
   • виконати SQL-запит на отримання даних для поля;
   • побудувати html-елемент для редагування (випадаючий список) за принципом ключ-значення;
4. для режиму перегляду browse передбачити виведення відповідного підпису для поля підстановки:
   • на етапі виведення звернутись до методу getLookupCaption(), який в свою чергу здійснить необхідний SQL-запит до таблиці-джерела.

На рівні обробки форм редагування та додавання запису для роботи з lookup не потрібно здійснювати додаткових доопрацювань, так як в POST-запит на етапі відправки форми попадатиме коректне значення ключа lookup-поля, що обумовлюється використанням html-елементів керування з принципом ключ-значення.
Автоматизована побудова інтерфейсу головний-детальний

Користувацький інтерфейс головний-детальний служить для редагування даних, що реалізують відношення один-до-багатьох (рис. 21). Даний інтерфейс є одним із найпоширеніших в застосунках баз даних. 

Рис. 21. Приклад інтерфейсу головний-детальний

Реалізація даної функціональності передбачає створення класу-нащадка Table – SubTable. Екземпляр SubTable відповідає за відображення та редагування таблиці «детальний». SubTable міститиме мета-інформацію про зв'язок з «головною» таблицею (ім’я поля SubTable, що є зовнішнім ключем на «головну»).

У клас таблиці Table необхідно внести зміни, що дозволять зберігати інформацію про наявність детальної таблиці (посилання на екземпляр SubTable).

При відображенні Table серед колонок також з’явиться стовпець, що містить посилання-перехід до «детальної», відповідно до поточного запису «головної» (рис.22).

У свою чергу стандартний інтерфейс SubTable буде доповнено навігаційними можливостями повернення до відповідної «гололвної» таблиці (рис.23). 

Рис. 22. Приклад таблиці «головний» із колонкою для посилань на «детальну». Тут, «Значення фільтра» - посилання на «детальну» таблицю

Рис. 23. Приклад таблиці «детальний» із навігаційними елементами повернення до «головної»

Зверніть увагу на додаткові посилання

Якщо вас цікавить...

CMS

Головний розділ

Розробка систем керування контентом (CMS) – архітектурні та інфологічні засади

Сторінки, близькі за змістом

Розробка систем керування контентом (CMS) – архітектурні та інфологічні засади

CMS — системи керування вмістом