Главным требованием при написании данного приложения является его кроссплатформенность, что исключило использование таких проприетарных технологий, как Adobe Flash, Microsoft Silverlight и JavaFX. Их использование подразумевает наличие на клиентском web-браузере установленного расширения для поддержки той или иной технологии. На мобильных устройствах их поддержка довольно ограничена либо вообще отсутствует.

Также очень важным недостатком этих технологий является то, что текстовая и мультимедийная информация, включённая в приложения, созданные с использованием данных технологий, не может быть полноценно проиндексирована современными поисковыми системами, что, в итоге, как исключает их использования в качестве подсистемы поиска контента на web-сайте, так и ограничивает продвижение конечного web-сайта в глобальных рейтингах поиска [7]. Учитывая новые возможности HTML5 и CSS3, детально описанные в информационной части данной работы, с широкой поддержкой в современных web-браузерах, как на десктопных, так и на мобильных платформах, тройка HTML5, CSS3, JavaScript на сегодняшний день представляет пока единственную универсальную технологию, позволяющую создавать динамичные клиентские кроссплатформенные web-приложения.

JavaScript по, своей сути, является универсальным языком клиентского скриптинга. Так как создаваемое приложение будет активно манипулировать объектами HTML документа (DOM-объектами) и использовать анимацию для создания эффекта присутствия, необходимо выбрать библиотеку, которая бы позволила максимально упростить создание данной функциональности.

На данный момент на рынке программного обеспечения существует несколько подобных библиотек. Рассмотрим наиболее широко используемые из них, а именно jQuery, Prototype и Dojo.

jQuery - это библиотека, фокусирующаяся на взаимодействии JavaScript и HTML. Библиотека jQuery помогает легко получать доступ к любому элементу DOM, обращаться к атрибутам и содержимому элементов DOM, манипулировать ими. Также библиотека jQuery предоставляет удобный API по работе с Ajax. Она предоставляет разработчику следующие возможности:

· Движок кросс-браузерных CSS-селекторов Sizzle, который существует в данный момент в виде отдельного проекта;

· Навигация по дереву DOM, включая поддержку XPath как плагина;

· Поддержка события DOM;

· Визуальные эффекты;

· AJAX-дополнения;

· JavaScript-плагины.

Точно так же, как CSS отделяет визуализацию от структуры HTML, jQuery отделяет поведение от структуры HTML. Например, вместо прямого указания на обработчик события нажатия кнопки, управление передаётся jQuery, идентифицирующей кнопки и затем преобразовывающий его в обработчик события. Такое разделение поведения и структуры также называется принципом ненавязчивого JavaScript.

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

Библиотека jQuery легка в изучении и использовании. Результирующий код получается компактным, легко читаемым и легко поддерживаемым другими разработчиками [8].

Другой схожей по функциональности с jQuery библиотекой является Prototype. Ее главной задачей является добавление поддержки более объектно-ориентированного программирования в JavaScript, нежели манипуляции объектами DOM. Prototype не имеет встроенной поддержки анимации, которая обеспечивается дополнительной библиотекой Scriptaculus, что в результате, выводит ее из разряда легковесных библиотек, так как суммарный исходный код занимает более 200 килобайт.

Третьей из рассматриваемых нами библиотек является Dojo. Это свободная модульная библиотека JavaScript, создана с целью упростить ускоренную разработку основанных на JavaScript или AJAX web-приложений и web-сайтов. Как и jQuery она предоставляет гибкие возможности по манипулированию объектами DOM и их анимацией, но при этом является очень тяжеловесной - объем библиотеки достигает нескольких мегабайт [9].

Резюмируем сравнение описанных библиотек в виде таблицы.

Таблица 2.2 - Сравнение библиотек JavaScript

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

2.3 Описание Model-View-Controller

В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что в общем не удивительно, так как с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Подобное неведение явилось следствием того, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое, и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее, чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная работа посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

«Оригинальный» MVC

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

Впервые паттерн MVC появился в языке SmallTalk в конце семидесятых. Собственно задача была хорошо всем знакомая, надо было придумать архитектурное решение, которое позволяло бы манипулировать графическими представлениями данных некоего приложения, таким образом, чтобы изменение Представления этих данных не влияло на бизнес-логику и данные (Модель) приложения, а так же, чтобы была возможность иметь несколько Представлений для одной Модели. Таким решением и стал паттерн MVC, идея которого родилась в недрах Xerox PARK, и получила свое первое публичное упоминание в документации к SmallTalk'80. В классическом варианте, MVC состоит из трех частей, которые и дали ему название.

Model (Модель)

Под Моделью, обычно понимается часть содержащая в себе функциональную логику приложения, иными словами то, что обычно называем «Business Layer», «Бизнес-слой» или «Слой бизнес логики». Как именно организован этот слой, по большому счету не важно, однако есть ряд ключевых моментов, на которых остановимся позднее. Основная цель паттерна - сделать так, чтобы Модель была полностью независима от остальных частей и практически ничего не знала об их существовании, что позволило бы менять и Контроллер и Представление модели, не трогая саму Модель и даже позволить функционирование нескольких экземпляров Представлений и Контроллеров с одной Моделью одновременно. Вследствие чего, Модель ни при каких условиях не может содержать ссылок на объекты Представления или Контроллера. Обычно различают несколько типов паттернов в зависимости от роли модели.

Passive Model (пассивная модель) - Модель не имеет вообще никаких способов воздействовать на Представление или Контроллер и только используется ими в качестве источника данных для отображения. Все изменения модели отслеживаются Контроллером и он же отвечает за перерисовку Представления, если это необходимо.

Active Model (активная модель) - Модель имеет возможность оповестить Представлениео том, что в ней произошли некие изменения, и Представление может эти изменения отобразить.

Как правило, механизм оповещения реализуется на основе паттерна Observer (обозреватель), Модель просто бросает сообщение, а Представления, которые заинтересованы в оповещении, подписываются на эти сообщения, что позволяет сохранить независимость Модели как от Контроллера так и от Представления, не нарушая тем самым основного свойства паттерна. Классической реализацией паттерна MVC принято считать версию именно с активной Моделью.

View (Представление)

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

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

Controller (Контроллер)

В задачи Контроллера входит реакция на внешние раздражители и изменение Модели и/или Представления в соответствии с заложенной в него логикой. Один Контроллер может работать с несколькими Представлениями, в зависимости от ситуации, взаимодействуя с ними через некий заранее известный интерфейс, который эти Представления реализуют. Важный нюанс, в классической версии MVC Контроллер не занимается передачей данных из Модели в Представление и не является медиатором (Mediator) между Моделью и Представлениями.

Стоит упомянуть, что MVC ни коим образом не определяет каким именно способом Модель взаимодействует с данными и как реализован уровень доступа к данным - это лежит вне зоны ответственности данного паттерна.

Таким образом, типичная схема взаимодействия компонентов паттерна выглядит примерно так: Контроллер перехватывает событие извне и в соответствии с заложенной в него логикой, реагирует на это событие изменяя Mодель, посредством вызова соответствующего метода Модели. После изменения Модель бросает событие о том что она изменилась, и все подписанные на это события Представления, получив его, обращаются к Модели за обновленными данными, после чего их и отображают (рис. 2.1).

Рис.2.1 - Схема MVC

При этом еще в описании оригинального шаблона упоминалось, что выделение отдельного Контроллера не так важно как отделение Представления от Модели и Контроллер вполне может быть интегрирован в Представление, тем более что в классическом варианте MVC логики в Контроллере не очень много [10].

Говоря о типовом решении модель -- представление -- контроллер, нельзя не подчеркнуть два принципиальных типа разделения: отделение представления от модели и отделение контроллера от представления.

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

* Представление и модель относятся к совершенно разным сферам программирования. Разрабатывая представление, думают о механизмах пользовательского интерфейса и о том, как сделать интерфейс приложения максимально удобным для пользователя. В свою очередь, при работе с моделью внимание сосредоточено на бизнес-политиках и, возможно, на взаимодействии с базой данных. Очевидно, при разработке модели и представления применяются разные (совершенно разные!) библиотеки. Кроме того, большинство разработчиков специализируются только в одной из этих областей.

* Пользователи хотят, чтобы, в зависимости от ситуации, одна и та же информация могла быть отображена разными способами. Отделение представления от модели позволяет разработать для одного и того же кода модели несколько представлений, а точнее, несколько абсолютно разных интерфейсов. Наиболее наглядно данный подход проявляется в том случае, когда одна и та же модель может быть представлена с помощью толстого клиента, Web-обозревателя, удаленного API или интерфейса командной строки. Даже в пределах одного и того же Web-интерфейса в разных местах приложения одному и тому же покупателю могут соответствовать разные страницы.

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

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

Данный принцип тесно связан с распространенной проблемой. При использовании толстого клиента с множеством диалоговых окон на экране могут одновременно находиться несколько представлений одной и той же модели. Если пользователь внесет изменения в модель посредством одного представления, эти изменения должны быть отражены и во всех остальных представлениях. В этом случае представление будет выполнять роль "наблюдателя" за моделью: как только модель будет изменена, представление генерирует соответствующее событие и все остальные представления обновляют свое содержимое.

Отделение контроллера от представления не играет такой важной роли, как предыдущий тип разделения. Действительно, по иронии судьбы практически во всех версиях Smalltalk разделение на контроллер и представление не проводилось. Классическим примером необходимости подобного разделения является поддержка редактируемого и нередактируемого поведения. Этого можно достичь при наличии одного представления и двух контроллеров (для двух вариантов использования). Между тем на практике в большинстве систем каждому представлению соответствует только один контроллер, поэтому разделение между ними не проводится. О данном решении вспомнили только при появлении Web-интерфейсов, где отделение контроллера от представления оказалось чрезвычайно полезным.

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

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

сайт электронный программирование клиентский

3. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ

Необходимо осуществить описание программной реализации приложения. В качестве инструмента для реализации поставленных задач данной работы будем использовать PHP Expert Editor и базу данных MySQL.

3.1 UML-диаграммы использования системы

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

Рисунок 3.1 - Информационная модель системы

В соответствии с формулированным требованием, проектируемый web-ресурс можно представить в виде UML-диаграмм использования (рис. 3.2-3.7). Например, подсистема пользователей представлена на рисунке 3.2.

Рисунок 3.2 - UML-диаграмма использования «подсистемы пользователей»

Данная подсистема отвечает за регистрацию, редактирование и просмотр пользователей и их данных. В web-ресурсе предусмотрено три вида пользователей неавторизированные, пользователи с правами «user» и пользователи с правами «admin». Незарегистрированные пользователи могут просматривать информацию и могут зарегистрироваться в системе. Пользователи с правами «user» расширяет возможности незарегистрированного пользователя, и они могут предлагать новости для публикации. Пользователи с правами «admin» могут выполнять любые действия в системе.

Подсистема редакции представлена на рисунке 3.3.

Рисунок 3.3 - UML-диаграмма использования «подсистема редакции»

Так как данный web-ресурс разрабатывается для людей, которые хотят оставаться в центре всех событий и быть в курсе всех новостей, то данной подсистеме выделяет особое внимание. Данная часть системы будет отвечать за действия: создание, просмотр, редактирование, поиск и добавление новостей в избранное.

Предложить новость для публикации могут только авторизированные пользователи, при просмотре новостей будут отрабатывать еще две небольшие подсистемы - похожие и рекомендуемые новости к данной новости. Редактировать новости могут пользователи с правами «admin». Поиск новостей является в свою очередь еще небольшой подсистемой, которая состоит из трех частей: простой поиск, по разделам и расширенный.

Подсистема каталога редакции представлена на рисунке 3.4

Рисунок 3.4 - UML-диаграмма использования «подсистема каталога редакции»

Данная подсистема отвечает за каталогизацию web-ресурса. В системе будет предусмотрено основной каталог, который будет иметь иерархическую структуру и дополнительные каталоги. Новости будут в обязательном порядке привязаны к основному каталогу и по специфике к дополнительным каталогам. Пользователи с правами «admin» смогут добавлять, редактировать каталоги и их разделы. Остальные пользователи смогут просматривать только их содержимое.

Подсистема приватные сообщения представлена на рисунке 3.5.

Рисунок 3.5 UML-диаграмма использования «подсистема приватных сообщений»

Подсистема оповещения на электронную почту представлена на рисунке 3.6.

Данная подсистема отвечает за оповещения таких событий, как «кто-то прислал Вам личное сообщение» и «опубликована новая новость» на электронную почту. Данная часть системы позволяет настраивать, через какой интервал присылать оповещения или вообще не присылать.

Рисунок 3.6 UML-диаграмма использования «оповещения»

Подсистема сообществ представлена на рисунке 3.7.

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

Приступим к проектированию внешнего вида главной страницы. Но сначала для уменьшения количества кода, написанного для каждой страницы веб-сайта, выделим общие части, которые будут отображаться на каждой странице. Такими блоками будут:

1 Логотип сайта

2 Навигационное меню

3 “Подвал“

На главной странице сайта основным содержанием страницы будет информация об основных разделах сайта (Main). Модель главной страницы имеет вид:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<link rel="shortcut icon" href="/images/favicon.ico" />

<link rel="stylesheet" type="text/css" href="/css/style.css" media="screen" />

<link rel="stylesheet" type="text/css" href="/css/lc.css" media="screen" />

</head>

<body>

<div class="page">

{include file="header.tpl"}

<div class="main">

<div class="leftcol">

{include file="leftcol.tpl"}

{include file="rightcol.tpl"}

</div>

<div class="centercol">

{include file="mainpage.tpl"}

</div>

</div>

</div>

{include file="footer.tpl"}

</body>

</html>

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

Каждый такой блок сделан в виде частичных представлений, которые размещены в папке проекта.

Через контекстное меню добавлено частичное представление для логотипа сайта, код которого представлен ниже: