Презентация к докладу:
Мы редко представляем Битрикс как CMF в первую очередь потому, что эти термины понятны только разработчикам и непонятные покупателям.
Но, видимо, пришло время обращать на это больше внимания и подробнее рассказывать разработчикам о выбранных нами концепциях развития продукта.
[spoiler]
В своем докладе я в самом начале затронул тему двух концепций развития продуктов, условно назвал направления CMS системами и CMF системами (хотя каждый из терминов сегодня не совсем точный).
CMS создаются с целью решить конкретную относительно простую бизнес задачу, например управление контентом, лентой новостей, форумом, блогом, иногда совмещенными подобными функционалами. Для таких продуктов характерно накопление галочек и чекбоксов, каждый из которых выполняет некоторые конкретные функции. Например галочкой в админке можно показать дату при выводе, а можно убрать фотографию в просмотре… По своей идее подобные продукты зачастую содержат некоторые ограничения на адаптацию или внешнего вида или бизнес логики. Но что самое досадное, по мере развития продукта, административный интерфейс обрастает невероятным числом галочек, комбинации между которыми приводят в тупиковое состояние и пользователя и разработчика.
Примерно такими были наши первые продукты, Битрикс: Управление сайтом 1.0 и 2.0, Битрикс: Инфо-портал 2.0, Битрикс: Арендуемые магазины… И хоть все делалось из добрых побуждений, продукты становились сложными и невнятными, накладывали ограничения на разработчиков и внесение изменений приводило к потери совместимости измененной версии и ветки разработки.
По этой причине, в 2003 году мы приняли решение и полностью реконструировали Битрикс: Управление сайтом, потратили 9 месяцев и выпустили версию 3.0, которая была несовместима с предыдущими версиями. Но новая версия продукта представляла собой CMF систему, с четкой и понятной архитектурой, классами и методами, API разных уровней, технологией обновлений SiteUpdate…
И уже на базе созданной CMF мы выпустили законченные редакции продукта, с готовой бизнес-логикой, которые обладают всеми возможностями CMS, но при этом получают гибкость CMF систем. И на базе CMF наши партнеры и мы будем дальше выпускать новые законченные решения, не теряя связь с продуктом.
Подробнее тема раскрыта в презентации, смотрите, пожалуйста, там.
Что хотелось бы еще отметить. На РИТ в рамках докладов высказывалась мысль, что CMF не должна как система думать о конечных пользователях. В лучшем случае CMF должна поставлять административный интерфейс управления сущностями.
Но я совершенно уверен, что современные концепции развития CMF привели разработчиков к необходимости поставлять в CMF готовую бизнес-логик и инструменты для клиентов и разработчиков. Мы выпускаем 21 модуль, каждый из которых с одной стороны готов к использованию и уже решает четкий спектр задач, а с другой стороны может быть очень гибко настроен как внутри, так и снаружи, с точки зрения представления.
А представление информации, мы реализуем на базе компонент, которые созданы по MVC модели, легко настраиваются под свои нужды шаблонизаторами, и в тоже время, удобны конечным пользователям для размещения, т.е. организации вывода функциональности CMF, и содержат тот самый пресловутый набор галочек и чекбоксов для настройки представления и логики работы компонента под нужны конкретного сайта.
Я уверен, что компоненты – это наш ключ к успеху, возможность быть архитектурно CMF и удобными как CMS.
В общем, детальнее смотрите презентацию, и приходите на наши семинары
будет что обсудить. Ближайший семинар 27 числа:
