Кастомизации в 1С
О кастомизациях вообще
Потребность в кастомизации программного обеспечения, т.е. его изменения под нужды конкретного пользователя, появилась, наверное, одновременно с самим программным обеспечением. Трудно написать программу, которая удовлетворит всех, а потому заложить в нее возможность изменений без привлечения производителя программы – хорошая идея. Особенно если дело касается бизнес-приложений, т.к. бизнес-процессы даже в одних и тех же областях могут отличаться в разных организациях.
Изменение исходного кода
Есть разные стратегии кастомизаций. Если приложение поставляется в исходных кодах, то самый очевидный подход – переписать исходный код под свои нужды. И самая очевидная в этом случае проблема – переход на новую версию приложения, т.к. он влечет слияние (merge) исходных кодов измененной на стороне клиента версии и новой версии от поставщика. А это может быть нетривиальной задачей, особенно если код на стороне клиента сильно кастомизирован.
Плагины
Более безопасная в этом плане стратегия – плагины. Исходное приложение предоставляет плагину фиксированный набор интерфейсов, а также возможность зарегистрировать себя в приложении. При выходе новой версии приложения плагины, написанные для предыдущей версии, продолжат работать и в новой версии (при условии неизменности интерфейсов). Поведение плагинов в новой версии может отличаться от поведения в предыдущей, если поставщик ПО изменил поведение приложения. Концепция плагинов используется в самых разнообразных классах ПО – офисном и бизнес-софте, средах разработки (Visual Studio, Eclipse, …), графических и звуковых редакторах и т.п.
Подписки
Еще одна технология кастомизации – возможность оформления подписки (subscription) на события в приложении и выполнения пользовательского кода на общеизвестном или проприетарном языке во время этих событий. События могут быть самого разного вида – открытие окна, загрузка изображения (для графического редактора), обработка заказа (для бизнес-системы).
Одна из разновидностей такого подхода – встраивание в основную программу возможности выполнять пользовательские скрипты на языках типа Visual Basic for Application (VBA). Кастомный код может, в частности, выполняться в ответ на события приложения. Тот же VBA показал себя очень мощным и гибким средством кастомизации; он встроен в Microsoft Office, AutoCAD, SolidWorks, CorelDRAW, WordPerfect, ESRI ArcGIS и другие продукты.
Кастомизации в решениях «1С»: начало
В платформе «1С:Предприятие» реализованы разные стратегии кастомизации. Поскольку прикладные решения 1С поставляются в исходных кодах, естественно, один из самых очевидных сценариев – изменение исходного кода.
Изменение исходного кода приложений 1С
Когда клиент меняет исходный код решения 1С под свои нужды, ему надо помнить, что поставщик приложения тоже не бездействует и выпускает новые версии, добавляя функциональность и исправляя ошибки. Чтобы при установке новой версии приложения не потерялись изменения, сделанные под потребности клиента, нужно каким-то образом произвести слияние (merge) измененной предыдущей версии приложения и новой версии.
Естественно, мы в «1С» уделяли большое внимание этой задаче и разработали механизм поставки и поддержки, облегчающий ее решение. Прежде чем рассказать, как он работает – пара деталей о внутреннем устройстве решений «1С».
Исходные коды и метаданные прикладного решения «1С» (конфигурации) хранятся в базе данных, в той же самой, в которой лежат данные самого приложения (проводки, данные справочников и документов и т.п.), т.е. программа хранится вместе с данными. База данных с конфигурацией (и данными приложения) в терминологии 1С называется информационной базой (сокращенно – инфобазой).
В процессе разработки поставщик конфигурации определяет, какие объекты конфигурации (справочники, документы и т.п.) клиент может менять, а какие – нет.
Настройка поставки на стороне поставщика
Клиент на своей стороне с помощью этого механизма также может определять правила поддержки объектов внедренной конфигурации поставщика— например, он может отказаться от поддержки поставщиком конкретного объекта, если возьмет на себя ответственность за дальнейшую модификацию этого объекта. А можно, наоборот, запретить редактирование объекта «своей» конфигурации (даже если поставщик разрешает это делать) с тем, чтобы застраховаться от случайного изменения.
Настройка поддержки на стороне клиента
Когда клиент начинает что-то менять в типовой конфигурации, в инфобазе создаются две конфигурации:
Внешние отчеты и обработки
Другой механизм кастомизации, сравнительно безопасный с точки зрения перехода на новые версии – это механизм внешних отчетов и обработок. Как следует из названия, оба типа объектов — внешние отчеты и внешние обработки – являются внешними по отношению к прикладному решению, хранятся в отдельных файлах и загружаются в прикладное решение в момент исполнения. Таким образом, процесс перехода на новую версию не затрагивает их вовсе. Но в случае, если в новой версии реквизиты какого-либо объекта были удалены или переименованы, а обработка или отчет обращаются к ним – на новой версии отчет или обработка без переделки не заработают.
Внешние отчеты и обработки по сути являются плагинами. Они хорошо подходят для «кастомных» отчетов и специфических операций над данными (например, для импорта информации из других систем), но, конечно, покрывают далеко не все сценарии кастомизации. Если клиенту нужно добавить специфический код, который должен выполняться при проведении документа, внешней обработкой тут не обойтись – надо править исходный код модуля документа.
Кастомизации в облаках
С появлением облачной технологии 1cFresh задача кастомизации вышла на новый уровень. Дело в том, что в «облаке» пользователи прикладного решения из разных организаций могут физически работать с одной информационной базой (т.е. с одним экземпляром приложения), но, в то же время, благодаря механизму разделения данных, видят только данные своей организации. Кастомизация через изменение исходного кода здесь становятся неприемлемой – каждой организации нужны свои кастомизации, и совершенно не нужны кастомизации «соседей» по инфобазе.
В «облаке» для кастомизации применимо только использование внешних отчетов и обработок, но, как говорилось выше, внешние отчеты и обработки покрывают далеко не все нужные пользователям сценарии.
Расширения конфигурации
Итак, нам нужно было придумать механизм кастомизации, который бы удовлетворял следующим требованиям:
Расширения – это способ держать изменения конфигурации отдельно от самой конфигурации. Расширение, по сути, само является отдельной конфигурацией, содержащей измененные объекты. Оно так же, как и конфигурация, представляется в виде дерева объектов. Для работы с расширением используются те же приёмы работы, что и с обычной конфигурацией:
Если мы хотим задействовать в расширении объект из основной конфигурации (например, добавить новую форму к существующему в основной конфигурации документу) – нам вначале надо позаимствовать объект к себе в расширение через команду «Добавить в расширение». Сразу после добавления объекта в расширение он «пустой» в дереве объектов расширения – у него есть только те свойства, которые есть в основной конфигурации. Можно также позаимствовать из основной конфигурации уже существующую форму и, например, добавить к ней новую кнопку, выполняющую какое-либо специфическое действие. К объектам в расширениях пока нельзя добавлять новые реквизиты, но мы работаем над этим.
Основная конфигурация и расширение с заимствованным документом СчетФактураВыданный
В расширении также есть аналог подписки на события — возможность обрабатывать события объектов расширяемой конфигурации, например, обработку записи. Можно указать, как именно будет вызываться наш код в расширении:
Мы можем перед стандартной процедурой записи документа вызвать наш код, который, например, проверит, заполнено ли поле ответственного за документ сотрудника, и если нет – запишет в это поле текущего пользователя:
В новой версии конфигурации реализация записи документа может измениться, но наш код в расширении будет по-прежнему выполняться перед стандартным кодом записи документа и делать свою работу.
Во время исполнения типовая конфигурация и расширения (их может быть несколько) «складываются», давая в итоге новую, кастомизированную конфигурацию, с которой и работает конечный пользователь.
Порядок выполнения расширений
При разработке расширений следует помнить, что платформа не гарантирует одинакового порядка выполнения расширений при добавлении нескольких расширений к конфигурации. Мы сознательно отказались от явного задания порядка выполнения расширений, т.к. это, на наш взгляд, усложняет настройку и в конечном счете привносит больше проблем, чем решает.
Если у нас к конфигурации добавляются несколько расширений, в каждом из которых есть обработка проведения одного и того же документа с директивой «&После», то все обработчики будут выполнены, но платформа не гарантирует, что порядок их выполнения всегда будет одинаков. Это надо учитывать при разработке расширений.
В случае наличия в нескольких расширениях обработчика одного и того же события с директивой «&Вместо» будет выполнен только один обработчик, причем какой – заранее сказать нельзя. Об этом нужно помнить и отслеживать, чтобы к конфигурации не более одного расширения имели обработчик «&Вместо» для одного и того же объекта/события.
Кастомизация форм в расширениях
Мы можем позаимствовать в свое расширение форму объекта из конфигурации (например, форму документа). При этом в визуальном редакторе формы в расширении мы увидим форму такой же, как и в основной конфигурации. А в редакторе кода формы в расширении будет пусто – весь код для формы пока содержится только в основной конфигурации.
На форму можно добавить новую кнопку (или даже несколько). В случае если несколько расширений добавляют на одну и ту же форму свои кнопки – все они будут присутствовать на итоговой форме во время исполнения.
А вот удалять стандартные элементы с формы не рекомендуется – это может сломать существующий в оригинальной конфигурации код (если он обращается к элементам формы). Если уж есть такая нужда – лучше делать элементы невидимыми через свойство «Видимость».
Нужно учитывать, что приложение на «1С:Предприятии» — это не просто код на языке программирования. БОльшая часть приложения описывается в виде декларативных моделей. Причем для разных задач используются разные виды моделей (формы, отчеты, права, ….). Для каждого вида модели мы подбираем свой способ кастомизации в расширениях, обеспечивающий наиболее удобное изменение для типичных случаев.
Преимущества расширений
Расширения имеют идеологическое отличие от механизма поставки и поддержки. В механизме поставки и поддержки разработчик правит конфигурацию поставщика, как хочет, как будто просто дорабатывает свою конфигурацию, а потом (при обновлении) разбирается с тем, как синхронизировать конфликтующие изменения. В расширениях разработчик сразу изначально разрабатывает именно расширение – в терминах добавляемой функциональности. Расширение хранится системой именно как дополнение и система заботится о максимально безопасном обновлении.
Простота перехода на новую версию конфигурации
Когда поставщик выпускает новую версию типовой конфигурации, выполняется автоматическое обновление, поскольку режим поддержки типовой конфигурации не менялся — она осталась на полной поддержке поставщика. А при запуске обновлённого прикладного решения платформа снова автоматически объединит изменённую типовую конфигурацию с расширением. И клиент продолжит работать с изменённым под его потребности типовым решением.
Иногда все же после обновления версии типовой конфигурации может потребоваться адаптация расширения под новую версию, например, если в новой версии переименованы объекты или реквизиты объектов, задействованных в расширении. Чуть подробнее об этом ниже, в разделе «Раннее оповещение об ошибках».
Изменения лежат отдельно
Первое очевидное преимущество расширений – все кастомизации, сделанные для клиента, лежат отдельно от типовой конфигурации, и теперь не надо сравнивать измененную конфигурацию с типовой чтобы понять, что же именно было изменено.
Уже упоминалось, что для того, чтобы задействовать в расширении объект из основной конфигурации, его надо позаимствовать в расширение из основной конфигурации. Таким образом, в расширении появляется нечто вроде ссылки на объект из основной конфигурации.
При этом есть способ понять, какие заимствованные объекты в конфигурации действительно изменены, а какие позаимствованы в режиме read-only – например, для использования в отчетах. В дереве объектов расширения есть кнопка фильтра «Изменённые и добавленные в расширении», после нажатия которой в дереве остаются только заимствованные объекты, модифицированные в этом расширении, и новые объекты, созданные в этом расширении.
Раннее оповещение об ошибках
Предположим, мы позаимствовали в расширение справочник Контракты из основной конфигурации для использования его в отчете. Тем временем вышла новая версия типовой конфигурации, в которой справочник Контракты был переименован в Договоры. Естественно, после перехода на новую версию наш отчет в расширении работать не будет. Если бы мы использовали старую технологию кастомизации — внешний отчет, то ошибка возникла бы только в момент выполнения отчета. В случае же расширений у нас есть возможность проверить корректность расширений в design-time после обновления версии типовой конфигурации, и исправить все проблемы до того, как пользователи начнут работу.
Особенно это актуально на внедрениях, где в одной информационной базе используется много расширений, а обновление версии конфигурации проводится централизованно (например, на облачных внедрениях, где разные организации, использующие одну и ту же конфигурацию, но работающие в разных областях данных, могут использовать разные наборы расширений). Администратор может на тестовой базе обновить версию типовой конфигурации и проверить корректность всех пользовательских расширений относительно новой версии. В случае проблем он сообщит о них владельцам расширений, и переход рабочей базы на новую версию типовой конфигурации будет сделан только тогда, когда все расширения будут приведены в соответствие с новой версией конфигурации.
Что дальше?
Мы считаем развитие расширений одним из главных направлений развития средств кастомизации в платформе «1С:Предприятие». Расширения, задуманные изначально для облегчения кастомизаций в облачном сервисе, были спроектированы так, чтобы облегчить и ситуации с кастомизациями и на не-облачных внедрениях.
Пока в расширениях можно откастомизировать не всё, что хочется. Например, пока нельзя создавать новые прикладные объекты (справочники, документы и т.д.) и нельзя добавлять новые реквизиты к существующим прикладным объектам. Мы работаем над этим (и над другими возможностями тоже) и практически в каждой новой версии платформы «1С:Предприятие» добавляем в расширения новые возможности:
Программерский сленг: что означает «кастомный» и «кастить»?
Что означает «Программа «[4872] laba!.exe: Машинный код» завершилась с кодом 3 (0x3).»?
при запуске кода компилятор пишет «Программа » laba. exe: Машинный код» завершилась с кодом 3.
Для каждой строки найти слова, которые не имеют ни одного из букв: «l», «k», «r», «s» i «j»
Задано символьные строки. Строка состоит из нескольких слов (наборов символов), которые разделяются.
В Google то трудно зайти?
qppq, дать ссылки на курсы английского?
Visual Studio не читает операторы, что начинаются на «glu» («gluBuild2DMipmaps», «gluPerspective»)
Этот код должен выводить на экран кубик, который по идее должен вращаться, но возникла проблема.
Что Вы понимаете под «абстрактным типом», «абстракцией данных» и «абстрактными операциями»?
А давайте займёмся археологией! И проследим как менялся смысл понятий «абстрактный тип данных».
Visual Studio не читает операторы, что начинаются на «glu» («gluBuild2DMipmaps», «gluPerspective»)
Данный код должен выводить на экран кубик который должен вращаться, но возникла проблема. Для.
Создать класс «Книга» с полями «название книги», «количество страниц», «год издания»
Создать класс Книга поля: название книги,количество страниц,год издания методы: вычислить сколько.
О кастомизации информационных систем
Основное направление деятельности нашей компании — это разработка корпоративных информационных систем. Помимо систем под заказ мы делаем два тиражируемых продукта. Конечно, мы стараемся, чтобы наши продукты были максимально удобными и функциональными. Однако в реальной жизни каждый бизнес имеет свои особенности и не всегда готов мириться со стандартными возможностями системы. Возникает задача доработки решения под конкретного клиента и его дальнейшей поддержки. Какие существуют подходы к организации архитектуры расширяемых продуктов? Какие проблемы могут возникнуть при разработке? Как поступили мы? Обо всем этом ниже.
Возможные подходы
Пожалуй, эта мысль — первая, которая приходит в голову, ведь ответвиться от основного продукта и внести изменения в новый бранч — самый быстрый способ достичь желаемого результата. Вопрос лишь в цене, которую придется заплатить за эту быстроту.
После разработки и внедрения информационной системы начинается самая долгая и часто самая болезненная фаза жизненного цикла — поддержка. В случае с проектом-расширением эта фаза может стать вдвойне неприятнее, ведь придется поставлять заказчику не только новые “фичи”, которые реализованы специально для него, но и новые версии продукта, на котором основано расширение. Для того, чтобы в проект попали изменения из новой версии продукта, видится один способ — 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 сами. Создавая продукт на платформе, вы автоматически получаете возможность кастомизировать его описанным способом. Всегда рады отзывам и комментариям!