55
2) Система является простой и недостаточно масштабируемой для
определенных задач (например, сайты с широкой функциональностью).
3) Недостаточные возможности редактирования как компонентов, так и
самой системы по причине простоты интерфейса. Также изначально
система имеет ограниченный набор функций, но их можно расширить
при помощи дополнений.
4) Система WordPress не подразумевает того, что разработчику может
понадобиться создавать собственные таблицы в БД. По этой причине
система требует хранить все данные пользователя только в заранее
предусмотренных разработчиками таблицах.
5) WordPress не является SEO дружественной системой управления
содержимым по то причине, что что созданные на ней сайты
воспринимаются многими поисковыми системами как молодые,
неинформативные и малоавторитетные сайты, что значительно
усложняет их продвижение в сети.
Преимуществами системы управления содержимым MODX являются:
1) Система является бесплатной, и имеет открытый исходный код, что
позволяет не только использовать ее практически без ограничений, но и
дает возможность разработчикам разрабатывать свои дополнения.
2) MODX не имеет высоких требований к хостинг провайдерам. Для работы
системы требуется только веб-сервер Apache (или IIS) с поддержкой PHP,
и сервер баз данных MySQL, причем для переноса системы на другие
сервера достаточно только создать базу данных, и скопировать каталог с
ней. При этом, благодаря продуманной архитектуре ядра системы и
систем кеширования достигается очень высокая скорость загрузки
страниц и ресурсов.
3) MODX является универсальной системой управления содержимым, то
есть подходящей для создания проектов различного назначения – от
56
одностраничных сайтов, до сложных и многообразных систем, имеющих
высокую посещаемость.
4) Система MODX является SEO ориентированной, так как позволяет
описывать адреса страниц, задавать описания и необходимые заголовки
как для внутренних описаний, так и для продвижения сайтов в поисковых
системах, за что в системе отвечает отдельный SEO модуль, идущий в
комплекте.
5) Одним из плюсов MODX является то, что данная система позволяет
одновременно разрабатывать нескольких сайтов на одном экземпляре
системы, причем возможно использование общих ресурсов.
6) Система имеет крайне простой интерфейс администратора, который
обеспечивает удобный и быстрый доступ к любым инструментам и
разделам сайта и представляет собой древовидную структуру с
неограниченными уровнями вложенности.
7) Благодаря развитой системе шаблонов MODX позволяет реализовать
абсолютно любой дизайн сайтов, причем так как система имеет
собственный синтаксис тегов, это позволяет создавать чистый код
шаблонов, что затруднительно в других системах управления
содержимым. Так же важно то, что система позволяет полностью
контролировать исходный код шаблонов (то есть не генерирует лишнего
кода) и позволяет использовать различные шаблонизаторы.
8) Система написана с использованием ООП, поддерживает ORM xPDO
реализующая паттерн Active Record, широко использует подход AJAX.
Основные недостатки MODX:
1) Для работы с MODX необходимо иметь хотя бы минимальный опыт
работы по созданию сайтов (как минимум язык разметки HTML и таблиц
стилей CSS).
2) Практически полное отсутствие русскоязычной документации, хотя в
последнее время эта ситуация стала исправляться.
57
3) Система имеет слишком мало готовых серьезных решений, такие, как
например, интернет-магазины.
4) В системе иногда проявляются проблемы с русским языком (проблемы,
связанные с кодировками), также встречаются проблемы с не
поддерживаемыми расширениями.
К достоинствам системы управления содержимым Drupal следует отнести:
1) Система распространяется с открытым исходным кодом, и является
бесплатной, в связи с чем имеет многочисленное сообщество
разработчиков и пользователей, а также обширную документацию.
2) Для Drupal разработано огромное число модулей, расширяющих
изначальный функционал системы. Для разработчиков практически не
существует ограничений при разработке сайтов с использованием Drupal
по той причине, что система была изначально была создана с учетом их
знаний и умений.
3) Одно из главных достоинств Drupal заключается в его гибкой
архитектуре. Систему возможно использовать для построения сайтов
любых типов и сложности: от простейших блогов до социальных сетей.
4) Наряду с MODX Drupal располагает встроенной системой кеширования,
которая позволяет снижать нагрузку на сервера и сокращать время
генерации страниц сайтов. Кеширование запросов к базе данных
позволяет избежать сложных запросов, что повышает
производительность сервера БД.
5) В отличие от других систем управления содержимым, в Drupal имеется
собственная полнотекстовая система поиска, реализованная на уровне
ядра системы, которая показывает достойные поисковые результаты на
уровне созданных с ее помощью сайтов.
Недостатками системы управления содержимым Drupal можно считать:
58
1) Сложность системы. По той причине, что данная система создавалась в
первую очередь для разработчиков, то для полноценного изучения
платформы может понадобиться значительное количество времени.
2) Несмотря на наличие API, система практически не использует
возможности ООП языка программирования PHP.
3) Интерфейс администрирования системы перегружен, и явно
недружелюбен к пользователям системы.
4) Drupal создаёт избыточную нагрузку на сервера баз данных, что при
серьезных нагрузках может значительно повысить стоимость владения
сайтами за счет необходимости масштабирования системы.
В первой части второй главы данной дипломной работы была
рассмотрена типовая архитектура систем управления сайтами, и их основные
компоненты, такие как ядро базы данных, ядро системы, модули системы
управления содержимым, административная панель и пользовательское
окружение. Так же в первой части описан процесс функционирования
шаблонизаторов, описаны основные принципы построения системы
безопасности систем управления содержимым.
Во второй части второй главы были описаны пять самых популярных на
данный момент системы управления содержимым, такие как 1С-Битрикс,
Joomla!, WordPress, MODX, Drupal, их основные свойства, функционал и
особенности.
В третьей, заключительной части второй главы был произведен
подробный анализ достоинств и недостатков систем управления содержимым,
описанных во второй главе.
Полученные в первой и второй главе выводы и знания позволяют
перейти непосредственно к разработке собственной системы управления
содержимым что и будет сделано в третьей, заключительной главе данной
дипломной работы.
59
ГЛАВА 3. РАЗРАБОТКА ДИНАМИЧЕСКОЙ ИНФОРМАЦИОННОЙ
СИСТЕМЫ УПРАВЛЕНИЯ САЙТОМ
3.1. Разработка серверной части системы управления содержимым
Данная система управления содержимым разрабатывается на языке
программирования Java с использованием фреймворка Spring. В данной главе
описывается работа с основными данными приложения, создание, удаление
пользователей и связанных с ними статей. Все данные приложения хранятся в
СУРБД в соответствующих таблицах, которые будут описаны в дальнейшем.
В данном приложении широко используется Spring Boot – инструмент
для создания, и быстрой настройки каркаса приложения, позволяющий
производить быструю сборку и развертку приложения (за счет встроенных
серверов приложений Apache Tomcat или Jetty) с отличными возможностями
логирования, что позволяет в реальном режиме работы приложения находить
ошибки и оперативно устранять их. Важно обратить внимание на то, Spring
Boot не является инструментом генерации кода (он генерирует только
единственный метод main и структуру каталогов). Так же Spring Boot позволяет
без лишних сложностей создавать приложения, полностью построенные на
аннотациях, то есть без использования XML файлов конфигурации проекта, что
сильно упрощает их структуру, и максимально поддерживает авто
конфигурации (например, при существующей зависимости на Mongo DB и
отсутствии ручной конфигурации, Spring Boot автоматически будет
подключаться к localhost:27017, а при наличие ручной конфигурации перекроет
на указанный разработчиком путь).
Управление зависимостями осуществляется при помощи Gradle –
системы автоматической сборки приложений, использующая DSL на Groovy в
отличии от XML конфигураций Apache Maven или Ant. Gradle был специально
разработан для расширяемых многопроектных сборок, и автоматически
выбирает изменившиеся классы для увеличения скорости сборки проектов.
60
3.1.1. Разработка каркаса системы управления сайтом
Каркас приложения создается при помощи инструмента Spring Boot
версии 1.5.8.RELEASE с использованием инициализатора https://start.spring.io,
который автоматически создает каркас приложения со следующими
зависимостями:
1. spring-boot-starter-freemarker: библиотеки поддержки веб-
шаблонизатора freemarker (Подробное описание и работа с ним
подробно описана в главе 3.2.).
2. spring-boot-starter-security: подключаемый набор библиотек,
обеспечивающий как общую безопасность приложения, так и
довольно широкие возможности для авторизации пользователей и
администраторов системы (Подробное описание и работа с
библиотекой описана в главе 3.1.3.).
3. spring-boot-starter-data-jpa: библиотеки поддержки Java Persistence
API (JPA) для работы с данными приложения (Подробное описание
в главе 3.1.2.).
4. spring-boot-starter-test: включает в себя поддержку интеграции
тестов для Spring приложений (Spring Test), библиотек JUnit,
Hamcrest и Java фреймворк Mockito.
Так как основной системой сборки данного проекта является Gradle, то в
конфигурационный файл build.gradle (Приложение 1) добавлены следующие
используемые в дальнейшем библиотеки:
1. spring-boot-starter-actuator - используется для мониторинга работы
частей приложения и используемых им ресурсов.
2. sourceforge.jtds:jtds:1.3.1 - данная библиотека является драйвером
поддержки СУРБД Microsoft SQL Server. С учетом использования
ORM, драйвер без усилий можно заменить для использования с
другими реляционными системами баз данных.
61
3. commons-lang3 - библиотека используется в приложении с целью
повышения удобства работы с датами и временем.
4. Jquery-1.11.3 - включает в себя поддержку JavaScript библиотеки
jQuery, которая использования в клиентской части приложения, и
фреймворком клиентской части приложения Bootstrap.
5. Bootstrap - библиотека, используемая как основной фреймворк
клиентской части данного приложения.
6. Holder.js - JavaScript библиотека используемая для генерации
границ возможных изображений, и будет в будущем удалена из
зависимостей проекта.
Структура проекта состоит из каталогов main/java, где расположены все
классы приложения, main/resources. В пакете com.platform имеются следующие
пакеты:
1. api - пакет для API классов приложения.
2. configuration - пакет для конфигурационных классов приложения.
3. controllers - пакет, содержащий в себе классы-контроллеры.
4. domain - пакет содержащий в себе описания моделей приложения.
5. repository - в данном пакете находятся классы JPA репозиториев.
6. service - в пакете находятся сервисные классы приложения.
7. util – в данном пакете находятся системные классы для работы с
датами, временем, генераторы паролей, и другие.
Каталог ресурсов приложения main/resources содержит в каталоге /static
таблицы стилей (CSS), необходимые шрифты, используемые изображения и
JavaScript файлы. В каталоге /templates находятся шаблоны страниц
пользовательского окружения, которые будут описаны в главе 3.2., и в корне
каталога /resources - файлы общих настроек приложения application.properties
(Приложение 2) и первоначального заполнения базы данных data.sql
(Приложение 3).
62
3.1.2. Реализация системы доступа к базе данных
В описываемой системе управления содержимым, основное внимание
уделяется максимальному хранению всех возможных данных в СУБД. Все
данные приложения находятся в одной базе данных, и разбиты на таблицы по
классам сущностей:
Основные данные – общие данные приложения, такие как название
приложения, постоянные текстовые данные приложения,
переменные приложения. Эти данные находятся в одной строке БД,
что позволяет довольно легко создавать однотипные сайты с
разным информационным наполнением даже без использования
шаблонов, что очень удобно в корпоративной среде по той причине,
что различные сайты можно создавать с одинаковым дизайном без
работы с шаблонизаторами.
Пользователи системы - таблица, включающая в себя данные о
пользователях, такие как логин (в конкретном случае e-email), хеш
пароля и роль пользователя.
Статьи пользователей – таблица, включающая в себя заголовок
статьи, ее содержимое, автора (с привязкой к пользователю), и дату
ее создания.
Комментарии к статьям пользователей системы – таблица,
аналогичная вышеописанной, содержит данные о комментариях,
имени пользователя от имени которого был написан комментарий,
и дату.
Для доступа к СУРБД (в данном случае ей является Microsoft SQL
Server), достаточно импорта JDBC драйвера в файле build.gradle (Приложение
1), и указания параметров подключения в файле application.properties
(Приложение 2), которые заключаются в указании имени драйвера, полного
пути до базы данных, имени пользователя и пароля, и диалекта СУРБД.
63
Диалекты позволяет приложению работать с различными СУРБД, то есть при
корректном описании классов-моделей, для использования других СУРБД чаще
всего достаточно заменить драйвер, путь к базе данных и ее диалект. Параметр
конфигурации spring.jpa.hibernate.ddl-auto=create предназначен для того, чтобы
при каждой развертке приложения база данных заполнялась из файла data.sql
(Приложение 3) с уничтожением старых, и созданием новых таблиц и данных,
указанных в нем, а параметр spring.jpa.show-sql=false служит для отображения
всех SQL запросов, и он очень важен при отладке приложения в случае ошибок
при работе с базами данных (при значении true).
3.1.3. Реализация безопасности системы управления сайтом, модели
данных, репозитории
Система безопасности данной системы управления сайтом построена c
использованием программной платформы Spring Security с хранением
пользовательских данных в СУРБД (в данном случае используется Microsoft
SQL Server), и включает в себя пользовательскую и административную части.
Пользовательская часть представляет собой отображение пользовательских
данных, таких как статьи, графические ресурсы, и эта часть доступна
пользователю исключительно для просмотра данных, и ее пути начинаются с
корня приложения (/), причем пользователь дополнительно имеет доступ к
своей панели управления /user/dashboard.ftl для управления доступными ему
ресурсами. Административная часть служит для изменения и добавления
данных, и путь этой части начинается с /admin. Административный интерфейс
представляет собой страницу /admin/dashboard.ftl с ссылками на создание,
редактирование и удаление пользователей, статей и комментариев к ним.
Возможности изменять или добавлять данные регулируется ролями
пользователя (пользователи, имеющие роль ADMIN – просмотр и
редактирование, имеющие роль USER – только просмотр данных, а
неавторизованный пользователь имеет возможность видеть только главную
страницу с возможностью авторизации). Все параметры безопасности
64
приложения описаны в классе WebSecurityConfig который наследуется от
класса WebSecurityConfigurerAdapter (Приложение 4), который находится в
пакете com.platform.configuration.
В данном конфигурационном классе аннотация @Configuration
сообщает фреймворку Spring о том, что данный класс используется для
конфигурации приложения (данной аннотацией помечаются все
конфигурационные классы любого приложения, использующего фреймворк
Spring), аннотация @EnableGlobalMethodSecurity служит для защиты всех
методов приложения, а аннотация @Order отвечает за порядок прохождения
цепочек безопасности библиотеки Spring Security. В теле класса с аннотацией
@Autowired (для автоматического связывания компонентов Spring Framework),
создается приватный экземпляр интерфейса UserDetailsService. Затем в методе
configure описывается цепочка безопасности. В методе http.authorizeRequests
параметр antMatchers указывает на совпадения с путями системы, то есть в
данном проекте в самом начале создается часть цепочки безопасности, которая
разрешает указанные пути всем без исключения (это корень приложения,
доступ к таблицам стилей, шрифтам, изображениям, JavaScript скриптам и
каталогу webjars). За разрешение отвечает метод permitAll. Далее в цепочке
указываются пути, доступные по ролям пользователей, где метод принимает
путь, и проверяет его на наличие доступа по роли (ADMIN или USER), и в
зависимости от соответствия разрешает, или запрещает доступ к ресурсам, и
автоматически разрешает все запросы аутентифицированным пользователям в
пределах их ролей доступа. Далее всем пользователям разрешается доступ к
странице входа, задается параметр входа (email), и разрешаются пути для
функциональности запоминания пользователя и адрес страницы с
предполагаемыми ошибками подключения пользователей (/error).
В методе configure следует указать параметры авторизации с
использованием класса-сервиса userDetailsService, и шифрования паролей
пользователей методом BCrypt. Описание клиентской части безопасности