Затем автор приветствуется с использованием его имени и ему предоставляете возможность выхода из системы. Эта ссылка всегда отображается в верхней част страницы stories.php, что позволяет легко выйти из системы в любой момент. Сценарий logout. php просто сбрасывает значение переменной auth_user. [1]

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

2.3. Компоненты подсистемы и схема хранения данных

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

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

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

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

Другой подход применительно к крупным документам предполагает организацию отдельных абзацев в соответствие с отношением "один ко многим". Другими словами, каждый абзац будет храниться в отдельной строке базы данных и иметь связь с идентификатором главного документа. Такой вид динамической структуры документа по­зволит формировать страницу содержания для каждого документа и отображать каждый раздел независимо либо же отображать документ целиком.

На начальном этапе необходимо принять чрезвычайно важное решение относительно метода хранения содержимого после его загрузки в систему. Поскольку вместе с текстом хранятся и метаданные, благоразумно поместить текстовую часть содержимого в базу данных. Несмотря на то что система MySQL способна хранить мультимедиа-данные все же лучше держать загружаемые изображения в файловой системе. Использование больших двоичных объектов (BLOB) в базе данных MySQL может привести к снижию производительности приложения.

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

Когда объем данных велик, очень важно оптимизировать их хранение. Подобно тому, как эффективность базы данных зависит от правильно выбранной индексации, файловая тема существенно выигрывает от хорошо продуманной системы каталогов. [1]

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

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

Реализация сайта с шаблонами заголовка и нижнего колонтитула позволяет легко и просто изменять оформление сайта, внося требуемые модификации только в фай­лы шаблонов.

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

Базируясь на предположении, что изображения, в основном, представляют собой фотографии, можно ограничиться лишь форматом JPEG и для манипулирования графикой воспользоваться соответствующими PHP-функциями.

В нашем проекте существует довольно простой сценарий resize_image.php, который на лету изменяет размер изображения, в результате чего оно может выводиться с использованием дескриптора <IMG SRC>. Этот

сценарий принимает три параметра, в число которых входит имя файла изображения, максимальная ширина и высота в точках. Не стоит полагать, что если указан максимальный размер 200 х 200, то изображение будет масштабировано в соответствии с этими значениями. Наоборот, масштаб изображения будет пропорционально уменьшен таким образом, чтобы заданные максимальные размерыне превышались. Например, изображение размером 400 х 300 будет уменьшено до размера 200x150. В результате максимально точно сохраняются пропорции изобра­жения.

Динамическое (то есть, на лету) изменение размеров изображения на сервере гораздо предпочтительнее, нежели простое задание атрибутов HEIGHT и WIDTH в дескрипторе <IMG>. Размер большого изображения с высоким разрешением может составить несколько мегабайт. Если же картинку уменьшить до приемлемых размеров, то размер может оказаться менее 100 Кб. Следовательно, нет надобности загружать на сервер файл большого размера, а затем предлагать браузеру изменить размеры изображения.

Ключевой аспект операции изменения размеров состоит в вычислении новых параметров ширины и высоты. При этом определяется соотношение между реальными и максимальными размерами. Параметры $max_width и $max_height можно пере­дать в одной строке запроса, в противном случае будут задействованы стандартные значения, определенные вначале сценария.

Если изображение уже меньше заданных размеров, его ширина и высота остаются неизменными.

Для хранения данных, необходимых для работы системы используется 6 таблиц: keywords, messages, pages, stories, writer_permissions, writers.

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

Таблица 2. Структура таблицы keywords базы данных

Поле story – это индивидуальный номер статьи, по которому она однозначно определяется, keyword – ключевое слово, weight – вес (цена) слова (изменяется от 1 до 10). Чем больше вес слова, тем больше релевантность этой статьи к запросу поиска. Во втором столбце указан тип данных для каждого поля, а в скобках максимальная длина значения поля.