CUBA — платформа для быстрой разработки бизнес-приложений на Java

    Если вы занимаетесь разработкой софта для предприятий, то возможно уже написали собственную платформу. Которая позволяет вам быстро создавать UI и логику для работы с данными, содержит общую для ваших проектов функциональность: управление правами пользователей, генератор отчетов, BPM и тому подобное, и имеет архитектуру, позволяющую легко сопровождать и масштабировать приложение. Если еще не успели написать, предлагаем познакомиться с нашей разработкой — платформой CUBA.

    image

    Платформа существует более четырех лет, но до сих пор она использовалась в довольно узком кругу разработчиков нашей компании и партнеров. Мы успели сделать на ней два тиражируемых продукта и больше десятка заказных проектов. И вот настал момент, когда после длительной подготовки, мы решились выпустить ее в виде продукта, доступного всем желающим.

    Для начала приведу краткий список основных возможностей. Подробности разумеется можно узнать на сайте.
    • Декларативное создание UI: компоновка экранов в XML, инициализация и обработка событий в классах Java.
    • Библиотека data-aware визуальных компонентов. Есть все стандартные, плюс специфические, например, универсальный фильтр данных, поля выбора связанных сущностей с разнообразными возможностями, таблица с группировками.
    • Экраны работают в веб (AJAX) и в десктоп (Swing) клиентах. Исходники общие.
    • Метаданные — расширенная информация о модели данных. Проектирование модели данных «от сущностей к таблицам».
    • Мягкое удаление записей в БД.
    • Управление правами доступа на уровне операций с сущностями, их атрибутов и отдельных экземпляров, экранов и компонентов UI.
    • Подключаемая при необходимости функциональность: генератор отчетов, модуль бизнес-процессов с визуальным редактором, полнотекстовый поиск, работа с кредитными картами.
    • «Из коробки» поддерживаются PostgreSQL, MS SQL Server, Oracle, HSQL.
    • Стандартный деплоймент на любом веб-контейнере.
    • Горизонтальное масштабирование на кластере серверов, можно отдельно средний слой, отдельно веб-серверы.

    Ну и для того, чтобы всем этим было удобно пользоваться, мы сделали Студию. Это отдельное приложение, которым пользуется разработчик параллельно с обычной Java IDE. Студия предоставляет графический интерфейс к механизмам платформы, позволяя мышкой накликать модель данных, сгенерировать DDL-скрипты для БД, нарисовать экраны в WYSIWYG-редакторе, сделать заготовки сервисов среднего слоя. Использование Студии не обязательно, но сильно облегчает многие вещи, особенно на начальном этапе проекта.

    Кому это может пригодиться?


    Мы позиционируем CUBA в первую очередь как инструмент для разработчиков, занимающихся автоматизацией внутренних бизнес-процессов предприятий. Это могут быть производственные процессы, закупки и продажи, документооборот, управление персоналом, средства мониторинга и так далее. CUBA может послужить основой любой учетной или управленческой системы.

    Кроме того, проверенным вариантом является использование платформы в качестве backend распределенной системы. В этом случае на платформе создается средний слой с основной бизнес-логикой и UI для сотрудников, а сайты и мобильные приложения для внешних пользователей выступают клиентами среднего слоя.



    Используя платформу, можно сосредоточиться в основном на бизнес-логике, так как большинство инфраструктурных задач уже решены. Соответственно, сделать проект быстрее и меньшими усилиями.

    Условия использования CUBA описаны на нашем сайте. Бесплатный вариант есть.

    Документация есть.

    История


    Теперь хочу рассказать о зарождении и эволюции платформы. Собственно, в основном речь пойдет о технологиях, так что станет примерно понятно, как CUBA устроена.

    С чего все началось. Наша компания создавалась для того, чтобы делать информационные системы для предприятий. Разные системы для разных предприятий, и чем больше, тем лучше. То, что писать мы будем на Java, не вызывало сомнений в силу предыдущего положительного опыта, независимости от ОС, наличия великолепной IDE, широкого выбора фреймворков всех уровней и тому подобного. В то же время мы понимали, что делать каждый проект с нуля, пользуясь только тем, что дают Java и доступные фреймворки, сложно и неэффективно. Значительная часть функциональности корпоративных систем пересекается, независимо от особенностей бизнеса. Да и ту часть, которая уникальна в каждом приложении, мы хотели делать проще и быстрее. К сожалению (или к счастью), мы не нашли ничего готового в мире Java, что удовлетворяло бы нашим требованиям, никакой подходящей «платформы для быстрого создания бизнес-приложений», и как водится, решили написать свою.

    Начали со среднего слоя — взяли JBoss с EJB3, в качестве ORM прикрутили OpenJPA. Почему не Hibernate — это тема для отдельной статьи, постараемся со временем ее написать. Научили OpenJPA работать с мягким удалением прозрачно для разработчика, чтобы не надо было ничего дописывать в запросы и контролировать результаты.

    Написали свой фреймворк метаданных, необходимый нам для реализации универсальных механизмов, таких как визуальные компоненты, настраивающие свои свойства в зависимости от типа атрибута сущности, который они отображают. На основе метаданных сделали механизм декларативного объявления графов сущностей (мы их называем “представления” — views). Такой механизм нужен для того, чтобы с любого уровня приложения можно было запросить данные и указать, какой объектный граф сейчас требуется, т.е. с какими атрибутами и связанными сущностями мы хотим в данный момент работать.

    Начали работать над security: пользовательская сессия, сами пользователи, роли и права доступа. Поломали голову над тем, как реализовать контроль доступа на уровне строк (row-level security). Остановились на том, что предикаты ограничений должны группироваться в отдельную от ролей иерархическую структуру. Всё управление security, разумеется, сразу делали динамическим в смысле возможности настройки в runtime.

    Сложным был выбор технологии для веб UI. Нам нужно было поверх какого-то фреймворка создать свой слой абстракции для разделения компоновки и кода экранов, а также для реализации набора визуальных компонентов, работающих с сущностями с помощью наших метаданных. Кроме того, мы планировали в будущем сделать реализацию этого же слоя на базе десктопного Swing. В общем, хотелось, чтобы прикладной код не зависел ни от каких технологий, кроме Java и наших собственных. В итоге, для веб клиента выбрали Vaadin (тогда он назывался ITMill). Альтернатив было немного, ну и в любом случае сейчас не жалеем о выборе, так как фреймворк мощный и активно развивается. Хотя набили много шишек, попытаемся о них рассказать в отдельной статье.

    Таким образом у нас появился GenericUI — модуль платформы для создания экранов на XML и Java. Он состоит из загрузчиков экранов, библиотеки визуальных компонентов и источников данных (datasources), связывающих компоненты с моделью данных. Первым, что мы написали на GenericUI, были экраны управления security самой платформы. Ну а потом начали делать первое приложение — это была заказная система документооборота. Надо сказать, что GenericUI позволяет работать в обход себя, напрямую с компонентами нижележащего UI-фреймворка. Поначалу мы этим активно пользовались, так как возможностей GenericUI часто не хватало. Со временем, в результате развития платформы, необходимость в таком “низкоуровневом” кодировании почти отпала, 99% прикладного кода работает только с обобщенными интерфейсами.

    Через некоторое время пришла идея отказаться от JBoss и реализовать всю инфраструктуру на Spring. Замечательная функциональность и расширяемость Spring дала нам возможность реализовать нужные механизмы более просто и надежно. Плюс мы обрели независимость от сервера, а также время старта приложения на Tomcat от 5 до 15 секунд, что в разы быстрее, чем было на JBoss.

    Несмотря на приемлемое время рестарта приложения, иногда необходимо деплоить части приложения на лету, без остановки сервера. Поэтому мы реализовали возможность динамической компиляции и загрузки классов из специального каталога. Более того, cейчас Студия постоянно отслеживает изменения в проекте и подбрасывает в этот каталог исходники UI, что очень помогает при разработке экранов — можно увидеть результат изменений без рестарта, логина, поиска экрана в меню и т.д.

    Настала пора наращивания функциональности — в приложениях нужны были управление бизнес-процессами и полнотекстовый поиск. Раздувать основную часть платформы мы не стали, а разбили ее на несколько проектов, которые используются приложениями при необходимости.

    После Workflow и Full Text Search начали разработку собственного генератора отчетов. До этого использовали JasperReports, но он нас не устраивал, во-первых из-за слишком трудоемкого процесса создания шаблонов, а во-вторых из-за сложностей с выводом результатов в Excel. Реализовали простую идею: отдельно описывать логику извлечения данных, отдельно создавать шаблон в Excel, Word или HTML. Такой подход себя оправдал, и недавно мы даже выделили ядро генератора в отдельный open-source проект под названием YARG для использования вне платформы. Про него обязательно будет статья на Хабре.

    Система сборки довольно долгое время базировалась на Ant-скриптах. Причем, если сторонние библиотеки загружались из репозитория в бинарном виде, то платформа подключалась к прикладному проекту только в виде исходников, напрямую из SVN. Такой подход имел преимущества на этапе становления платформы — любой программист при работе над своим проектом мог легко поправить что-то в платформе и просто закоммитить свои изменения. В определенный момент мы перешли на стандартный вариант, когда бинарные артефакты и исходники платформы загружаются в проект так же, как и остальные зависимости — из Maven-репозитория. Заодно заменили Ant на Gradle, который позволил нам заключить основной код сборки в плагине, а скрипты проектов сделать максимально лаконичными, но при этом произвольно расширяемыми.

    Когда мы начали делать Sherlock — продукт для такси, потребовался десктопный клиент. Тогда и появилась вторая реализация GenericUI-компонентов на Swing. В результате весь UI продукта (более 300 экранов) доступен и в веб и в десктоп вариантах с одинаковой функциональностью, отличия только в отзывчивости интерфейса и нюансах работы с клавиатуры.

    Также для тиражируемых продуктов мы придумали механизм расширений, который позволяет адаптироваться к требованиям заказчиков. Расширение — это, по сути, проект нового приложения, в котором продукт используется как платформа. Таким образом нам удается добиваться максимальной кастомизации под заказчика без изменения кода основного продукта. Сохраняется и возможность обновления версий продукта — для этого достаточно привести расширение в соответствие новой версии и пересобрать его.

    В определенный момент времени появилась идея сделать платформу доступной разработчикам за пределами нашей компании. Два года назад CUBA была взята на вооружение еще двумя ИТ-компаниями, которые сделали на ее основе довольно крупные проекты: систему обработки электронных сообщений граждан Правительства Москвы и федеральный Электронный регистр онкобольных Республики Казахстан. Это окончательно убедило нас в том, что CUBA может быть полезной не только нам, и мы начали подготовку к публичному релизу.

    C этого момента началась работа над Студией, которая позволяет снизить порог входа для начала разработки на платформе и дает возможность более удобно решать рутинные задачи. Мы сделали Студию веб приложением, что дает интересные возможности применения — от теоретической способности работы в облаке до вполне практической возможности быстро подключиться к проекту коллеги и, например, помочь ему разобраться в проблеме. Кроме Студии в помощь разработчику написали плагин к IntelliJ IDEA для навигации по специфическим для CUBA элементам проекта.

    Планы на будущее


    На данный момент CUBA перешла из фазы интенсивного роста и постоянных изменений в более спокойную стадию эволюции. Естественно, в первую очередь это непрерывный процесс различных локальных доработок и устранения дефектов. Кроме того, мы планируем в ближайшее время заняться доделкой модуля отображения диаграмм — там появятся компоненты для отображения карты и интерактивные диаграммы на JavaScript, которые будут управляться, как и все остальные GenericUI-компоненты, из серверного Java-кода. После этого, скорее всего, займемся вопросами деплоймента CUBA-приложений в облаке у PaaS-провайдеров.

    Разумеется, мы открыты для диалога, и направления совершенствования платформы во многом будут определяться пожеланиями разработчиков, ее использующих.

    В отличие от самой платформы, Студия является очень молодым продуктом. В первую очередь мы работаем над повышением удобства использования Студии и стараемся сделать ее более умной и дружелюбной.

    Также много усилий в последнее время прикладываем к улучшению документации. Пока в ней есть пробелы, явно не хватает примеров и рецептов решения типовых задач. Эти недостатки и будем устранять, а в следующем году собираемся выпустить всю документацию на английском.

    На Хабре мы планируем публиковать статьи о различных аспектах устройства платформы и о проблемах, которые нам приходилось решать. Надеюсь, что будет интересно.

    Haulmont

    268,00

    Разработка корпоративного ПО

    Поделиться публикацией

    Похожие публикации

    Комментарии 54
      +3
      Читал и плакал, вспоминая Oracle ADF…
      Его рекламные проспекты, схемы, графики, пламенные речи, декларативность… и то что получилось (да и сейчас получается) в итоге.

      Надеюсь у вас результат лучше.
        0
        а можно поподробнее?
          +3
          Подробно получится книга листов на 900 )

          Но в целом, декларативность, которая очень круто выглядит на демонстрациях и в туториалах (все эти тонны XML), в реальном, боле менее крупном проекте превращается просто в ад и содомию.
          Как притянутый за уши пример (очень притянутый), если надо на 30 формах исправить элемент какой-то, с определенными параметрами.
          Надо 30 раз прокликать мышкой все параметры, на всех страницах. Что бы во всех нужных XML, среда разработки проставила все нужные параметры.
          Тут конечно можно возразить, что все это из кода можно сделать, там есть наследование и прочие ништяки. Ты начинаешь это делать и радоваться, что не приходится развивать скилл мышекликания…
          И в какой-то момент отчетливо понимаешь, что ты все равно все делаешь кодом и смысл во всех этих «чего-то улучшающих» прослойках как-то ускользает от тебя. Но при этом ты вынужден пользоваться этими прослойками, потому что переписать проект уже нереально, все завязано на эти костыли. Я уже не говорю, что все эти прослойки просто адово жрут ресурсы.

          Я реально не понимаю, зачем тот же vaadin еще чем-то оборачивать. Зачем строить абстракции над абстракциями над абстракциями?
          Любой адекватный разработчик, хоть раз окунувшись в большой проект с «рисованием» кода через XML, расскажет какой это ад.
          Я уже не говорю про банальности вроде дебага, когда пара строк на XML делает непонятно что и непонятно где, без какой либо отладочной информации и приходится разбирать буквально гадая и перебирая варианты. Или выдавая офигенно информативные сообщения вида «в жизненном цикле граней появились исключения».
          Добавьте сюда еще и такие моменты, JDeveloper (а только в нем можно разрабатывать на ADF), сам по себе ужаснейшая поделка.
          Версия JDev намертво прибита деревянными гвоздями к версии ADF. А это значит, что в 99% случаях вам придется работать в древнейшей IDE в которой функционала меньше чем в notepad.

          Если уж касаться указанных в статье технологий, связка вроде Hibernate (подставить ORM по вкусу, хоть JDBC голый) + Scala/Java/Groovy + AppServer (по вкусу), позволяет вполне себе быстро разрабатывать, а самое главное хоть как-то контролировать приложение. Менять компоненты, при возникновении проблем и т.д.
          Все эти разговоры, про «написал интерфейс на XML и оно работает везде», это красивый маркетинг. Ну написали вы пару формочек, ну запустилось оно на десктопе и в браузере. А потом, через какое-то время, вдруг обнаруживается, что юзкейсы то разные, что работа в приложении и в браузере отличается и по хорошему надо это как-то разруливать… или «на десктопе работает, а в браузере, только в IE или FireFox что-то не так», и начинается ад. Простые вещи начинают отнимать непозволительное количество времени. И вся экономия на «один XML для всего» очень быстро теряется и начинает отжирать время (как основной ресурс) просто в страшных количествах. Тут как правило все уже начинают понимать, к чему приводит экономия там где не надо, но уже не в силах отказаться от сделанного, слишком много ресурсов вложено в доведение этих костылей до ума. а руководство, как правило, не умеет признавать свои ошибки и отказываться от расточительных проектов… ежики плакали, кололись, но продолжали жрать кактус.
            0
            Ничего не могу сказать по поводу ADF, в любом случае у нас совсем другой подход.

            А вот по поводу XML выскажусь. На наш взгляд отделение компоновки экранов от логики — это совершенно необходимая вещь в больших проектах. Писать кучу сложных экранов на чистом Vaadin или Swing — это кошмар, мы через это прошли. Посмотрите примеры кода создания экранов на сайте Vaadin — это сотни строк кода, даже для простых экранов — создать все компоненты, задать им свойства, разложить по контейнерам. Нет, спасибо. Сопровождать это потом очень трудно, мы реально делали это на Swing раньше.

            Применять или не применять визуальные инструменты типа нашей Студии — это по желанию. Но layout в XML — для нас это однозначно.

            Что касаемо работоспособности одновременно веб и десктоп — можем интересующимся приватно показать живое демо Sherlock — системы для такси. Это не туториал. И код этих экранов можем показать.
              0
              Я тоже много писал на Swing раньше, сейчас на Vaadin.
              Возможно у нас с вами разный подход к разработке, ибо у меня нет «сотни строк кода, даже для простых экранов».

              >Применять или не применять визуальные инструменты типа нашей Студии — это по желанию.
              Вот это хороший подход, правильный.

              >Что касаемо работоспособности одновременно веб и десктоп…
              Я не сомневаюсь, что можно сделать генерацию различных клиентов через XML. Я просто знаю, ибо видел не раз, чего в итоге стоит такое решение в больших проектах. И не верю что может получится серебряная пуля.
              Логика очень простая, когда я выбираю vaadin, я попадаю в зависимость от них и их решений по развитию.
              Когда выбираю решения типа вашего, я попадаю в зависимость от двух вендоров сразу, и их взаимодействия. Т.е. в случае проблем, головняка будет даже не в 2 раза, а больше…
              А профит от первоначального ускорения создания форм, очень быстро нивелируется разборками с глюками системы уйдя в «минус».
                0
                > Я тоже много писал на Swing раньше, сейчас на Vaadin.
                >Возможно у нас с вами разный подход к разработке, ибо у меня нет «сотни строк кода, даже для простых экранов».

                Очевидно, вы создали для себя свой собственный слой абстракции :)

                > А профит от первоначального ускорения создания форм, очень быстро нивелируется разборками с глюками системы уйдя в «минус».

                Это ваш опыт. У нас он другой, повторяю про наличие реальных больших проектов, в том числе и с веб/десктоп интерфейсом. Уверен, что существует множество условий, при которых применение нашего подхода с экранами в XML более оправданно. Разумеется, ваша точка зрения также оправданна во многих случаях.
                  0
                  Очевидно, вы создали для себя свой собственный слой абстракции :)

                  Выше была упомянута Scala. Удивительно насколько код на Scala более компактный. Вот, например, стандартный листенер нажатия кнопки вообще без полезной нагрузки на Java:

                          button.addClickListener(new Button.ClickListener() {
                              private static final long serialVersionUID = 1L;
                  
                              @Override
                              public void buttonClick(ClickEvent event) {
                                  // ...
                              }
                          });
                  


                  А вот листенер аж сразу нескольких событий на Scala:

                    dashboard.addListener(newListener {
                        case event: LoginEvent => // ...
                        case event: LogoutEvent => // ...
                    })
                  


                  То же самое и с дизайном UI. Дизайнить UI на ScalaSwing намного приятнее чем на Java Swing. К Vaadin, конечно, пришлось написать немного функций-хелперов, но они именно хелперы, а не отдельный слой абстракции.
                    0
                    Безусловно на Scala можно писать более лаконично, и это здорово.

                    Но мы предпочитаем пока использовать Java как более простой «мэйнстрим» язык. Проще найти кадры и организовать работу в команде.
                0
                >Но layout в XML — для нас это однозначно.

                А почему именно в XML, что мешает сделать слой абстракции в коде? Почему джависты чуть что хватаются делать DSL поверх XML?
                  0
                  Хороший вопрос.
                  По следующим причинам:
                  1. XML хорошо читается, особенно когда теги семантические, т.е. <textField id="myField"/> а не <component class="com.lalala.TextField" id="myField">. Под «хорошо читается» я имею в виду то, что когда вы открываете исходник такого экрана, то при некотором навыке понимаете как он будет выглядеть в работе, без всяких визуализирующих Студий.
                  2. XML с семантическими тегами легко писать руками, IDE подсказывает вам возможные теги и атрибуты по XSD (а она у нас разумеется есть).
                  3. XML легко генерить сторонними инструментами типа плагина к IDE или Студии.
                    0
                    Не могу согласиться что XML так уж хорош. Читается, редактируется он, как по мне, отвратительно, а генерируется он не удобнее всяких остальных JSON-ов.

                    Но вообще я имел ввиду не XML vs JSON vs что-угодно, а eDSL vs XML. Т.е. почему у вас именно XML, почему нельзя сделать чтобы layout-ы можно делать удобно прямо в коде? Даже не смотря на то, что в Java нет человеческих литералов, все равно можно обложиться хелперами и всякими fluent-интерфейсами, и делать все может и немного многословнее, но зато — как минимум гораздо гибче.

                    В коде я могу делать что-то типа:
                    if (user.allowedToEditThis && entity.Status != Status.Closed) {
                    layout.add(new TextField(....))
                    }
                    Как я такое буду делать в XML?
                      0
                      > Не могу согласиться что XML так уж хорош. Читается, редактируется он, как по мне, отвратительно, а генерируется он не удобнее всяких остальных JSON-ов.

                      Это дело вкуса. Как минимум XML привычнее, его знают все. И я не уверен, что для JSON существует сравнимое с XSD по возможностям решение, и с соответствующей поддержкой от IDE.

                      > В коде я могу делать что-то типа:

                      Мы тоже делаем это в коде :)
                      В XML только статический layout, и кроме прочего может быть объявлен пустой контейнер, ссылку на который вы по ID получаете в Java-контроллере, создаете компоненты и кладете в контейнер.
                      Другое дело, что это приходится делать нечасто, так как компоненты, связанные с данными автоматически скрываются или делаются read-only, если например атрибут, который они отображают, запрещен данному пользователю по security. А вот чтобы учесть Status из вашего примера, действительно придется написать примерно такой же код.
                        0
                        Я сам делаю опердени (т.е. приложения из форм и таблиц), в том числе на вебе. И мой опыт показывает что на большинстве будут требоваться всякие хитрые штуки, типа этого Status-а.

                        Взять какую-нибудь банальную форму Order/Order Lines. Там 100% будет нужна сумма заказа, там стопудово нужно будет отключать кучу кнопок если OrderLines пустые, наверняка будет какой-нибудь поиск дубликатов customer-ов, и еще пара дюжин подобных фичей.

                        И я вот смотрю на такую форму, на похожем фреймворке сделанную:
                        demos.devexpress.com/XAF/XCRM/Default.aspx#ShortcutViewID=ICRMOrder_DetailView&ShortcutObjectKey=c05e4827-9e6f-4c41-81c2-60dfff642837&ShortcutObjectClassName=XCRM.Module.ICRMOrder&Shortcutmode=Edit

                        Да, все работает. Но, например добавление строки заказа — неудобно на грани полной неюзабельности. Или например в строке заказа нельзя поправить количество заказанного не заходя в попап-меню. Короче всю эту форму на практике нужно будет перепахать, чтобы с ней реальные люди могли работать. Перепахать так, что там обычных бесхитростных полей будет максимум половина. После чего будет непонятно совсем зачем половину полей держать в XML.

                        Для оперденей безусловно надо фреймворки. Но идея «замеппим поля таблиц на контролы, контролы разложим в XML-ке» — на практике не очень работает. Вся эта сначала удобная декларативщина, неминуемо скатывается в императивный код поверх событий и загадочных чужих API. Который повсеместно ломает всякие горизонтальные штуки, типа секьюрити или какого-нибудь optimistic concurency.

                        Короче моя точка зрения в том, что если уж делать декларативное, нужно что-то сильно хитрее.
                          0
                          Первый раз слышу такое слово — опердень.

                          По сути вашего комментария. Конечно странно тут обсуждать фреймворк, который к нам не имеет никакого отношения и я его не использовал. Но форма, которая открывается по вашей ссылке, действительно довольно типичная, и я возьмусь прокомментировать.

                          > Там 100% будет нужна сумма заказа

                          В чем проблема? Делаете поле и связываете с атрибутом AMOUNT сущности.

                          > там стопудово нужно будет отключать кучу кнопок если OrderLines пустые

                          В CUBA есть «стандартные actions», которые отслеживают, что какая-нибудь строка таблицы выбрана. Если не выбрана, кнопки недоступны (например «Edit»).

                          > наверняка будет какой-нибудь поиск дубликатов customer-ов

                          Да, чтобы это отслеживать на этапе ввода, а не после коммита формы, нужно написать метод сервиса на среднем слое и вызывать например его в листенере изменения таблицы (это грубо, там несколько разных типов листенеров).

                          > в строке заказа нельзя поправить количество заказанного не заходя в попап-меню

                          В CUBA есть «редактируемые таблицы», когда вы объявляете какую-то колонку редактируемой и можно вводить в нее значения не открывая дополнительных окон.

                          > идея «замеппим поля таблиц на контролы, контролы разложим в XML-ке»

                          У нас несколько сложнее — контролы мапятся на графы сущностей, извлекаемые со среднего слоя в datasources экрана. Возможно, это частично помогает нам не ломать «горизонтальные» механизмы специфическим кодом.
                            +1
                            Опердень — это сокращение от «операционный день банка». Это такой класс банковских приложений, которые состоят из форм и таблиц чуть более чем полностью. Название прижилось в определенных кругах как нарицательное название всех бизнес-приложений из таблиц и форм.

                            >У нас несколько сложнее — контролы мапятся на графы сущностей, извлекаемые со среднего слоя в datasources экрана. Возможно, это частично помогает нам не ломать «горизонтальные» механизмы специфическим кодом.

                            Т.е. у вас контролы и их логика работают поверх каких-то viewmodel, которые туда-сюда мэппятся в модель, а дальше в базу? Это действительно хороший шаг и спасет от многих проблем. А есть где почитать именно про этот момент?
                              0
                              У нас иногда всплывает определение наших английских коллег — «system of records». Тоже довольно точно передает тот класс приложений, который вы описали. Именно формы и таблицы. Плюс отчеты, иногда карты и графики. И все.

                              Про наши источники данных (datasources) можно почитать здесь. К сожалению, пока информация там сухая и мало примеров, но представление получить можно.
                                0
                                Почитал, но не очень понял вот что: как я понимаю viewmodel у вас представлена классом с определенными интерфейсами, а класс как я понимаю живет на сервере. Как тогда вводить поведение на клиенте (типа того же подсчета суммы order lines)?
                                  0
                                  У фреймворка Vaadin всё поведeние на сервере, если вы в терминах Клиент=Браузер. Если вы в терминах Сервер=Средний слой, то модель живёт на веб-клиенте вместе с поведением (классом контроллера).
                                    0
                                    Да, это набор Java-итерфейсов и их релизаций. Чтобы разобраться с тем, что мы называем клиентом, посмотрите пожалуйста на эту диаграмму.

                                    Код datasources (как и всего фреймворка GenericUI) физически располагается в случае веб-клиента на веб-сервере, а в случае десктоп клиента на машине пользователя. Не забывайте, что для веб-клиента мы используем Vaadin, который дает нам возможность писать только server-side.
                    0
                    интерестно посмотреть
                      0
                      Напишите нам, пожалуйста, на info@cuba-platform.com. Мы организуем для вас вход на тестовый сервер, оттуда же можно будет запустить и десктоп-клиента через Java Web Start.
                    0
                    Ну, абстракции какие-то в любом случае будут. И декларативщина — тоже, в каком-то объеме. И если она удачная — почему бы и нет?

                    Хотя я вот тоже натерпелся XML-DSL-ей с мета-конфигурациями мета-данных о мета-layout-ами, со своими XML-условными операторами, циклами и наследованием. Так что для меня фраза «конфигурируется в XML» — это звоночек :)
                      0
                      Все хорошо в меру.
                      Чтобы успокоить уважаемых читателей, скажу, что в CUBA нигде нет XML-условных операторов и циклов. Для этого есть контроллеры на Java. А вот наследование XML-компоновки экранов есть, оно очень помогает в расширениях (адаптациях для заказчиков) продуктов переопределять компоновку базовых экранов.
                    0
                    Что бы было понятнее, посмотрите на скрин системы из статьи
                    Пример с сайта разработчиков CUBA
                    Обратите внимание на кнопки выбора/очистки у полей слева.
                    Борьба с таки глюками, а они могут быть гораздо серьезнее, отнимает просто адовое количество времени.
                    Если вообще будет техническая возможность исправить это…
                      0
                      Это обычная проблема В CSS теме конкретного проекта, ничего более.
                        0
                        Ну в данном конкретно случае, возможно вы и правы.
                        Но речь идет не о конкретной какой-то ошибке. А о том, что появляется еще одна прослойка абстракция над другими абстракциями. Которая добавляет проблем, которые неизвестно где аукнутся.
                          0
                          Данный конкретный случай — это лень разработчиков (это не наш проект, наших партнеров) и апатия пользователей. Ну и разумеется наш косяк, что мы опубликовали такой скриншот. Правда теперь после вашего комментария как-то и неудобно его убирать…

                          По поводу прослоек — вы правы, это еще одна абстракция. Но, как известно, абстракция — неплохой, если не единственный способ борьбы со сложностью. Добавлять или не добавлять этот слой поверх упомянутых вами фрейморков — это выбор разработчиков, и мы считаем что для большого класса проектов эта абстракция дает больше плюсов чем минусов.
                  0
                  Посмотрел видео работы с системой: http://vimeo.com/77210510

                  Выглядит с одной стороны логично, с другой — довольно запутанно: постоянно надо нажимать кучу разных элементов интерфейса. Я, как разработчик, наверно бы в итоге сбежал от этой «интерфейсной магии». :)

                  Но, наверняка, многим заказчикам нравится возможность клепать всё из UI.
                    0
                    Видео о приложении Студия, чтобы можно было быстро начать. Программисты хорошо работают и без неё, поскольку есть хороший плагин для IntelliJ Idea (плагин именно для программистов, без «интерфейсной магии»).
                      0
                      По поводу запутанно, XAF видели? Вот уж где царство Шеогората, так это там.
                      Кстати хотелось бы знать, krivopustov, в каких условиях записывалось видео? (примерная конфигурация железа).
                        0
                        Записывала наша сотрудница на обычном ноуте Asus N56VZ, 6G RAM, микрофон Audio-Technica AT2020 USB, софт — Camtasia Studio 7.1.
                      0
                      Студия в начале полезна тем, что можно покликать мышкой, посмотреть что получается в проекте — какие файлы где создаются, где что регистрируется. Потом постепенно можно то же самое делать просто в IDE. И плагин для IDEA на самом деле не обязателен, весь код проекта — это Java плюс XML для компоновки экранов и нескольких конфигов.

                      Да и даже когда все знаешь досконально изнутри, для многих задач такой визуальный интерфейс удобнее, чем код править.
                        0
                        Про шишки с Vaadin интересно, напишите пожалуйста. Я сейчас сам пишу проект на Vaadin и Scala и тоже набиваю шишки.
                          0
                          У нас много своих компонентов на Vaadin и многое из API Vaadin (особенно то, что они не хотят чинить) исправлено в форке, идущем параллельно их ветке 7.1. Регулярно постим им баги и сабмитим патчи в Gerrit (иногда они их принимают). Опыт в Vaadin копим ещё со времён IT Mill, когда ещё никакого Vaadin Ltd то не было. Подробный пост про Vaadin и причуды обязательно будет.
                            0
                            Я тут зафорчу тред немного ) Подскажите, пожалуйста, вы наталкивались, а, быть может и исправили этот баг у себя? dev.vaadin.com/ticket/13034. Сколько ни имел дела с Vaadin сообществом, ответов не добивался.
                              0
                              Да, такая проблема есть, это их баг с автоматической высотой в окнах. Можно вопроизвести даже положив в окно вертикальный бокс с кучей длинных надписей gist.github.com/jreznot/7823647. Мы решаем проблемы со скроллингом явным использованием панели со скроллингом (и указываем режим скроллбаров — вертикальный/горизонтальный/оба), в которую кладём то, что может не умещаться.
                          0
                          Авторы черпали вдохновение с платформы 1C.Enterprise?
                            0
                            В какой-то степени да. Специально мы ее не изучали, и никто из разработчиков CUBA с 1С непосредственно не работал, но основные плюсы и минусы знаем. И хотим приблизиться к ней в простоте освоения и решения бизнес-задач. При этом не потеряв в открытости, масштабируемости и широте решаемых задач.
                              0
                              По видео все очень похоже, и перспектива вашего продукта в виду открытости видится более чем прекрасной.
                            0
                            Как-то с названием не супер.
                              0
                              А что не так с названием? :) Дело вкуса конечно. У нас исторически сложилось так, что внутренние проекты имеют географические названия. Кроме Cuba, есть Chili, Bali например.
                                0
                                То есть Chile конечно
                              0
                              лучше бы что-то типа v8.1c.ru/metod/videotutorial/000000022.html выложили — сразу стало бы понятно про то, какая это «платформа»
                                0
                                Пожалуйста. На сайте все есть:
                                www.cuba-platform.com/ru/quickstart
                                  0
                                  ну, «создание связной сущности» и «микроучетная система ремонтов» — все-таки разные по уровню вещи.
                                    0
                                    Согласен. У нас немного другой подход, мы стараемся длинные ролики не делать.
                                    Вместо этого делаем отдельные по разным темам, мне кажется это удобнее.
                                    Часть уже есть здесь: www.cuba-platform.com/ru/tutorials
                                    Сейчас здесь в основном обзорные ролики по некоторым компонентам платформы, постепенно будем добавлять ролики непосредственно по процессу разработки. Все желаемое сразу к сожалению сделать не получается, так как это достаточно трудоемкий процесс.
                                0
                                Выглядит интересно. Но основная проблема с подобными технологиями — нельзя просто взять и соскочить. Получается замкнутый круг: чтобы начать разбираться в какой-то технологии, нужно потратить на нее пару лет. А потратив, сложно перейти на что-то другое в случае косяков.
                                  0
                                  Согласен, соскочить сложно.
                                  Но так же сложно соскочить например с Vaadin или Swing, хотя это и более низкоуровневые вещи. Или попробуйте соскочить с Oracle Database, если вы написали на нем кучу логики в PL/SQL.

                                  Вообще так называемая независимость от вендора, которую пропагандируют разработчики стандартов — в большой степени красивая сказка. Как только вам нужно сделать что-то большое и серьезное, придется использовать всякие проприетарные расширения. Иногда обновить версию используемого фреймворка в работающей системе сложно, не то что сменить поставщика.

                                  Мы работаем над тем, чтобы на освоение CUBA не надо было тратить пару лет. Соответственно соскочить будет проще — меньше сожалений.
                                    0
                                    Согласен. Поэтому я и предпочитаю работать с Core Java + совсем уже монстрами типа Spring, с которых соскакивать не придется — все их используют. Но это все же немного другая область.
                                      0
                                      > Иногда обновить версию используемого фреймворка в работающей системе сложно, не то что сменить поставщика.

                                      Это вы, должно быть, про миграцию с шестого Ваадина на седьмой с ловлей кучи лулзов в стиле нескролящихся и прыгающих окон? =)
                                        0
                                        Вы почти угадали. Переход с Vaadin 6 на 7 нам дорого дался. Но в основном по другой причине: в Vaadin 7 любимый многими браузер IE8 стал отрисовывать некоторые наши экраны на порядок (в 10 и более раз) медленнее. Как мы решили эту проблему — тема отдельная.
                                        0
                                        Или попробуйте соскочить с Oracle Database, если вы написали на нем кучу логики в PL/SQL.

                                        а зачем соскакивать с  PL/SQL? разве нельзя просто его вызывать из CUBA?
                                          0
                                          Или попробуйте соскочить с Oracle Database, если вы написали на нем кучу логики в PL/SQL.

                                          Речь идёт о сферическом глубоком использовании именно возможностей PL/SQL Oracle в сферическом проекте.
                                            0
                                            Разумеется, вызывать можно. CUBA никак не ограничивает возможности обращения к БД через JDBC или ORM native queries.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое