Метод загрузки файлов

2. Метод загрузки файлов

HTTP-протокол предоставляет метод загрузки файлов при помощи Web-браузера. Язык РНР позволяет решать эту задачу очень просто и эффективно.

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

3. Интерактивное редактирование

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

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

Как и при методе загрузки файлов, данные формы можно записать в файл либо сохранить в базе данных.

В нашем проекте реализуется как раз последний метод ввода содержимого в систему.

Итак, после того, как статья введена, ее можно отправить на редактирование. Для этого выбирается тематика статьи (в нашей системе это новости, компьютеры, спорт и музыка) и после этого материал отсылается соответствующему редактору. При входе редактора в систему у него появляется список статей, предназначенных для редактирования. Он может начать редактирование, написать сообщение автору статьи либо написать свою статью. При написании статью в чужой раздел у него будут права обычного автора на эту статью. Кстати, статью может редактировать и автор, пока редактор не нажмет ссылку «Готово». После нажатия этой ссылки статья становится недоступной ни для редактора, ни для автора. Она переходит в распоряжение администратора. Он может ее редактировать, удалить либо, что наиболее вероятно, опубликовать ее на сайте.

Из рис.3 видно, что на протяжении своего маршрута документ попадает к трем участника процесса документооборота. То есть весь процесс обработки документа можно условно разделить на три этапа: создание, редактирование и публикация. Однако это разделение, как и названия этапов, достаточно условны потому, что границы между этими этапами не такие конкретные, как может показаться с первого взгляда. Например, администратор имеет доступ к документу еще на этапе редактирования. Он может следить за ходом редактирования, а также имеет право сам править или даже удалить документ. На схеме это никак не указано, так как в общем-то это дополнительная функция системы и принципиально ничего не изменяет в архитектуре системы. Она только дает больше прав администратору.

1

Автор статьи

(создание)

2

Редактор раздела

(редактирование)

Рис. 3. Маршруты документов в системе

На рис. 4 показано, как эта подсистема маршрутизации документа вписывается в общую логическую структуру информационного сервера.

Сервер БД

Transaction

(Транзакция)

Сервер приложений

Web-сервер

Пользователь

Query

Query

(Запрос)

Подсистема маршрутизации документов

Подсистема типизации документов

Схемы отображения документов

Рис. 4. Описание логической структуры информационного сервера

2.2. Организация политики безопасности в рамках подсистемы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поле	Тип
story	int(11)
keyword	varchar(32)
weight	int(11)

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

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

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

Поле	Тип
message_id	int(11)
from_user	varchar(32)
to_user	varchar(16)
body	text
read	char(1)
date	int(11)

Единственное, что хотелось бы отметить в этой таблице – это наличие поля read, которое может принимать значения 1 либо 0. При создании сообщения этому поля присваивается значение 0, а после того, как тот пользователь, которому оно адресовано, открывает страницу с сообщениями ему присваивается 1. Это служит для того, чтобы как-то выделить новые непрочитанные сообщения.

В таблице pages есть всего 2 поля: это название раздела и краткое его описание.

А вот таблица stories наиболее крупная из всех – она служит собственно для хранения статей и является основой всей системы.

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

Поле	Тип
id	int(11)
writer	varchar(16)
page	varchar(16)
headline	text
story_text	text
picture	text
created	int(11)
modified	int(11)
published	int(11)
for_admin	char(1)

Итак, поле id – индивидуальный номер статьи, writer – автор статьи, page – к какому тематическому разделу относится данная статья, headline – заголовок, story_text – основной текст, picture – адрес файла с изображением. Следующие 3 поля предназначены для работы с датой, соответственно создания, редактирования и публикации документа. Последнее поле по своей функциональности похоже на поле read из таблицы messages: оно может принимать 0 или 1. Поле принимает значение 1, когда редактор раздела нажимает ссылку «Готово», которое служит для отправки статьи администратору. То есть, когда в этом поле стоит 1, то уже не автор, не редактор не имею доступа к этому документу – он уже предназначен для проверки администратором.

Таблица writer_permissions служит для присвоения редакторам прав управления тем или иным разделам. Кстати, редакторы определяются в последней таблице writers последним полем editor.

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

Поле	Тип
username	varchar(16)
password	varchar(16)
full_name	text
editor	char(1)

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

Заключение

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

Были исследованы и проанализированы основные принципы создания ИС, ее структура и функциональность, взаимодействие основных компонентов.

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

Была разработана, создана и протестирована собственная подсистема документооборота, в которой реализовались основные принципы построения и взаимодействия ИС, а также основная функциональность работы.

Список литературы

Веллинг Л., Томасон Л. Разработка Web-приложений с помощью PHP и MySQL – М.: Издательский дом «Вильямс», – 2003. – 800с.: ил.

Гилмор В. PHP 4. Учебный курс – СПб.: «Питер», – 2001. – 352с.: ил.

Курбацкий А. Н. Автоматизация обработки документов - Мн.: БГУ, 1999. - 221с.: ил.

Приложение 1. Листинги SQL-запросов по созданию таблиц

Листинг 1. SQL-запрос создания таблиц базы данных

# БД : `content`

#

# --------------------------------------------------------

#

# Структура таблицы `keywords`

#

CREATE TABLE `keywords` (

`story` int(11) NOT NULL default '0',

`keyword` varchar(32) NOT NULL default '',

`weight` int(11) NOT NULL default '0'

) TYPE=MyISAM;

# --------------------------------------------------------

#

# Структура таблицы `messages`

#

CREATE TABLE `messages` (

`message_id` int(11) NOT NULL auto_increment,

`from_user` varchar(16) NOT NULL default '',

`to_user` varchar(16) NOT NULL default '',

`body` text,

`read` char(1) NOT NULL default '0',

`date` int(11) default NULL,

PRIMARY KEY (`message_id`)

) TYPE=MyISAM AUTO_INCREMENT=20 ;

# --------------------------------------------------------

#

# Структура таблицы `pages`

#

CREATE TABLE `pages` (

`code` varchar(16) NOT NULL default '',

`description` text,

PRIMARY KEY (`code`)

) TYPE=MyISAM;

# --------------------------------------------------------

#

# Структура таблицы `stories`

#

CREATE TABLE `stories` (

`id` int(11) NOT NULL auto_increment,

`writer` varchar(16) NOT NULL default '',

`page` varchar(16) NOT NULL default '',

`headline` text,

`story_text` text,

`picture` text,

`created` int(11) default NULL,

`modified` int(11) default NULL,

`published` int(11) default NULL,

`for_admin` char(1) NOT NULL default '0',

PRIMARY KEY (`id`)

) TYPE=MyISAM AUTO_INCREMENT=65 ;

#

# Структура таблицы `writer_permissions`

#

CREATE TABLE `writer_permissions` (

`writer` varchar(16) NOT NULL default '',

`page` varchar(16) NOT NULL default ''

) TYPE=MyISAM;

# --------------------------------------------------------

#

# Структура таблицы `writers`

#

CREATE TABLE `writers` (

`username` varchar(16) NOT NULL default '',

`password` varchar(16) NOT NULL default '',

`full_name` text,

`editor` char(1) NOT NULL default '0',

PRIMARY KEY (`username`)

) TYPE=MyISAM;

Приложение 2. Листинги основных PHP скриптов

Листинг 2. Файл stories.php (основной файл системы)

Если Вы новый пользователь, то зарегистрироваться можно тут.

Вход: Логин: Пароль: