Побудова системи управління вмістом

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

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

Вимоги до проекту. Необхідно створити систему, яка:

· Збільшує продуктивність роботи, дозволяючи авторам концентруватися на статтях, а дизайнерам — на оформленні

· Дозволяє редакторові переглядати статті і вибирати їх для публікації

· Створює одноманітне сприйняття сайту за допомогою шаблонів сторінок

· Надає авторам доступ лише до призначених для них областей сай­та

· Дозволяє легко змінювати оформлення будь-якого розділу або всього сайту

· Запобігає зміні нового вмісту

Редагування вмісту.По-перше, необхідно продумати спосіб введення вмісту в систему, а також методи його зберігання і редагування. Потрібно вибрати метод передачі компонентів статей і оформлення. Існує три можливості.

1. FTP. Авторам і дизайнерам можна надати FTP-доступ до областей Web-сервера. Це дозволить їм завантажувати на сервер файли зі своїх локальних комп'ютерів. Для завантажуваних файлів потрібно буде виробити строгий стандарт іменування (для ідентифікації приналежності зображень до статей). Замість цього можна застосувати засновану на Web систему, яка здійснюватиме ідентифікацію незалежно від FTP-загрузки. Використання FTP створює проблему допусків. Необхідна для даного прикладу гнучкість не дозволяє використовувати FTP для надання користувачам можливості завантажувати файли.

2. Метод завантаження файлів. HTTP-протокол надає метод завантаження файлів за допомогою Web-браузера. Мова РНР дозволяє вирішувати цю задачу дуже просто. Крім того, метод завантаження файлів дає можливість зберігати текст в базі даних замість файлів. Для цього виконується читання в тимчасовий файл і збереження його вмісту в базі даних, а не копіювання в іншу область файлової системи. Метод завантаження файлів в цьому проекті не використовується.

3. Інтерактивне редагування. Користувачі можуть створювати і редагувати документи без участі FTP або іншого методу завантаження файлів. Замість цього авторам можна надати у вікні боль­шое текстове поле, в якому вони зможуть редагувати вміст статей. Цей метод простий, але часто ефективний. Web-браузер не надає яких-небудь можливостей редагування тексту, окрім функцій копіювання і вставки, прису­щих операційній системі. Проте, коли потрібно внести лише невелике измене­ние, наприклад, виправити орфографічну помилку, це можна здійснити дуже швидко. Як і для методу завантаження файлів, дані форми можна записати у файл або зберегти в базі даних.

Перевага баз даних перед файлами для зберігання вмісту. На початковому етапі необхідно прийняти важливе рішення відносно методу зберігання вмісту після його завантаження в систему.

Оскільки спільно з текстом зберігаються метадані, ми вирішили помістити текстову частину вмісту в базу даних. Хоча MYSQL здатний зберігати мультимедійні дані, прийнято рішення зберігати завантажувані зображення у файловій системі. Використання великого двійкового об'єкту (BLOB) в базі даних MYSQL може понизити швидкодію.

У базі даних зберігатимуться лише імена файлів зображень. Дескриптор <IMG SRC> може прямо посилатися на каталог графічних файлів звичайним способом.

Коли об'єм даних великий, важливо оптимізувати їх зберігання. Подібно до того, як ефективність бази даних залежить від правильної індексації, файлова система істотно виграє від добре продуманої системи каталогів.

Мал. 6.1. Структура каталогів для завантаження файлів

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

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

Як приклад візьмемо статтю новин. Заголовок зберігатиметься в своєму полі окремо від тексту. Зображення за своєю природою є окремим компонентом документа. Оскільки заголовок є окремим елементом, для його відображення можна задати стандартний шрифт і стиль, а також легко відокремити заголовок від останньої частини статті, сформувавши головну сторінку заголовків.

Для крупних документів можна застосувати до окремих абзаців відношення один до багатьом. Іншими словами, кожен абзац зберігатиметься в окремому рядку бази даних і матиме зв'язок з ідентифікатором головного документа. Цей вигляд динамічної структури документа дозволить представляти сторінку вмісту для кожного документа і відображувати кожен розділ незалежно або відображувати документ цілком.

Використання метаданих.Вже вирішено, що запис для кожної статті містить заголовок, текст і зображення. Проте ніщо не заважає зберігати в тому ж записі інші дані. Система автоматично вставляє значення, що описують авторство статті і вре­мя її останньої модифікації. Вони можуть автоматично відображуватися в нижній частині статті і служити підписом і міткою часу, позбавляючи автора від необхідності додавання цієї інформації. Крім того, інколи корисно додавати дані, що не відображуються, звані метаданими. Хорошим прикладом служить зберігання ключових слів, які використовуватимуться як індекси пошукового механізму.

Пошуковий механізм витягуватиме ключове слово для кожної статті і на його основі визначати відповідність критеріям пошуку. Це усуває необхідність сканування всього тексту кожної статті. Адміністратор сайту зможе управляти відповідністю ключових слів і фраз певним документам.

У нашому прикладі допускається пов'язувати із статтею будь-яку кількість ключових слів, а також привласнювати кожному ключовому слову "вагове" значення, вказуюче міру його значущості в діапазоні від 1 до 10.

Потім можна розробити алгоритм пошукового механізму, який розташовує со­ответствия статтям згідно людській шкалі значущості. Це замінить складний алгоритм, який інтерпретує англійський текст і приймає рішення залежно від свого обмеженого розуміння, а також управляється фіксованими правилами.

Метадані повинні зберігатися в базі даних. Можна використовувати HTML-дескриптор <МЕТА> або навіть застосовувати XML для створення документів. Проте краще при першій-ліпшій можливості скористатися перевагами бази даних для управління документами.

Форматування виводу.У нашому прикладі сайту новин сторінки відображуються в простому, але структурованому форматі. Кожна сторінка містить ряд статей, сформатованих однаково. Перш за все, заголовок виводиться крупним шрифтом, внизу зліва відображує фотографія, а справа — текст статті. Сторінка цілком міститься в стандартному шаблоні сторінок, що створює послідовність в оформленні сайту.

Мал. 6.2. Логічна структура сторінки.

Цей вигляд компоновки украй популярний — скільки сайтів ви регулярно відвідуєте, де панель меню розташована зліва, а посилання швидкого доступу вгорі? При цьому засоби навігації залишаються незмінними незалежно від сторінки, що переглядається.

Реалізація структури шаблонів, подібної тій, що використовується для оформлення сторінок, дуже проста. У HTML-коде можна знайти дескриптор <TD>, початківець вічко головного вмісту. У цьому місці HTML-код розщеплюється на два файли. Перша половина складає файл заголовка, а друга — нижній колонтитул. Коли відображується сторінка, спочатку виводиться заголовок, потім текст і, нарешті, нижній колонтитул.

Реалізація сайту з шаблоном заголовка і нижнього колонтитулу дозволяє модифікувати оформлення сайту, змінюючи файли шаблонів.

РНР надає дві опції конфігурації, які зручні в даній ситуації. Можна визначити для кожного каталога директиви auto_prepend_file і auto_append_file, які вказують файли, що підключаються до або після виконання будь-якого сценарію.

Проте існують деякі обмеження. Якщо існують сценарії, які не генерують вивід і відправляють заголовок переадресації, такий як

<? header("Location: destination.php"); ?>

файли заголовка і нижнього колонтитулу відображуватимуться, а переадресація не станеться, оскільки вивід вже відправлений до Web-браузер. Це також створює проблеми з cookie-наборум і вбудованими функціями управління сеансами РНР 4, оскільки cookie правильно не функціонуватиме після відправки виводу Web-браузеру.

Управління зображеннями.Автори можуть доповнювати статті своїми фотографіями. Нам необхідна одноманітність оформлення, але що станеться, коли один автор завантажить крупне зображення високої якості, а інший — згорнуту в піктограму картинку?

Виходячи з припущення, що зображення в основному є фотографіями, можна обмежитися лише форматом JPEG і скористатися РНР-функциями для управління графікою.

Напишемо невеликий сценарій resize_image.php, який на льоту змінює розмір зображень, внаслідок чого вони можуть відображуватися з допомогою дескриптор <IMG SRC>. Сценарій наводиться в лістингу 6.21.

Лістинг 6.21. Сценарій resize_image.php змінює розміри JPEG-изображения "на льоту"

<?

if (!$max_width) $max_width = 150;

if (!$max_height) $max_height = 100;

$size = GetImageSize($image); $width = $size[0]; $height=$size[l];

$x_ratio = $max_width / $width; $y_ratio = $max_height / $height;

if ( ($width <= $max_width) && ($height <= $max_height) )

{ $tn_width = $width; $tn_height = $height; }

else if (($x_ratio * $height) < $max_height)

{ $tn_height = ceil($x_ratio * $height); $tn_width = $max_width; }

else {$tn_width=ceil($y_ratio * $width); $tn_height=$max_height; }

$src = ImageCreateFromJpeg($image);

$dst = ImageCreate($tn_width,$tn_height);

ImageCopyResized($dst, $src, 0, 0, 0, 0,

$tn_width,$tn_height,$width,$height);

header("Content-type: image/jpeg"); ImageJpeg($dst, null -1);

ImageDestroy($src); ImageDestroy($dst);

?>

Цей сценарій приймає три параметри — ім'я файлу зображення, максимальну ширину і висоту в крапках. Не варто вважати, що якщо вказаний максимальний розмір 200 х 200, зображення буде масштабовано відповідно до цих значень. Його масштаб буде зменшений пропорційно так, щоб вказані максимальні розміри не перевищувалися. Наприклад, зображення розміром 400 х 300 буде зменшено до розміру 200x150. Таким чином досягається збереження пропорцій зображення.

Зміна розміру зображення на сервері переважно, чим просте завдання атрибутів HEIGHT і WIDTH в дескрипторі <IMG SRC>. Розмір великого зображення з високим дозволом може складати декілька мегабайт. Якщо ж картинку зменшити до прийнятних розмірів, її розмір може не перевищувати 100 Кб. Немає потреби завантажувати файл великого розміру, а потім вказувати браузеру змінити розмір зображення.

Тут використовується функція ImageCopyResized() для масштабування зображень на льоту. Суть операції зміни розміру полягає в обчисленні нових параметрів ширини і висоти. Визначається співвідношення між реальними і максимальними розмірами. Параметри $max_width і $max_height можуть бути передані в одному рядку запиту. Інакше будуть використані стандартні значення, вказані у верхній частині лістингу.

$x_ratio = $max_width / $width; $y_ratio = $max_height / $height;

Якщо зображення вже менше вказаних максимальних розмірів, його ширина і висота залишаються незмінними. Інакше буде використаний коефіцієнт X або Y для рівного масштабування обох розмірів, аби зображення зменшеного розміру не виявилося розтягнутим або сплюснутим:

if ( ($width <= $max_width) && ($height <= $max_height) )

{ $tn_width = $width; $tn_height = $height; }

else if (($x_ratio * $height) < $max_height)

{$tn_height = ceil($x_ratio * $height); $tn_width = $max_width; }

else {$tn_width=ceil($y_ratio * $width); $tn_height=$max_height; }

Огляд проекту. У таблиці. 6.9 міститься перелік файлів даного застосування.

Таблиця 6.9 файлів застосування управління вмістом

Створення бази даних.Лістинг 6. 22 відображує SQL-запити, використовувані для створення бази даних вмісту системи. Цей лістинг демонструє частину файлу create_database.sql. Файл в застосуванні окрім цього містить запити для заповнення бази даних прикладами користувачів і статей.