Рубрика:
Веб /
Веб-технологии
|
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
Алексей Моисеев
Совершенствуем технологию CMS
Уже не один месяц интернет-сообщество и бизнес ожидают новое поколение CMS. Наконец отдельные идеи, многие из которых революционные, были собраны воедино, в проекте Habitat 2.0.
CMS в их текущем виде существуют уже довольно-таки давно. Эксперты сходятся во мнении, что в ближайшее время должно появиться что-то кардинально новое – система, которая возведёт сайтостроение на качественно более высокий уровень. В различных изданиях, преимущественно электронных, не раз публиковались статьи, посвящённые несовершенству современных CMS. Там же высказывались предложения о том, каковы должны быть CMS нового поколения, однако большинство таких предложений уже давно реализовано (например, модульная структура, редактор HTML-кода в администраторской части).
Подавляющее большинство разработчиков CMS основной акцент делают на пользовательскую (клиентскую) часть, а администраторская панель является дополнением, позволяющим более комфортно управлять функциями системы. Одно из главных отличий предлагаемой вам сегодня системы состоит в том, что ее основной частью является администраторская панель, а клиентская часть состоит из визуализатора, отображающего скомпилированные страницы пользователю.
Размышляем о новых возможностях CMS
Как правило, наиболее качественными CMS являются платные системы. При покупке такой CMS пользователь получает поддержку, а также в большинстве случаев своевременное решение появляющихся вопросов при работе с системой. Среди платных CMS следует особо выделить: S.Builder, Q-Publishing, UMI.CMS, ABO.CMS, Bitrix, CimWebCenter, CMS Master, CMS UlterSuite, Content Master, MSTL-content, помимо перечисленных, существует ещё очень много систем управления. Один из таких продуктов – Habitat – разрабатывался мной в течение длительного времени. После двух с половиной лет исследования CMS мною были сделаны выводы относительно конструктивных особенностей, не позволяющих развиваться существующим системам в сторону usability. Неоднократно проводились консультации с владельцами сайтов на основе Habitat, по теме сервисных возможностей, однако далеко не всё можно реализовать на базе существующих CMS.
Иное представление CMS
Результатом вышеописанных исследований стал проект Habitat 2.0. Он является развитием большинства существующих CMS. Среди основных нововведений, которые вы не увидите в других системах, имеет смысл особо выделить объектно-ориентированный метод построения шаблонов страниц.
Для администратора системы HTML-страница представляется в виде дерева компонентов, каждый из которых имеет свойства, позволяющие изменить вид графического представления компонента. Система не оперирует понятиями HTML, CSS, JavaScript. То есть уровень абстрагирования на порядок выше, чем у ближайших аналогов. Компонент есть инициализированный класс, который закачивается в систему в формате XML-компонента.
- В систему изначально заложены способы упорядочивания компонентов, благодаря чему вы можете организовывать объекты представления (страницы, товары и т.д.) в любом порядке (линейный, иерархический).
- Для наполнения шаблонов страниц динамической информацией используются инфоисточники (Data-Aware). К инфоисточникам относятся константы (строки, определённые для всех компонентов), переменные (строки, определённые по месту, то есть для конкретных компонентов) и сами Data-Aware, которые представляют собой участок PHP-кода в комбинации с PIN. Последние необходимы для связи данных, возвращаемых скриптом Data-Aware, с переменными внутри шаблонов.
- Среди неотъемлемых частей Habitat 2.0 можно выделить магазин. Его необходимость объясняется тем фактом, что в результате роста числа российских пользователей Интернет с каждым днём увеличивается число Интернет-представительств организаций, которые считают необходимым обеспечить возможность комфортного для пользователей заказа услуг компании.
Разработка сайта отныне осуществляется в новом ключе – веб-программист разрабатывает компоненты, отвечает за то, что они реализуют свои функции, а затем собирает из этих компонентов шаблоны страниц (т.н. типовые страницы). Все это делается ради нескольких «священных коров» программирования:
- установление четкой и прозрачной взаимосвязи между содержанием (данные из БД) и формой (визуализация данных);
- перенос понятия «сопровождения сайта» из плоскости программирования в плоскость управления и соответственно удешевление сопровождения;
- повторное использование кода (компоненты – вещь четкая и отделимая от всего остального);
- повышение надежности серверной части ПО за счет структурной четкости реализации.
Шаблоны страниц могут состоять из компонентов (элементарные шаблоны) и других шаблонов (т.н. «типовые страницы»), собранные на основе компонентов. Под компонентом подразумевается логически выделенный дизайнером и обычно повторяющийся элемент дизайна, несущий определенную функциональность, например отображение списка новостей. Рубрикаторы, меню, содержательные части страниц и т. д. – все это компоненты, на основе которых путем комбинирования, взаимного их расположения можно построить шаблоны страниц. Это обеспечит нам легкость и гибкость изменения внешнего вида. Например, можно задавать, какие рубрикаторы используются в различных шаблонах, где используются колонтитулы, а где нет, и т. д.
Для реализации большей части нововведений потребовалось более активное использование БД, чем в обычных CMS, однако требования у системы не выходят за рамки возможностей дешёвых хостингов: PHP 5, MySQL 4, 20 Мб свободного места (обычно самое минимальное, что можно купить).
Ядро Habitat 2.0
Важнейшую часть ядра системы составляет компилятор-сборщик, который на входе получает ссылку в корень дерева шаблона (который надо собрать), а на выходе отдаёт готовый шаблон для страниц с расставленными «вкраплениями». Расстановка указанных «вкраплений» (шаблоновых переменных) является наиболее интеллектуальной частью компилятора. На место таких переменных вставляется информация, возвращаемая от источников данных (Data-Aware, Переменные, Константы). Эту операцию выполняет компилятор-сумматор, который является частью пользовательского визуализатора.
Для того чтобы полностью переложить всю работу, над внешним видом сайта, на плечи системы (а точнее, её разработчика) помимо свойств (в которых задаются параметры каждого компонента, такие, как обрамление, выравнивание, положение и т.п.), у компонента есть события. Определяя события для конкретных компонентов, можно добавить динамику для страницы сайта (например, подсветка рубрикаторов, элементов меню и т.п.). Для этого планируется:
- Написание Data-Aware модулей, решающих все возможные вопросы, которые только могут появиться у пользователей.
- JavaScript-описание всех определённых событий в HTML, для того чтобы дать администратору максимально возможную гибкость при редактировании внешнего вида страниц.
- Создание множества классов, для того чтобы полностью исключить необходимость редактирования исходного кода HTML или CSS.
При работе с константами, переменными и DataAware всегда есть возможность просмотреть названия компонентов, где используется текущий источник данных. Для перехода к редактированию компонента, использующего текущий источник, достаточно двойного клика мышкой.
Компоненты как строительный материал
Компонент «движка» представляет собой строительный материал для страниц сайта. Он обладает рядом особенностей, делающих компоненты более универсальным средством.
Во-первых, он визуальный, т.е. занимает определенную территорию на странице. Это накладывает ограничение на свободу создателя компонента, который должен гарантировать, что компонент не будет рисовать за пределами самого себя.
Во-вторых, компонент всегда получает данные извне, т.е. сам не умеет запрашивать данные из базы, – он суть одеяние, способ отображения неких других данных. На этапе компоновки страниц компоненту указывается источник данных, откуда он и узнает то, что ему необходимо отображать.
И в-третьих, будем отличать «класс компонента classMyComponent» и «компонент MyComponent класса classMyComponent». Первый никогда не исполняется сам по себе – это описание того, что должно быть передано движку и включено в цикл обработки движка. То есть, говоря простым языком, classMyComponent – это заготовка, ее можно экспортировать из одного проекта и импортировать в другой, пусть и для похожего, но уже другого применения. По аналогии с языками высокого уровня classMyComponent – это тип объекта или его класс, а сам объект этого типа нужно еще породить и запустить. Программист для нашего движка сначала создает компоненты, а потом уже пытается правильно их применить.
Работа с типами компонентов (классами), а также инициированными классами (будем их называть просто «компоненты») нужна для того, чтобы компоненты одного и того же класса можно было использовать множество раз для схожих и одновременно разных целей. Точно так же, как программисты Delphi/VC++ используют классы, описывающие в памяти некоторую структуру данных. В данном же случае достигается некоторая степень универсальности, позволяющая компоненты одного типа представлять в различном виде: форма, цвет, обрамление…
И как следствие этого приема компонент перестает быть привязанным к конкретной реализации, он работает как черный ящик для того, кто его использует. При создании шаблона страницы у разработчика есть свойства, события компонента, заявленная функциональность, всё остальное – дело самого компонента.
Интерфейс
Внешнее представление самой администраторской панели спроектировано таким образом, чтобы вы могли «добраться» до любого «уголка» панели за минимально возможное время. Это обеспечено за счёт иерархической структуры всей администраторской панели, то есть дерева в отдельном фрейме. Каждая ветка дерева догружается по мере необходимости, что позволяет более эффективно использовать канал связи. В отдельный верхний фрейм (так называемый Toolbar) вынесены сервисные кнопки, которые позволяют управлять структурой дерева, а также обезопасить себя от случайного удаления важного элемента.
Рассматриваемая CMS изначально создаётся для рядового пользователя Интернета, коим вполне может оказаться руководитель предприятия или работник отдела маркетинга, какой-либо организации. Этим объясняется возможность включения подсказок везде, где это может принести хоть какую-то пользу.
Среди стандартных возможностей системы можно упомянуть разделение доступа для суперадминистраторов, администраторов, модераторов, редакторов, аудиторов и т. п, эргономичность, usability, accessibility, управление рекламой, статистика (по рекламе, посетителям и т. д), создание резервной копии всей системы…
В истории немало фактов, когда создание простых инструментов и технологий приводило к появлению на рынке множества некачественных продуктов, изрядно портящих жизнь их пользователям, однако с появлением Habitat 2.0 строение сайтов будет на порядок проще, а безопасность в несколько раз выше, так как ей будут заниматься профессионалы, чья основная обязанность заключается в совершенствовании Security и Usability модулей системы.
Многоязыковая поддержка позволит системе распространиться за пределы СНГ. В планах на будущее реализовать подход к вёрстке AJAX (подход к созданию веб-страниц, позволяющий при каждом новом запросе загружать не полностью новую страницу, а лишь те её части, которыми она отличается от текущей. Этот принцип позволяет повысить скорость загрузки страниц во много раз по сравнению с традиционными методами вёрстки), что становится вполне реальным, если под рукой находится вышеописанная CMS платформа.
Этапы развития сайтостроения
В итоге мы можем выделить следующие ступени эволюции интернет-страниц:
- Начальные идеи отдельных разработчиков. Как правило, распространение за пределы одного рабочего коллектива отсутствовало.
- Gopher.
- Статические веб-страницы.
- Динамические веб-страницы, развитие CMS.
n Конкретное название класса для CMS подобных Habitat 2.0 придумывать пока рано, однако есть основания полагать, что это первый шаг к тем системам нового поколения, приход которых предсказывают эксперты.
Если проследить развитие языков разметки от HTML 3.2 до XHTML, XML, то можно заметить, что важнейшей целью разработчиков Интернет-консорциума, вероятно, является сделать труд веб-верстальщиков менее рутинным (в конференциях, таких, как fido7. RU.HTML.PROFY, высказывается мнение, что цель разработчиков заставить верстальщиков использовать программы класса XMLSpy, HomeSite, DreamWeaver, и не набирать код вручную), то есть вся рутинная вёрстка, как предполагается, должна выполняться специальными программами. Вполне возможно, что профессия «верстальщик» вообще перестанет существовать в её современном представлении.
В ряды продуктов, выполняющих всю рутинную вёрстку, можно отнести Habitat 2.0. Точно так же, как визуальное программирование позволяет ускорить и упростить труд дизайнера программного обеспечения (а главное, не требует от него особых навыков программиста), системы нового поколения приблизят возможности WWW к пользователям, не имеющим навыки веб-разработчиков.
С большой долей вероятности можно утверждать, что будущее именно за гибкими автоматизированными системами управления содержимым веб-ресурса.
Возможное развитие
Есть предположение, появившееся при анализе существующих систем управления сайтом, а также при проектировании Habitat и Habitat 2.0, что через некоторое время большинство хостинг-провайдеров в качестве дополнительной услуги или даже в качестве обязательной функции будут предлагать использование CMS. Разработка таких CMS скорее всего будет вестись сторонними фирмами либо самой организацией, предоставляющей услуги хостинга. Примером подобных программных продуктов может служить Control Panel и Direct Admin. Предполагается, что CMS будет состоять из центральной администраторской панели, в которой можно будет управлять абсолютно всеми функциями веб-сайта и одним для всех визуализатором. Это позволит постоянно повышать безопасность («единый фронт борьбы с хакерами»), а также оградит пользователей от таких ненужных в большинстве случаев определений, как «FTP», «закачать обновление». Всё это является задачами CMS и администраторов хостинга.
В России немало частных лиц и небольших организаций, занимающихся различными разработками, не имеют возможности рассказать о своих идеях в прессе. Системы автоматизированного построения веб-ресурсов, позволяющие полностью оградить своего владельца от необходимости веб-разработки и при этом не требующие услуг дизайнера, делают реальностью самостоятельную публикацию идей или разработок.
В настоящий момент такая услуга, как создание и сопровождение Интернет-ресурса компании, деятельность которой не связана с информационными технологиями, обходится в крупную сумму. Однако увеличение доступности Интернета в совокупности с появлением CMBS-систем позволит интернет-пользователям заказывать услуги не только относительно крупных компаний, но и более мелких организаций.
Наиболее вероятно внедрение подобных идей у хостинг-провайдеров, постоянно улучшающих качество своих услуг, понимающих, для чего необходимо «грамотное регулирование цен» на услуги. В России таких фирм почти нет… разве что уже упоминавшаяся RuWEB. Или, может, о новых технологиях предоставления хостинга задумаются те провайдеры, которые ещё только планируют появиться в ближайшем будущем? Возможно, бой только начинается…
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|