Февраль 11, 2006
CMS с desktop-клиентом - за и против (Часть 1)
Аббревиатура "CMS" обычно ассоциируется с набором web-сервисов, скрытых от посторонних глаз в специальном "админском" разделе и позволяющих, в той или иной степени, управлять сайтом. Создавать новые документы, редактировать формы, загружать изображения и многое другое - в зависимости от того, насколько та или иная CMS "продвинута". И все это с помощью одного лишь web-браузера.
Однако такой подход, хоть и является самым привычным и распространенным - отнюдь не единственный. Наиболее заметной альтернативой ему служат системы управления сайтом, выведенные в отдельные программы, устанавливаемые на компьютере администратора или контент-менеджера. Обычно это специально написанные для работы с web-проектами desktop-приложения, работающие с локальным "зеркалом" базы данных или напрямую с базой данных сервера и предоставляющие пользователю богатый набор возможностей, как правило недоступных в обычных web-интерфейсах.
Почему же такие системы не получили широкого распространения?
Прежде всего, из-за сложности в разработке. Действительно, в случае с web-интерфейсом за разработчика почти все делает сам браузер: визуализирует HTML-код страниц, предоставляет готовые поля ввода и элементы выбора, осуществляет соединения с сервером и т.д. - берет на себя всю "рутину". Тогда как в случае написания самостоятельных приложений приходится обращать внимание на многочисленные тонкости реализации, в том числе и самые низкоуровневые.
Другая причина заключается в доступности web-браузера практически на любом компьютере "по умолчанию". Контент-менеджеру, особенно если он работает с сайтом и с работы, и из дома, а то и с помощью мобильных устройств, не нужно устанавливать никакого дополнительного программного обеспечения. Открыл браузер - и работай. Особенно это преимущество становится очевидным, когда над сайтом работает сразу несколько человек - например, распределенный штат журналистов.
Поэтому большинство разработчиков CMS предпочитают сконцентрировать усилия именно на web-интерфейсах и логике их взаимодействия с базами данных. Этот путь быстрее ведет к цели - созданию работающей системы управления контентом и быстрее окупается.
Что же тогда заставляет некоторых разработчиков идти по более сложному пути, создавая специальные приложения?
Браузеры, конечно, берут на себя "рутину", однако, платой за это служат многочисленные ограничения. Браузер, прежде всего - средство просмотра готовых страниц в формате HTML. А HTML - это язык разметки текстов. Так уж сложилось исторически. И хотя с момента возникновения этой парадигмы появилось множество ее "расширений", таких как, например, JavaScript, CSS, DOM - ситуация принципиально не изменилась. Возможности браузеров для построения сложной функциональности сильно проигрывают возможностям, которые открываются для самостоятельных desktop-приложений.
Разработчики web-ориентированных CMS сталкиваются с проблемами визуального редактирования иерархий разделов и каталогов, для которых было бы удобно простое перетаскивание ветвей мышью. Или управления большими объемами данных, для которых было бы удобным представление, принятое в программах работы с электронными таблицами типа MS Excel. До недавнего времени остро стоял вопрос даже о простом визуальном форматировании текстов.
Закономерное желание сделать свою CMS достаточно гибкой и универсальной приводит к неизбежному усложнению систем: в скрипты вводится множество абстракций, деклараций потенциально необходимых "объектов", появляются избыточные запросы к базам данных и разнообразные служебные таблицы. Код "распухает", обрастает большим количеством модулей, часто ненужных для решения конкретных практических задач. Все это, в конечном счете, негативно сказывается и на производительности, и на простоте внесения изменений в сайты.
продолжение следует...
Часть 2 |
Разместил:
Источник: Микаэлла Клюева