Новые требования клиентов. Кастомизация в интернет-маркетинге и IT
Ещё пару десятилетий назад мы радовались любым нововведениям в компьютерной сфере и могли свыкнуться с любыми неудобствами программ. Сейчас каждый пользователь может высказать своё недовольство по поводу работы с сервисом. Одному будет не нравиться одно, второму ― другое. Вместо того чтобы угодить всем, разработчики стараются сделать интерфейс и наполнение программ изменяемыми. И для такого подхода есть свой термин ― кастомизация. Итак, что такое кастомизация?
Что значит кастомизация
Кастомизация ― это внесение конструктивных или дизайнерских изменений в продукт под заказ конкретных потребителей. Это самое общее понятие, которое можно дать. Проще говоря, кастомизированный ― это продукт, созданный по индивидуальным потребностям покупателя. Пользователь сам решает, что ему не хватает в базовом продукте, и дорабатывает его сам или обращается за помощью к специалистам.
Яркий пример кастомизации ― изменение кроссовок. Очень популярно покупать какую-либо модель кроссовок и модернизировать её на своё усмотрение (менять цвет, наносить рисунки).
Создание штучного товара для производства – очень невыгодное дело. Конечно, можно ориентироваться на богачей, но они и так чаще всего заказывают себе эксклюзивные вещи. Куда интереснее использовать технику кастомизации в товарах для среднего сегмента рынка. Для решения такого кейса была придумана массовая кастомизация (mass customization). Это модульный подход к производству товаров и услуг. Чаще всего вы сталкивались с подобным при подборе мебели. Вот вы заходите на сайт мебельного магазина, выбираете понравившуюся вам модель кресла. И тут вам предлагают выбрать цвет и материал обивки, размер и форму ножек, цвет декора. По итогу созданное вами кресло может в корне отличаться от того, что вы увидели на сайте. Разве что форма останется неизменной. Что для клиента, что для производителя ― это конструктор, из которого собирается продукт. Массовая кастомизация лежит между обычной массовой продукцией и эксклюзивом. Далее в наших примерах мы чаще всего будем иметь в виду именно массовую кастомизацию, так как о полном эксклюзиве в товарах средней ценовой категории говорить не приходится.
Появление интернет-магазинов дало сильный толчок к распространению кастомизированных товаров. Да, выбрать цвет обивки мебели и цвет шнурков можно было и раньше в офлайн-магазинах. Однако представьте, что вы потратили время на поездку в магазин, заказали вещь с определёнными параметрами, уехали домой и через некоторое время снова вернулись в магазин за заказом. Ещё длиннее цепочка у производителя. Из-за таких сложностей массовая кастомизация была непопулярной. Всё изменило появление интернет-магазинов.
Интернет-магазины и расширение возможностей кастомизации
Значительно уменьшить цепочку заказа товара с индивидуальными доработками позволили интернет-магазины. Покупатель сидит на диване у себя дома, клацает мышкой по составляющим товара и меняет их внешний вид по своему усмотрению. Производитель получает заказ с комментариями клиента и производит продукт. Клиент и производитель больше не должны тратить время на дорогу, чтобы обсудить детали заказа. Наличие офлайн-магазина теперь тоже не обязательно, что сокращает расходы на бизнес. И эти деньги можно потратить на производство индивидуальных заказов.
Интернет-маркетинг активно использует массовую кастомизацию, так как теперь коммуникация с пользователем происходит намного быстрее. Уже не обязательно создавать продукт до знакомства с потребителем. Куда проще создать отдельные составляющие, как конструктор, и дождаться клиента, который скажет, какие элементы он хочет видеть у вещи.
Есть множество примеров массовой кастомизации среди марок, производящих одежду и обувь, но нам кажется, что дальше всех в этом деле убежали фастфудные заведения, а именно, пиццерии и бургерные. Если вы зайдёте на сайт или в приложение Mcdonalds, KFC или Burger King, вы увидите, что при заказе бургера можно убрать почти все составляющие бутерброда или, наоборот, удвоить каждый ингредиент. То же самое и с пиццей. Что Papa John’s, что Dodo Pizza также предлагают убрать или добавить ингредиенты. Если вы с друзьями или со второй половинкой не можете решить, что заказать, то можно слепить две пиццы в одну и наслаждаться двумя вкусами.
Как видите, интернет-маркетинг развязал руки производителям. Теперь они могут предлагать больше видов кастомизации без ущерба процессу производства.
Задачи кастомизации в компьютерных технологиях
Задачи кастомизации в товарной сфере немного отличаются от целей кастомизации в IT. Когда потребитель покупает кастомизированные кроссовки, он думает не об удобстве, а в первую очередь о том, как он будет выделяться среди других пользователей кроссовок. За эксклюзив человек готов платить больше, поэтому на обычном рынке кастомизацию используют как маркетинговый приём, который позволяет значительно поднять ценник на товар. Также в сфере розничных продаж кастомизация может стать УТП (уникальным торговым предложением). «Конкуренты всех под одну гребёнку гребут, а мы учитываем интересы каждого», ― говорит глава маркетингового отдела.
В случае с IT-продуктами, кастомизация ― способ предоставить максимально удобный интерфейс. Каждый человек мыслит по-разному. Кому-то удобнее, когда меню справа, а кому-то слева. Одни люди предпочитают светлые тона в интерфейсе, другие ― тёмные. Создать идеальный интерфейс, адаптировать его для всех просто невозможно. Создавать внешний вид для людей с определённым мышлением ― неэффективно. Во главе угла всё-таки остаются возможности программы, её функционал. Вот разработчики и решаются кастомизировать, создавать разные интерфейсы для программ, чтобы любой человек смог выбрать, что ему больше по душе.
Удобство может быть не только в интерфейсе, но и в наборе функционала. Программа 1-С предлагает различный набор возможностей в зависимости от размеров и задач компании. По сути, программа остаётся той же, но для разных заказчиков собирается разный набор возможностей.
Разница между кастомизацией и персонализацией
Наверно, исходя из вышеописанного может показаться, что между термином «кастомизация» и «персонализация» можно поставить знак равно, ведь и та и другая технология пытается подстроиться под требования конкретного покупателя. Но разница кроется в инициаторе изменения продукта.
Сначала разберёмся с персонализацией. Организация, которая предоставляет товар или услугу, изучает своего клиента и на основе его предпочтений предлагает ему специальные предложения и скидки. Если мы говорим о розничной торговле, то вам могут предложить персонализированные подарки при покупке товара на определённую сумму. В случае с IT-сферой вы можете предложить промокоды для постоянных клиентов на обслуживание серверов, привилегии при обращении в техническую поддержку. Как видите, сама организация предлагает пользователю плюшки.
При кастомизации клиент сам дорабатывает для себя продукт. Он сам определяет, что ему нужно, и сам делает доработки, опираясь на возможности.
Рассмотрим на примере электронной почты. Во многих почтовых программах вы можете менять фон интерфейса, ставить фильтры на письма, менять порядок элементов в меню. Каждая из таких настроек и есть кастомизация. Ещё один простой, но распространённый вариант кастомизации ― тёмная и светлая тема интерфейса. Такой выбор предлагают YouTube, VK, Яндекс.Браузер. Каждый пользователь сам решает, какую тему выбрать, пусть с выбором сильно не разгуляешься. Для тех, кто знаком с панелями управления хостинга, вариант с темами можно встретить в cPanel. В настройках есть возможность выбрать одну из 5 вариантов тем интерфейса. Вот для примера две из них:
Плюсы и минусы внедрения кастомизации в интернет-маркетинге и IT
Из плюсов можно выделить:
Минусы тут тоже найдутся:
Технологией массовой кастомизации пользуется всё больше и больше компаний, продающих разные виды продуктов. Это тренд в сфере продаж. Из-за этого возрастает конкуренция среди индивидуализированных товаров. Поэтому думать о том, стоит ли внедрять элементы кастомизации не приходится. Ответ определённо положительный. Те, кто не задумываются о потребностях клиентов, в скором времени будут просто съедены более «дружелюбными» брендами. Любите и слушайте своих клиентов, и они полюбят вас.
Кастомизация компонентов Ant Design и оптимизация бандла
Иван Копенков, ведущий фронтенд-разработчик VK Cloud Solutions (бывш. MCS) рассказывает, какие есть подходы к кастомизации компонентов UI-библиотеки Ant Design, какой из них выбрали в MCS. И показывает, как удалось полностью избавиться от неиспользуемых модулей и уменьшить размер бандла.
Если вы уже используете или собираетесь использовать библиотеку компонентов Ant Design, то из данной статьи сможете узнать, как можно делать это удобнее и эффективнее. Если вы используете другую библиотеку компонентов, то сможете использовать описанный подход в работе с вашей UI-библиотекой.
Какие проблемы возникают при использовании UI-библиотек
UI-библиотеки предоставляют разработчикам возможность использовать готовые типовые компоненты, зачастую уже покрытые тестами и поддерживающие основные сценарии использования.
Однако в таком случае возникают две проблемы:
Первая проблема решается кастомизацией компонентов, а вторая — оптимизацией бандла. Некоторые библиотеки, например Ant Design, адаптированы под tree shaking, что позволяет сборщику вырезать из бандла неиспользуемые части.
Однако этого может оказаться недостаточно, так как в случае с Аnt Design в бандл все равно попадают все иконки и файлы локализации Moment.js. Кроме того, если где-то в проекте компоненты будут реэкспортится из одного файла, то все такие модули окажутся в сборке независимо от того, используются они или нет.
Способы кастомизации
Для начала разберемся, какие можно придумать решения, если для проекта требуется кастомизировать компоненты сторонней библиотеки.
1. Переопределение глобальных классов (только CSS)
Это самый легкий способ — просто модифицировать стили через CSS, изменяя свойства глобальных классов выбранной библиотеки компонентов.
Из очевидных недостатков:
В качестве единственного плюса этого подхода в голову приходит только его простота.
2. Локальные обертки для компонентов
Это более продвинутый способ — создать файл с оберткой над оригинальным компонентом и импортировать его во всех местах.
3. Форк репозитория библиотеки компонентов
На мой взгляд, это одновременно как самый мощный подход, так и самый сложный.
Как поступили мы
После длительного обсуждения наша команда выбрала использовать в новых проектах библиотеку Ant Design. На мою долю выпало полное создание каркаса будущих приложений, включая подключение библиотеки.
Нам, безусловно, требуется изменять не только стили, но и осуществлять многочисленные модификации и расширение логики работы компонентов UI-библиотеки. Форкать репозиторий Ant Design желания не было.
На проекте VK мы долгое время разрабатывали обертку над другой библиотекой компонентов Semantic UI, подключая ее из отдельного репозитория, но так и не нашли удобного способа для работы с ним. Переиспользовать этот репозиторий на другом проекте (b2b-облако) тоже оказалось неудобно, и мы с ним разошлись. В конечном итоге перенесли обертку из отдельного репозитория в сам проект.
Далее расскажу по шагам, как это было сделано и как это можно повторить в других проектах.
Шаг 1. Файлы с обертками
В папке с компонентами проекта я создал папку `antd`. В ней мы постепенно, по мере появления потребностей в модификациях, создаем файлы для наших оберток. Данные файлы представляют собой композицию, где компонент-обертка рендерит оригинальный компонент UI-библиотеки. Рассмотрим пример обертки в упрощенном виде.
В качестве примера модификации стилей изменяем цвет фона через Styled Components. А чтобы показать возможности кастомизации поведения, добавляем параметр, в зависимости от наличия которого при наведении указателя на кнопку будет появляться тултип.
Шаг 2. Замена импортов дефолтных компонентов алиасами на обертки
Теперь о том, как заставить сборщик (Webpack) при импортировании именованных модулей из корня `antd` заменять их на пути к нашим оберткам.
На этом этапе получаем примерно такое содержимое:
Теперь заменяем пути импорта тех компонентов, для которых мы сделали обертки. В нашем случае — импортируем Button из src/components/antd/Button:
Остается сделать так, чтобы Webpack при импорте компонентов из Ant Design фактически брал наши обертки. Для этого на основе файла antd/index.ts создаем набор алиасов и добавляем его в конфигурацию Webpack. В нашем случае мы автоматически создаем набор ссылок на ES-модули для Webpack. Для этого создали в папке с конфигами Webpack файл AntAliases.ts, который автоматически собирает набор алиасов на основе имеющихся оберток и относительных импортов библиотеки Ant Design на свои же модули.
Содержимое AntAliases.ts:
В приведенном выше файле AntAliases.ts также решается проблема использования составными компонентами некастомизированных версий: в файлах библиотеки ищутся все относительные импорты вложенных компонеyтов составными, и для них тоже создаются алиасы, указывающие на наши обертки.
Секция resolve нашего конфига для Webpack выглядит так:
Шаг 3. Поддержка TypeScript (опционально)
В целом первых двух шагов достаточно, чтобы все работало. Но если вы используете TypeScript и изменяете интерфейс обернутых компонентов (как в нашем случае — добавлением к пропсам обертки для Button поля tooltipTitle), то потребуется добавить алиасы в конфиг TypeScript. Здесь уже гораздо проще — достаточно всего одной строки в разделе paths файла tsconfig.json:
Шаг 4. Использование переменных (опционально)
Поскольку мы используем Styled Components, нам удобно хранить переменные для стилей в отдельном ts-файле. Стили Ant Design написаны на less, поэтому есть возможность собирать их, передавая переменные через less-loader. В связи с этим у нас используются одни и те же переменные и для сборки стилей UI-библиотеки, и для стилизованных компонентов внутри проекта.
Так как наш стайлгайд предполагает написание кода в camelCase, мы объявляем css-переменные в том же стиле. В less-файлах Ant Design переменные используются в kebab-case, поэтому наши переменные экспортируем в обоих стилях, автоматически переводя camelCase в kebab-сase с помощью Lodash.
Файл с переменными в сокращенном виде выглядит так:
Полный список переменных Ant Design можно посмотреть в этом файле.
Сборка less-файлов и инжект переменных делается добавлением соответствующего лоадера в конфиг Webpack:
Пример использования компонентов
После этих манипуляций все должно работать. Так выглядит код, в котором мы используем модифицированные компоненты:
Проблема с комплексными компонентами
Этот пункт можно пропустить, но остается проблема с двумя комплексными компонентами: Grid и Radio. Фактически компонента Grid не существует, в файле node_modules/antd/es/grid/index.js лежат реэкспорты компонентов Col и Row.
Во всех других сложных компонентах уже автоматически используются существующие обертки, благодаря добавленным на втором шаге алиасам. Но если нужно, чтобы Grid отрисовывал кастомные Col и Row, то нужно сделать следующее.
В качестве примера я создал обертку над компонентом Col и сделал фон этого компонента красным по умолчанию. Для теста отрисовываю оригинальный компонент List и хочу добиться того, чтобы в качестве столбцов он выводил кастомный Col.
Чтобы List использовал не дефолтный Col, а именно нашу обертку, в папке components/antd создаем файл Grid.tsx со следующим содержанием:
И в файле AntAliases.ts указываем путь к обертке для Col в константе SPECIAL_ALIASES:
На этом манипуляции закончены. Теперь List будет выводить нашу обертку в качестве столбцов. Когда мы захотим кастомизировать Row, нужно будет создать файл с оберткой и указать пути к нему в Grid.tsx и переменной SPECIAL_ALIASES. Это не очень удобно, но этот шаг при необходимости потребуется только для компонентов Grid и Radio, в чем на реальных проектах у нас пока нужды не возникало.
Оптимизация сборки
Tree shaking
Как уже указывалось, сейчас Ant Design поддерживает tree shaking из коробки. В более ранних версиях для этого приходилось использовать babel-plugin-import. Полагаю, что для UI-библиотек без поддержки tree shaking можно попробовать активировать его хотя бы частично с помощью этого же плагина.
Импорт стилей
Несмотря на нативную поддержку tree shaking, от babel-plugin-import мы не отказались. Он все еще нужен нам, чтобы при импорте js-файлов компонента в проект автоматически подтягивались файлы со стилями. Так в бандле остаются только нужные стили и становится невозможной ситуация, когда разработчик забывает вручную импортировать стили отдельного компонента.
Что такое кастомизация в программировании
Курс предназначен для базовой подготовки администраторов сайтов, созданных на «1С-Битрикс: Управление сайтом». Изучив курс, вы освоите основные методы администрирования системы, а также пополните знания по темам, изученным в курсе Контент-менеджер.
Если вы добросовестно изучите курс, то научитесь:
Если вам предстоит самостоятельная установка системы или перенос сайта на хостинг, то без курса Установка и настройка Курс Установка и настройка предназначен для специалистов устанавливающих «1С-Битрикс: Управление сайтом» или «Битрикс24 в коробке».
Начальные требования
Необходимый минимум знаний для изучения курса:
Неплохо было бы иметь базовые навыки установки и администрирования *nix-систем.
У нас часто спрашивают, сколько нужно заплатить
Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.
Баллы опыта
уроке.
Тесты и сертификат
Иконка успешно сданного вами курса отображается в вашем профиле на Freelance, если вы укажите ссылку на ваш профиль на сайте компании 1С-Битрикс.
Комментарии к урокам
Для преподавания оффлайн
Если данный курс берётся в качестве основы для оффлайного преподавания, то рекомендуемая продолжительность: 3 дня (24 академических часа).
Если нет интернета
Скачать материалы курса в формате EPUB. Файлы формата EPUB Чем открыть файл на
Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox
iPhone:
FBReader
CoolReader
iBook
Bookmate
Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome
Как проходить учебный курс?
О кастомизации информационных систем
Основное направление деятельности нашей компании — это разработка корпоративных информационных систем. Помимо систем под заказ мы делаем два тиражируемых продукта. Конечно, мы стараемся, чтобы наши продукты были максимально удобными и функциональными. Однако в реальной жизни каждый бизнес имеет свои особенности и не всегда готов мириться со стандартными возможностями системы. Возникает задача доработки решения под конкретного клиента и его дальнейшей поддержки. Какие существуют подходы к организации архитектуры расширяемых продуктов? Какие проблемы могут возникнуть при разработке? Как поступили мы? Обо всем этом ниже.
Возможные подходы
Пожалуй, эта мысль — первая, которая приходит в голову, ведь ответвиться от основного продукта и внести изменения в новый бранч — самый быстрый способ достичь желаемого результата. Вопрос лишь в цене, которую придется заплатить за эту быстроту.
После разработки и внедрения информационной системы начинается самая долгая и часто самая болезненная фаза жизненного цикла — поддержка. В случае с проектом-расширением эта фаза может стать вдвойне неприятнее, ведь придется поставлять заказчику не только новые “фичи”, которые реализованы специально для него, но и новые версии продукта, на котором основано расширение. Для того, чтобы в проект попали изменения из новой версии продукта, видится один способ — merge изменений из основной ветки в бранч расширения. Но представьте, насколько это окажется трудоемко, и сколько потенциальных ошибок может проявиться, если один и тот же участок кода сильно изменялся в обеих ветках.
Можно, конечно, сразу думать о будущих переводах на новую версию продукта и организовывать код таким образом, что все специфичные изменения будут располагаться максимально в стороне от кода основного продукта. В идеальном мире это бы сработало, но мы с вами живем в суровой реальности, где часто срок выполнения задачи может быть объявлен как “вчера”, и работает над проектом отнюдь не компактная команда классных профессионалов, а батальон вчерашних студентов. В таких ситуациях люди редко задумываются об архитектуре и идут по пути наименьшего сопротивления — нашел место, где надо поправить, удалил старое, написал новое. Это, кстати, ведет к еще одной большой проблеме — логика расширения перемешивается с логикой продукта.
Итог: данный подход является самым гибким, так как позволяет изменить абсолютно любую часть продукта, но радоваться гибкости придется только первые пару обновлений. Впоследствии огромные сложности доставят поддержка расширения и перевод его на новые версии продукта. Причем чем дольше будет жить информационная система, тем более и более трудоемкой будет становиться поддержка.
Далее о недостатках. Во-первых, это ограниченность применения. Модель EAV позволит лишь добавить атрибуты в сущность и отобразить их в заранее определенном месте на экране. Не более того. Об изменении функциональности, хитрых UI-компонентах здесь речи не идет.
В-третьих, опять же из-за структуры базы будет довольно сложно делать выборки данных для отчетов — вместо написания обычного SQL для реляционных данных потребуются гораздо более сложные запросы.
Данная архитектура позволяет хранить дополнительную функциональность в отдельных артефактах — плагинах. Если ваш заказчик хочет какой-то новой специфики, то вы ставите ему базовый продукт, пишете плагин, подключаете его и готово. Для использования плагинов в продукте должны быть объявлены точки расширения. Что это такое? Если просто, то это определенные места в коде. В этих местах перебираются загруженные плагины, анализируется, есть ли в плагинах логика, предназначенная для данной точки расширения, и если такая логика находится, она выполняется. Примеры точек расширения: пункт меню, обрабочик команды, кнопка на тулбаре, новый экран.
Такой часто используемый вариант расширения функциональности, как описание логики и обработчиков событий во внешних скриптах, также можно отнести к вариациям плагинов, т.к. скрипты вызываются и исполняются определенными точками программы.
Плагинная архитектура позволяет хранить всю новую функциональность отдельно от продукта, что является немаловажным её достоинством. Полное физическое разделение продукта и плагинов делает процесс обновления версии продукта или плагина очень простым — достаточно лишь заменить обновленный компонент.
Но и здесь, к сожалению, есть недостатки. Для каких-то продуктов они окажутся несущественными, для каких-то могут стать причиной невозможности использования плагинной архитектуры. Дело в том, что плагин может расширить систему лишь в том месте, где определена точка расширения. Бесспорно, существует класс продуктов, где таких мест в принципе немного и все они заранее определены, но есть также и огромная группа, для которой предугадать, что потребуется расширить завтра, практически невозможно. Анализ потенциальных расширяемых мест может стать очень ресурсоемким занятием, а в результате все равно оказаться не совсем точным. Кроме того, точки расширения — это усложнение основного кода, что всегда чревато ошибками и сложностью сопровождения. Подходить к определению точек расширения в основном продукте надо очень вдумчиво.
Как это делаем мы
Мы выпустили на рынок два тиражируемых продукта: ECM (или в более привычных терминах, систему электронного документооборота, СЭД) ТЕЗИС и систему для автоматизации бизнеса такси Sherlock. С самого начала было очевидно: для того, чтобы поставить конкретному клиенту максимально удобную систему, потребуются доработки продукта, и следовательно в основе продукта должна лежать легко расширяемая архитектура.
Начиная работу над новым расширением, часто мы даже не предполагали, в какого «монстра» (в хорошем смысле слова) этот проект может перерасти. Обычное явление — когда то, что начиналось как небольшая кастомизация, заканчивается практически полностью переписанными бизнес-процессами и дополнительной логикой на доброй половине экранов. Вдобавок продукт может расшириться новой функциональностью, вполне достаточной для самостоятельной системы. Как пример — в проекте-расширении ТЕЗИС для крупной распределенной компании появилась автоматизация деятельности казначейства, оценки эффективности работы сотрудников и еще несколько непростых модулей.
Разнообразие требований, их объем и непредсказуемость не позволяли использовать ни один из способов, описанных выше. Вдобавок ко всему, версии продуктов выходят довольно регулярно. Это делает обязательным требованием максимальную легкость перевода проекта-расширения на новую версию продукта.
Как же мы решаем проблему создания и поддержки расширений?
Наш проект-расширение
Большинство проектов нашей компании созданы с помощью платформы CUBA. Мы уже писали о ней в одной из прошлых статей. Для того, чтобы понять, как организованы проекты-расширения, сначала нужно разобраться с устройством самой платформы.
При создании нового проекта, в его скрипте сборки прописываются зависимости от тех базовых модулей платформы, функциональность которых необходима. После этого, используя сущности, экраны и сервисы подключенных модулей, мы начинаем реализовывать проект. Физически модули платформы — это jar файлы, а установленный на сервере проект — обычное Java веб-приложение.
Когда нужно расширить существующий продукт на платформе, мы поступаем так: создаем новый проект, но в его скрипте сборки указываем зависимость уже не от модулей платформы, а от расширяемого продукта. Продукт сам фактически выступает в роли платформы для разработки.
Теперь внутри проекта-расширения можно создавать новые объекты доменной модели, описывать новый пользовательский интерфейс как в самом обычном проекте на платформе CUBA. Весь функционал ниже-лежащих модулей разработчику по прежнему доступен.
Самое очевидное достоинство — вся новая логика хранится в отдельном проекте-расширении. Всегда можно увидеть, что именно и когда вы написали в рамках текущего расширения. Подход никак не ограничивает разработчика в типе новой функциональности, как это делают плагинная архитектура и EAV.
Добавление нового атрибута в сущность базового продукта
Определим для себя задачу: в сущность User базового продукта необходимо добавить поле для хранения адреса. Подобные требования, пожалуй, самые распространенные среди наших заказчиков. Сразу скажем, что платформа поддерживает модель динамических атрибутов, о которых писалось выше, но на практике этот вариант используется редко — скорость выборки данных и легкость построения отчетов практически всегда оказываются важным требованием.
Собственно об альтернативном способе добавления атрибута. В качестве ORM платформой используется OpenJPA. Объявление сущности в продукте выглядит следующим образом:
Как видите, это стандартное для JPA описание сущности и маппинга на таблицу и колонки БД.
Создаем наследника сущности в проекте-расширении:
Теперь все операции создания сущности User будут создавать экземпляр расширенной сущности:
Операции извлечения данных из БД также вернут экземпляры новой сущности. Например, в базовом продукте объявлен сервис поиска пользователей по имени, возвращающий результат следующего JPQL запроса:
Сущность переопределена. Теперь хорошо бы отобразить новое поле пользователю.
Видим ссылку на контроллер экрана UserEditor, объявление источника данных (datasource), компонента fieldGroup, отображающего поля сущности, и фрейм со стандартными действиями “ОК” и “Отмена” (windowActions).
Совсем не хочется дублировать код базового экрана в проекте-расширении, поэтому мы добавили в платформу возможность наследования XML-дескрипторов экранов. Вот так выглядит наследник экрана из базового проекта:
В экране-наследнике указывается предок (атрибут extends) и описываются лишь те компоненты, которые должны быть добавлены в базовый экран либо переопределены в нем. Остается лишь объявить экран в конфигурационном файле с идентификатором базового экрана:
Переопределение бизнес-логики
Что касается переопределения функциональности, то здесь все достаточно тривиально. Инфраструктура платформы реализована на Spring. Соответственно и слой сервисов с бизнес логикой — это управляемые спрингом бины. Возможностей расширения, предоставляемых фреймворком, оказывается более чем достаточно для переопределения нужной бизнес-логики. Чтобы наглядно это продемонстрировать, снова небольшой пример. Допустим, на среднем слое в базовом продукте имеется компонент, выполняющий расчет цены:
Для того, чтобы в проекте-расширении заменить алгоритм расчета цены мы делаем 2 простых шага:
Создаем наследника переопределяемого компонента:
Регистрируем класс в конфигурационном файле Spring с идентификатором бина из базового продукта:
Теперь контейнер Spring будет всегда возвращать нам экземпляр ExtPriceCalculator.
Переопределение темы
С модификацией сущностей, компонентов экранов и бизнес-логики мы разобрались. Следующая на очереди визуальная тема.
Экраны, созданные с помощью платформы, работают в веб и десктоп клиентах. На текущий момент у нас преобладает использование веб-клиентов, поэтому говоря о кастомизации темы, рассмотрим именно их.
Для реализации веб-UI нами был выбран популярный фреймворк Vaadin. Vaadin позволяет описывать темы на SCSS. Описание стилей для новой темы на SCSS само по себе в разы приятнее, чем на чистом CSS. Мы сделали процесс создания темы еще менее трудоемким, вынеся множество параметров в переменные.
Заготовка для новой темы создается в 2 клика с помощью нашей студии разработки. Новая тема импортирует стили базовой темы платформы, разработчику остается переопределить лишь нужные стили и переменные. Многие клиенты желают видеть информационную систему в корпоративных цветах своей компании. Используемый нами подход к расширению тем позволяет им легко этого добиться.
В проекте расширении разработчику доступна возможность подключения новых визуальных компонентов. Большое количество готовых компонентов имеется в репозитории аддонов Vaadin. Если нужного компонента там не нашлось, то можно написать его самому.
Примеры различных визуальных тем:
Заключение
Если наш подход показался вам интересным, то можете попробовать платформу CUBA сами. Создавая продукт на платформе, вы автоматически получаете возможность кастомизировать его описанным способом. Всегда рады отзывам и комментариям!
