Обзор систем управления Web-контентом
Обзор систем управления Web-контентом |
|---|
|
По мере развития Интернета и включения его в структуры реального бизнеса растет количество людей, в прямые служебные обязанности которых входит публикация информации в Сети.
Вначале это были отдельные энтузиасты, в основном программисты, которым не составляло труда использовать язык разметки (HTML) для форматирования документов и файловую структуру — для их размещения.
Затем, с расширением аудитории появились системы для визуального редактирования документов и поддержки структуры статических (представляющих собой набор HTML-страниц) Web-сайтов: FrontPage, DreamViewer, PageMill, HomeSite и др. С помощью этих систем можно легко создавать и модифицировать такие сайты, не обладая специальной квалификацией и не вдаваясь в тонкости HTML.
Но сейчас подобные системы по целому ряду причин перестают удовлетворять растущие потребности бизнеса, и на сцену выходит новое поколение систем — так называемые системы Web-паблишинга, или управления Web-контентом. Зачем они нужны и на что способны? Ниже мы попробуем ответить на эти вопросы и описать несколько систем, уже появившихся на российском рынке.
Чем же не устраивают нас статические сайты? В основном тем, что, как уже отмечалось, они в принципе не могут удовлетворить все потребности пользователей, да и стоимость владения ими слишком высока.
Это обусловлено несколькими факторами, которые имеет смысл рассмотреть подробнее.
Дело в том, что язык HTML, являющийся сегодня общепринятым стандартом и технологическим базисом сети, приспособлен для описания внешнего вида документов. А страницы статических сайтов «живут» именно в виде HTML-документов. И как правило, каждая страница кроме содержательной информации включает некоторое обрамление — шапку данного сайта, меню, служебные ссылки для удобной навигации и др.
Поэтому на страницах, отображающих конкретные документы, вперемешку идут контент (смысловое наполнение) и дизайн, причем как дизайн самого документа, так и сайта в целом.
Негативных следствий из этого факта масса. И в первую очередь можно назвать трудоемкость публикации новых и редактирования существующих документов — они должны оформляться надлежащим образом с учетом стилевых особенностей и включением стандартного обрамления.
Обычно на современных сайтах на каждый содержательный документ имеется более чем одна ссылка: в тематическом разделе, в общем хронологическом индексе и, наконец, пока документ свежий, на первой странице (новость). Поэтому публикация документа — это не только добавление страницы, но и изменение трех-четырех других страниц, что в несколько раз увеличивает трудоемкость и риск испортить дизайн.
Ну а изменение структуры или дизайна сайта становится серьезной проблемой, требующей переработки всех опубликованных страниц.
Создание и поддержка сообществ (on-line community) признаны сейчас магистральным направлением развития электронного бизнеса, так как именно сообщества пользователей представляют собой основной капитал любого Web-проекта. Необходимо принимать все меры к тому, чтобы привлекать посетителей и помогать такому сообществу самоидентифицироваться.
Все эти вещи в принципе неосуществимы в технологии статических сайтов, и здесь не обойтись без программирования. Паллиатив в виде включения отдельных скриптов, «оживляющих» статический в своей основе сайт, решает далеко не все проблемы и резко повышает квалификационные и реализационные требования к нему.
Развитие инфраструктуры Сети приводит к тому, что Web-ориентированные решения все чаще используются как для внутрикорпоративной автоматизации (Intranet), так и для взаимодействия с клиентами (Extranet).
А те бизнес-процессы, которые при этом возникают, по своей природе существенно сложнее, чем цепочка «подготовка в офлайновом режиме — публикация», характерная для статических сайтов. В процессе подготовки документ должен проходить несколько стадий обработки, выполняемой разными людьми, прежде чем достичь своего окончательного состояния.
Рассмотрим, например, работу редакции онлайнового издания. Как правило, автор работает не в офисе, а дома — готовит материал и выкладывает его на сайт. Там он становится доступен только редактору, который вступает с автором в переписку, причем в идеале эта переписка должна происходить тут же, на сайте. Далее, после доработки автором и одобрения редактором материал попадает к корректору, а затем, возможно, к выпускающему редактору, который, собственно, и дает «добро» на публикацию.
Другой пример – электронный магазин, в котором посетитель размещает заказ.
Менеджер по работе с клиентами проверяет этот заказ и либо отклоняет его, либо передает на исполнение.
Заказчик может снять свой заказ, пока он еще не отправлен. Когда заказ отправляется покупателю, информация об этом соответствующим образом фиксируется. После доставки и оплаты заказ снимается с контроля и попадает в архив. Причем как менеджер, так и покупатель должны иметь возможность в любой момент проконтролировать состояние заказа.
Поддержку бизнес-процессов крайне трудно реализовать на базе статических сайтов.
Все это привело к пониманию того, что современные профессиональные сайты должны быть динамическими.
Контент динамических сайтов хранится обычно в базе данных, а на некоторых языках программирования пишутся программы, «на лету» генерирующие из содержимого таких баз HTML-странички, которые, собственно, и показываются пользователю. Существует несколько общепризнанных языков и систем программирования для разработки этих сайтов — ASP, PHP, разные варианты Perl и др..
Таким путем может быть, естественно, создан сколь угодно сложный, гибкий и «разумно» ведущий себя сайт (запрограммировать можно все), но как только начинается программирование, порог сложности задачи сразу возрастает.
В технологической цепочке разработки сайта появляется новый персонаж — программист, резко усложняется процесс постановки задачи и увеличивается цена ошибок постановки. В общем, открываются все прелести заказного программного проекта (несогласованность требований, затяжка сроков и др.), с которыми сталкивался любой, имевший несчастье выступать в роли заказчика программного обеспечения.
Кроме того, при подобном подходе практически не разделяются дизайн и функциональные возможности, поэтому изменение дизайна является проблемой, требующей совместной работы дизайнера и программиста, а изменение структуры или навигации может привести к необходимости изменения структуры данных и почти полного перепрограммирования самого сайта.
Создание сайта, честно реализующего поддержку сообщества и бизнес-процессы, — довольно сложная программистская задача, решение которой связано с затратами значительного времени и средств. И позволить это себе могут только большие проекты или крупные Web-студии, имеющие обширный набор повторно используемых заготовок.
Итак, где же выход? Статические сайты создаются относительно просто и дешево, но трудоемки и дороги в сопровождении, а кроме того, у них отсутствует целый ряд необходимых функций. Заказные динамические сайты сложны и дороги в разработке, но при удачной постановке задачи могут быть сделаны достаточно дешевыми в сопровождении.
Системы управления Web-контентом, или системы Web-паблишинга, как раз и предлагают компромисс между этими двумя крайностями. За счет ограничений, накладываемых на логическую структуру контента, внешний вид (дизайн) и функциональные возможности создаваемых динамических сайтов, такие системы позволяют радикально снизить трудоемкость разработки и поддержки.
Все системы управления контентом представляют собой некоторое программное обеспечение, устанавливаемое на Web-сервере и предназначаемое для создания и обслуживания динамических Web-сайтов. Все они в том или ином объеме предполагают отделение контента от дизайна, работу с сообществами, поддержку бизнес-процессов и минимизацию программистских усилий при разработке сайтов. Все хранят контент в базах данных и управляют как контентом, так и дизайном через Web-интерфейс.
Большинство подобных систем способны функционировать в режиме хостинга, т.е. сервис-провайдер может размещать систему управления контентом на своем сервере, предоставляя клиентам возможность создавать там свои персональные сайты за сравнительно (со стоимостью приобретения программного обеспечения) небольшие деньги.
И в то же время между рассматриваемыми системами имеются существенные различия — как по используемым технологиям и подходам, так и по областям применения и квалификационным требованиям к пользователям. Мы будем рассматривать здесь те аспекты, которые кажутся нам наиболее существенными, а именно:
Попытаемся оценить и области применения – кто, в какой ситуации и каким образом может воспользоваться предлагаемой системой.
Эта коммерческая система является надстройкой над известными продуктами Lotus Notes & Domino и предназначена, как анонсировано на сайте, «для создания небольших виртуальных офисов». Посвященный ей сайт доступен по адресу www. quickplace.com. В настоящее время в России по адресу www.webspace.ru предлагаются услуги хостинга. Там же имеется русскоязычное описание системы.
Контент представлен совокупностью документов, каждый из которых включает имя автора, заголовок и дату публикации. Документ может быть ответом на другой документ, что позволяет поддерживать простые формы обсуждений.
Документы разложены по папкам с иерархической структурой. Есть папки предопределенные, но пользователи могут создавать новые. Предусмотрен также индекс, в котором документы представлены полным списком — без разделения на папки.
Папки сгруппированы по комнатам. Для каждой комнаты определены свой список пользователей и управление правами.
Можно подготовить собственные типы документов (формы) и специфицировать для них технологический цикл (workflow) обработки.
Пользователи в каждой комнате делятся на три категории — имеющие право читать, обладающие правом публиковать (и редактировать) свои документы и владеющие всеми правами (администраторы). Доступ можно разрешить и анонимным, неавторизованным, пользователям, но публиковать документы могут только авторизованные. Авторизовать (зарегистрировать) нового пользователя может только администратор.
QuickPlace предоставляет очень богатые возможности публикации. Система содержит мощный и удобный редактор текстов с поддержкой шрифтов, цветов и картинок и умеет качественно импортировать уже подготовленные HTML- и Word-документы. Правда, обеспечивается это загружаемой на компьютер пользователя ActiveX – компонентом, совместимым не со всеми типами браузеров.
При публикации документа можно разослать его по списку пользователям сайта. Подписки на новости продукт, по-видимому, не поддерживает.
Функции и структура (навигация) сайта в QuickPlace заданы довольно жестко, хотя управление ими в какой-то степени допускается. Управляется набор пунктов левого меню (вынесенный туда набор папок и документов), набор колонок в списках документов и др.
Дизайн — фреймовый, включает четыре предопределенных фрейма. Оформление выбирается из набора предопределенных шаблонов (стилей). Можно ли создавать свои стили и управлять дизайном на уровне HTML, понять мне не удалось.
Все управление как дизайном, так и контентом производится путем wizard-style диалогов — пользователя проводят через последовательность этапов, на каждом из которых заполняются интуитивно ясные формы.
Надо отметить уникальную для рассматриваемых систем, но естественную для продукта, базирующегося на Lotus Notes, возможность работы в офлайновом режиме. Стоит вам списать и установить на свой компьютер 15-Мбайт архив, и вы сможете пользоваться собственным QuickPlace-приложением, не имея подключения к Сети, а потом синхронизировать внесенные изменения с изменениями на сайте, сделанными в ваше отсутствие.
К сожалению, есть проблемы с русификацией системы, в частности, не работают поиски и возникли некоторые сложности с публикацией материалов.
Имеется также значительное неудобство, обусловленное то ли фреймовым дизайном, то ли чем-то еще, а именно нажатие кнопки Refresh где-нибудь посредине диалога выбрасывает часть его контекста на заглавную страницу сайта. То есть применять этот продукт можно только при хорошей, устойчивой связи.
Серьезным ограничением является здесь и отсутствие возможности самостоятельной регистрации. Из-за этого изготовленный на базе QuickPlace магазин DrBacker, который упоминается на WebSpace в качестве удачного примера, был сломан в течение недели после появления в Сети. Поскольку публиковать материалы, в том числе и размещать заказы, могли только зарегистрированные пользователи, авторы магазина завели пользователя «Клиент» с некоторым паролем и предложили всем желающим сделать заказ авторизоваться как «Клиент». Но однажды некий клиент зашел и поменял «свой» пароль! Правда, он оказался достаточно благороден, чтобы оставить об этом запись с рекомендацией владельцам магазина заменить платформу.
В целом же это, пожалуй, наиболее удобная, хотя и наименее гибкая система. Она предъявляет минимальные квалификационные требования к пользователям и позволяет действительно просто создавать полезные мини-приложения, но, видимо, малопригодна для подготовки приложений промышленных. В частности, сам сайт www.webspace. ru (да и www.quickplace.com ) сделан не на QuickPlace, а как традиционные статические сайты...
Система Zope (читается «Зопи») представляет собой свободно распространяемое программное обеспечение, разрабатываемое группой энтузиастов в рамках проекта Open Source Software. Компания, осуществляющая поддержку и разработку на Zope, называется Digital Creations, Inc, Web-сайт проекта расположен по адресу www.zope.org.
О локализации Zope и связанных с ней в России систем мне ничего не известно, хотя на западе Zope-провайдеры имеются — на сайте проекта есть довольно обширный список оказывающих услуги по хостингу Zope-сайтов.
Речь об этой системе может идти в двух аспектах — как о системе программирования, позволяющей квалифицированным разработчикам на языке Python создавать мощные и сложные Web-сайты, и как о системе управления контентом, с помощью которой можно без программирования реализовать и наполнить информацией простые сайты. Здесь мы будем говорить, разумеется, о последнем варианте.
Информация (контент) в Zope хранится в собственной объектной базе данных. Принятая метафора организации контента естественна для программистов, пишущих на объектно-ориентированных языках, но может быть довольно сложна в освоении для простого пользователя.
Контент представлен в системе как набор объектов, имеющих свои свойства и методы, которые также являются объектами и образуют, таким образом, произвольную иерархическую структуру. Примерами объектов могут служить документы, картинки, папки и учетные записи пользователей.
Дизайн в Zope описывается с помощью методов. Так, у каждой папки есть метод index_html, который, по существу, и показывает страницу, соответствующую данной папке. Имеется некоторый стандартный вариант, но если он нас не устраивает, мы можем переписать этот метод.
Методы описываются на языковом расширении HTML, называемом DTML (Dynamic Tag Markup language). Zope-сервер в принципе занимается тем, что интерпретирует документы на DTML, выполняя предписанные действия и формируя на выходе HTML-страницы.
На DTML можно программировать и расширять его возможности путем программирования на Python, но достаточно много вещей делаются столь тривиально, что могут считаться разработкой шаблонов, а не программированием. Кстати, именно на DTML должны быть написаны тексты, которые будут публиковаться. В этом смысле особой разницы между шаблонами и собственно документами нет.
Управление сайтом происходит через стандартный для Zope административный интерфейс, структура которого отражает объектную модель. Этим способом публикуются, редактируются и удаляются объекты, причем относящиеся как к контенту (документы, папки, картинки), так и к управлению функциональными возможностями и дизайном сайта (методы).
Для администратора сайта такой интерфейс вполне удобен, а вот для простого пользователя он тяжеловат, в связи с чем при организации дискуссий, например, на Zope-сайтах используются дополнительные компоненты, хотя, скажем, реплика — это по сути не что иное, как предельно упрощенный документ.
То же самое в значительной мере относится и к публикации документов силами неквалифицированных конечных пользователей.
Поскольку управление дизайном и функциями ведется «штучно», т.е. для каждого объекта (документа, папки и др.) в отдельности, предусмотрен целый ряд приемов, позволяющих перенести принятые для одних объектов и папок решения на другие.
Модель авторизации и разграничения прав доступа в Zope является, по-видимому, самой гибкой по сравнению с прочими рассматриваемыми системами. Она честно построена по принятой во всех операционных системах схеме «пользователи–роли–права». Это означает, что пользователь имеет одну или несколько ролей, а роли определяют, что можно делать с теми или иными объектами (права). Набор прав различается для разных типов объектов. Существуют механизмы, помогающие автоматически распространять права вниз по дереву папок.
Поддержку бизнес-процессов базовые функции Zope не обеспечивают, но имеется такая замечательная возможность, как поддержка версий сайта. Я, впрочем, считаю, что речь идет не столько о версиях, сколько о трансакциях. К примеру, некто может «создать версию», затем долго работать над модификацией содержимого сайта, и все это время вносимые изменения будут видны только ему одному. А далее он говорит: «Слить версию», и изменения проявляются для окружающих.
Для Zope имеется масса библиотек, предоставляющих объекты, которые реализуют разные варианты организации форумов, опросов, подписок и т. п., но, к сожалению, отсутствуют внятные описания этих библиотек.
Таким образом, Zope может рассматриваться как система управления контентом, хотя сейчас в полной мере она может использоваться только при участии программиста-разработчика, который, правда, будет скорее не программировать, а изыскивать и тестировать готовые решения. Но при наличии такого специалиста, умеющего программировать на языке Python, Zope становится мощнейшим инструментом разработки Web-решений.
Система DynaSite — разработка питерской фирмы RekSoft. Проекту уже более двух лет. Наиболее известен сделанный по этой технологии книжный магазин «Озон» (www.o3.ru).
Технологически DynaSite реализован на основе СУБД Sybase и Web-сервера приложений ColdFusion компании Allaire Corp. и работает на платформе Windows NT. Продукт является коммерческим — желающие воспользоваться им должны приобрести лицензию. Услуга хостинга анонсирована, но пока недоступна.
Контент в DynaSite представляется как набор папок, в которых хранятся собственно документы. При этом любой из них может быть помещен в несколько папок одновременно. Есть несколько типов документов, в том числе просто документ, новость, шаблон и др.
Документ имеет заголовок и дату публикации и состоит из последовательности блоков.
Существует довольно обширный набор типов блоков. Каждый блок генерирует некоторый HTML-код, определяемый его типом и параметрами. Причем одни блоки являются константными (текст, HTML-текст, картинка), а другие – динамическими, генерирующими переменное содержимое. К этим последним относятся, например, блок «список», позволяющий показать, скажем, последние номера новостей по HTML-шаблону, который также входит в число его параметров, и блок, порождающий форму авторизации или идентификации зарегистрированного пользователя.
Так что шаблоны — это тоже документы, в которых задействованы блоки, порождающие динамическое содержимое. В каждой папке имеются шаблоны, определяющие, как следует показывать саму папку и документы, лежащие в этой папке.
Управление содержимым сайта осуществляется через административный интерфейс, который предоставляет возможность публиковать и редактировать документы. Редактирование производится в терминах блоков: их можно создавать, редактировать, удалять и менять местами. Внешне все это похоже на работу в стандартных для Windows графических оболочках в метафоре Cut&Paste. Настройка параметров блоков происходит в визуальном режиме путем заполнения полей форм и выбора вариантов в чек-боксах.
Предусмотрена поддержка достаточно мощной и гибкой системы управления правами пользователей. По-видимому, управление правами на просмотр/публикацию документов идет на уровне папок. Допускается как свободная регистрация, так и административный способ управления. Поддерживаются и некоторые варианты редакционных процессов с разделением ролей авторов и редакторов.
DynaSite — система «крупноблочная», много существенных для ее практического использования возможностей реализовано здесь не на базе контент-модели, а в виде дополнительных модулей (расширений). Существуют модули, обеспечивающие реализацию функций электронного магазина, управления рассылками и др. Форумы и опросы также выполняются с помощью отдельных модулей.
Несмотря на привлекательность концепции, система имеет некоторые подводные камни. В частности, шаблон, представленный в виде последовательности блоков, выглядит совсем неочевидно, и понять, что он, собственно, породит, весьма сложно. Соответственно затруднен и процесс их подготовки. То же самое относится к публикации документа. Если в нем где-то в середине встретится картинка, мы будем вынуждены разрезать его на два текстовых блока и блок типа «Картинка».
Еще один минус заключается в том, что работа по управлению контентом сводится к длинной серии мелких шагов, каждый из которых сопровождается установлением контакта с сервером и загрузкой довольно объемной страницы. Естественно, при не очень хорошей связи все процессы занимают слишком много времени.
Сильно ограничивает возможности системы бедный и нерасширяемый набор атрибутов и типов документов — все существенные расширения базовых функций требуют реализации дополнительных модулей и блоков, что выходит за рамки компетенции рядового пользователя. Кроме того, нужно отметить трудоемкость установки и эксплуатации (база данных содержит более 100 таблиц). Недоступна на сегодня также детальная документация по системе. Для того чтобы подготовить настоящий обзор, ее архитектуру пришлось «вычислять» в беседах с разработчиками.
Тем не менее DynaSite можно рекомендовать для больших корпоративных решений в тех случаях, когда все потребности пользователя с запасом перекрываются возможностями имеющихся здесь блоков и модулей. Думаю, что после появления услуг хостинга и выхода второй ее версии ситуация изменится.
Проект разработан московской компанией Communiware project group. Сервер проекта доступен по адресу www.communiware.ru. Наиболее известный Web-сайт, выполненный по этой технологии, – Московский либертариум (www.libertarium.ru). Организовано также несколько Интранет-серверов.
Технологически Communiware реализован на основе СУБД Oracle и свободно распространяемого Web-сервера Apache, использует Perl и работает на любых Unix-платформах. Анонсирована также версия со свободно распространяемой СУБД Postgress. Продукт является коммерческим — для работы с ним требуется приобретение лицензии. Хостинг заявлен, и ряд проектов разработчики размещают на своем собственном сервере, но как полномасштабная коммерческая услуга Communiware-хостинг пока недоступен.
Модель представления контента, принятая в Communiware, является наиболее гибкой по сравнению с другими описанными в настоящем обзоре системами. Контент представим в виде графа. Имеются информационные объекты (в оригинальной документации называемые item), соединяемые между собой с помощью различных видов связей. Каждый объект обладает уникальным идентификатором, который либо задается его автором, либо генерируется автоматически. Основные типы объектов — тематическая рубрика, документ, реплика, персона и пр.
Любой объект располагает достаточно богатым набором атрибутов, к которым относятся название, аннотация, даты написания и публикации и др. Некоторые типы объектов могут включать дополнительные атрибуты.
Но автор и тематическая рубрика, к примеру, не считаются атрибутами документа, а оформлены связями, за счет чего документ может иметь несколько авторов и входить в несколько тематических рубрик.
Связи бывают одноуровневыми и иерархическими (если A связано с B, а B с C, то A в некотором смысле связано с C). Скажем, «Автор» – связь одноуровневая, а «относится к теме» — иерархическая. Существует предопределенный набор типов объектов и связей, достаточный для большинства задач Web-паблишинга, и предусмотрена возможность создания своих типов.
Визуализация контента производится с помощью шаблонов, которые являются специальным типом объектов. Текст шаблона описывается на HTML, синтаксически расширенном так называемыми динамическими элементами. Эти элементы указывают, что именно должно быть динамически порождено и вставлено в результирующую HTML-страницу. Внутри шаблонов могут быть использованы обращения к другим шаблонам. Например, оформив шаблон, описывающий стандартную шапку и левое меню, его можно задействовать в шаблонах для всех конкретных типов страниц.
При разработке шаблонов небходимо указать, какая именно совокупность объектов должна быть показана в том или ином контексте. Для этого служат фильтры, скрывающие от разработчика базу данных и позволяющие ему работать в содержательных терминах. Благодаря регулярной структуре базы почти всегда можно обойтись примерно десятком стандартных фильтров типа «Все потомки данного объекта по связи (Параметр)». Но существует интерфейс для создания и отладки новых фильтров, представляющих собой фактически произвольные SQL-запросы. В частности, через фильтры легко обеспечить визуализацию информации из внешних по отношению к Communiware подсистем.
Здесь также реализована поддержка как свободной (пользователи регистрируются сами), так и административной регистрации. Имеются несколько системных статусов пользователей. Управление правами всех остальных производится путем отнесения их (с помощью связей) к некоторым группам с дальнейшим определением на уровне шаблонов пределов «видимости» для каждой группы или даже для конкретного пользователя. Опять же на уровне разработки шаблонов можно учитывать индивидуальные предпочтения, например, применение графики, порядок сортировки реплик в дискуссиях и др.
Система довольно хорошо интегрирована с электронной почтой — поддерживается возможность принудительной рассылки опубликованного материала отдельным персонам или по спискам и, кроме того, используется мощный механизм подписки на изменения, который позволяет управлять не только тем, на что, собственно, подписывается пользователь, но и тем, в каком виде и с какой периодичностью ему будет высылаться информация.
Управление как контентом, так и дизайном ведется через административный интерфейс модератора, с помощью которого можно создавать, удалять и редактировать объекты и их связи, управлять типами объектов и связей, фильтрами и другими служебными объектами. В соответствии с логикой организации контента базовой операцией управления является добавление/редактирование единичного объекта и его связей.
Но обычных пользователей, занятых публикацией материалов, необязательно заставлять работать с этим интерфейсом. Разработчику шаблонов доступны средства создания простых интерфейсов — форм для посылки реплик, публикации новостей и статей и др.
Набор форматов и средства импорта файлов в Communiware слабее, чем в QuickPlace, но тоже достаточно обширны — возможна публикация как HTML-, так и RTF-текстов и даже plain-текстов, в которых, впрочем, допускается использовать некоторые простейшие виды разметки.
Бизнес-процессы реализуются путем разработки соответствующих типов объектов, связей и шаблонов, фильтрующих информацию в зависимости от статуса пользователя и дающих ему нужные технологические операции. Так, в одном из Интранет-проектов на базе Communiware была реализована система управления проектом, поддерживающая такие понятия, как задача/подзадача, ответственный исполнитель и др.
Communiware — единственная система, в которой дискуссии всех стандартных (гест-буки, Web-форумы) и целого ряда нестандартных видов удается полностью осуществить в рамках ее базовых функций. К тому же это довольно «легкий» продукт: количество таблиц в базе данных не превосходит двух десятков, а объем скриптов — десяти тысяч строк на Perl и PL/SQL .
Платой за гибкость являются довольно высокие квалификационные требования к разработчику сайта. От него требуется знание HTML и изучение примерно четырех десятков Communiware-объектов — стандартных типов объектов и связей, атрибутов, динамических элементов и стандартных фильтров.
Ощущается также некоторая «молодость» проекта — не предусмотрено много очевидных возможностей, административные интерфейсы ориентированы скорее на программиста, чем на неквалифицированного пользователя, отсутствует связная документация. Хотя на сайте проекта www.commuiware.ru в разрозненном виде имеется почти полный комплект справочной информации, но воспользоваться ею не очень просто.
Однако среди рассматриваемых систем Communiware можно признать наиболее приемлемым решением для тех пользователей, которые хотят иметь максимальную степень свободы в управлении дизайном и функциями организуемых ими Web-сайтов, а также возможность реализации произвольных по своей сложности бизнес-процессов. Таковыми в первую очередь являются корпоративные пользователи, создающие свои Интранет-решения, и небольшие Web-студии, не имеющие собственной сильной команды программистов.