Однако спасибо за идею, возможно мы сделаем удобную обертку для такой операции.
На всякий случай отмечу, что это будет работать только для managed-экземпляра, для которого уже выполнен merge. В detached-экземплярах старых значений нет, там только список номеров измененных полей. И значений там быть не должно, иначе будет дополнительная нагрузка на память и на сериализацию, в то время как нужны эти старые значения в 0.1% случаев.
Ну а в этом приложении я просто захожу в основной UI с компа, смотрю отчет, иногда создаю новый счет или категорию. Вносить операции и видеть баланс можно с мобильного UI.
Лицензией ограничивается количество одновременных «пользовательских сессий». Сессии создается при логине пользователей-людей, а также могут создаваться для работы асинхронных процессов. Например запускаете механизм выполнения задач по расписанию — одна сессия создается шедулером. Можно все таски запускать от одного пользователя, тогда они будут пользоваться той же сессией. Иногда удобно каждой таске дать своего пользователя, тогда они будут создавать дополнительные сессии.
В этом приложении никаких асинхронных процессов пока нет. Можете зайти в Administration -> User Sessions — увидите одну свою сессию.
Основной UI — предоставляет все функции приложения. Быстро пишется на XML+Java, можно использовать WYSIWYG-редактор экранов Студии. Рендерится для веб с помощью Vaadin, для десктоп с помощью Swing. Веб работает на всех устройствах, но, во-первых, тыкать в него пальцами неудобно, а во-вторых он non-responsive, т.е. не умеет меняться в зависимости от размеров экрана.
Поэтому сделан второй UI на чистом JavaScript+Bootstrap. Через него не все можно сделать, зато удобно пользоваться на мобилках. Трудозатраты на него конечно на порядок выше чем на основной UI.
Визуальная разница надеюсь понятна из скриншотов в начале статьи.
Этот подход используется нами во многих коммерческих приложениях — основной полнофункциональный UI для сотрудников предприятия, пользующихся системой, а на классических веб-технологиях красивые веб-сайты для внешних пользователей.
Собственно, сам проект вполне open-source — используйте и модифицируйте как хотите. Платформа с открытыми исходниками, но с несвободной лицензией, ограничивающей количество одновременно работающих в приложении пользователей (5 бесплатно).
А вообще систему учета персональных финансов думаю и полностью свободную можно найти.
Напишите нам, пожалуйста, на info@cuba-platform.com. Мы организуем для вас вход на тестовый сервер, оттуда же можно будет запустить и десктоп-клиента через Java Web Start.
Вы почти угадали. Переход с Vaadin 6 на 7 нам дорого дался. Но в основном по другой причине: в Vaadin 7 любимый многими браузер IE8 стал отрисовывать некоторые наши экраны на порядок (в 10 и более раз) медленнее. Как мы решили эту проблему — тема отдельная.
Да, это набор Java-итерфейсов и их релизаций. Чтобы разобраться с тем, что мы называем клиентом, посмотрите пожалуйста на эту диаграмму.
Код datasources (как и всего фреймворка GenericUI) физически располагается в случае веб-клиента на веб-сервере, а в случае десктоп клиента на машине пользователя. Не забывайте, что для веб-клиента мы используем Vaadin, который дает нам возможность писать только server-side.
У нас иногда всплывает определение наших английских коллег — «system of records». Тоже довольно точно передает тот класс приложений, который вы описали. Именно формы и таблицы. Плюс отчеты, иногда карты и графики. И все.
Про наши источники данных (datasources) можно почитать здесь. К сожалению, пока информация там сухая и мало примеров, но представление получить можно.
Согласен, соскочить сложно.
Но так же сложно соскочить например с Vaadin или Swing, хотя это и более низкоуровневые вещи. Или попробуйте соскочить с Oracle Database, если вы написали на нем кучу логики в PL/SQL.
Вообще так называемая независимость от вендора, которую пропагандируют разработчики стандартов — в большой степени красивая сказка. Как только вам нужно сделать что-то большое и серьезное, придется использовать всякие проприетарные расширения. Иногда обновить версию используемого фреймворка в работающей системе сложно, не то что сменить поставщика.
Мы работаем над тем, чтобы на освоение CUBA не надо было тратить пару лет. Соответственно соскочить будет проще — меньше сожалений.
По сути вашего комментария. Конечно странно тут обсуждать фреймворк, который к нам не имеет никакого отношения и я его не использовал. Но форма, которая открывается по вашей ссылке, действительно довольно типичная, и я возьмусь прокомментировать.
> Там 100% будет нужна сумма заказа
В чем проблема? Делаете поле и связываете с атрибутом AMOUNT сущности.
> там стопудово нужно будет отключать кучу кнопок если OrderLines пустые
В CUBA есть «стандартные actions», которые отслеживают, что какая-нибудь строка таблицы выбрана. Если не выбрана, кнопки недоступны (например «Edit»).
> наверняка будет какой-нибудь поиск дубликатов customer-ов
Да, чтобы это отслеживать на этапе ввода, а не после коммита формы, нужно написать метод сервиса на среднем слое и вызывать например его в листенере изменения таблицы (это грубо, там несколько разных типов листенеров).
> в строке заказа нельзя поправить количество заказанного не заходя в попап-меню
В CUBA есть «редактируемые таблицы», когда вы объявляете какую-то колонку редактируемой и можно вводить в нее значения не открывая дополнительных окон.
> идея «замеппим поля таблиц на контролы, контролы разложим в XML-ке»
У нас несколько сложнее — контролы мапятся на графы сущностей, извлекаемые со среднего слоя в datasources экрана. Возможно, это частично помогает нам не ломать «горизонтальные» механизмы специфическим кодом.
> Не могу согласиться что XML так уж хорош. Читается, редактируется он, как по мне, отвратительно, а генерируется он не удобнее всяких остальных JSON-ов.
Это дело вкуса. Как минимум XML привычнее, его знают все. И я не уверен, что для JSON существует сравнимое с XSD по возможностям решение, и с соответствующей поддержкой от IDE.
> В коде я могу делать что-то типа:
Мы тоже делаем это в коде :)
В XML только статический layout, и кроме прочего может быть объявлен пустой контейнер, ссылку на который вы по ID получаете в Java-контроллере, создаете компоненты и кладете в контейнер.
Другое дело, что это приходится делать нечасто, так как компоненты, связанные с данными автоматически скрываются или делаются read-only, если например атрибут, который они отображают, запрещен данному пользователю по security. А вот чтобы учесть Status из вашего примера, действительно придется написать примерно такой же код.
Все хорошо в меру.
Чтобы успокоить уважаемых читателей, скажу, что в CUBA нигде нет XML-условных операторов и циклов. Для этого есть контроллеры на Java. А вот наследование XML-компоновки экранов есть, оно очень помогает в расширениях (адаптациях для заказчиков) продуктов переопределять компоновку базовых экранов.
Хороший вопрос.
По следующим причинам:
1. XML хорошо читается, особенно когда теги семантические, т.е. <textField id="myField"/> а не <component class="com.lalala.TextField" id="myField">. Под «хорошо читается» я имею в виду то, что когда вы открываете исходник такого экрана, то при некотором навыке понимаете как он будет выглядеть в работе, без всяких визуализирующих Студий.
2. XML с семантическими тегами легко писать руками, IDE подсказывает вам возможные теги и атрибуты по XSD (а она у нас разумеется есть).
3. XML легко генерить сторонними инструментами типа плагина к IDE или Студии.
> Я тоже много писал на Swing раньше, сейчас на Vaadin.
>Возможно у нас с вами разный подход к разработке, ибо у меня нет «сотни строк кода, даже для простых экранов».
Очевидно, вы создали для себя свой собственный слой абстракции :)
> А профит от первоначального ускорения создания форм, очень быстро нивелируется разборками с глюками системы уйдя в «минус».
Это ваш опыт. У нас он другой, повторяю про наличие реальных больших проектов, в том числе и с веб/десктоп интерфейсом. Уверен, что существует множество условий, при которых применение нашего подхода с экранами в XML более оправданно. Разумеется, ваша точка зрения также оправданна во многих случаях.
Данный конкретный случай — это лень разработчиков (это не наш проект, наших партнеров) и апатия пользователей. Ну и разумеется наш косяк, что мы опубликовали такой скриншот. Правда теперь после вашего комментария как-то и неудобно его убирать…
По поводу прослоек — вы правы, это еще одна абстракция. Но, как известно, абстракция — неплохой, если не единственный способ борьбы со сложностью. Добавлять или не добавлять этот слой поверх упомянутых вами фрейморков — это выбор разработчиков, и мы считаем что для большого класса проектов эта абстракция дает больше плюсов чем минусов.
Ничего не могу сказать по поводу ADF, в любом случае у нас совсем другой подход.
А вот по поводу XML выскажусь. На наш взгляд отделение компоновки экранов от логики — это совершенно необходимая вещь в больших проектах. Писать кучу сложных экранов на чистом Vaadin или Swing — это кошмар, мы через это прошли. Посмотрите примеры кода создания экранов на сайте Vaadin — это сотни строк кода, даже для простых экранов — создать все компоненты, задать им свойства, разложить по контейнерам. Нет, спасибо. Сопровождать это потом очень трудно, мы реально делали это на Swing раньше.
Применять или не применять визуальные инструменты типа нашей Студии — это по желанию. Но layout в XML — для нас это однозначно.
Что касаемо работоспособности одновременно веб и десктоп — можем интересующимся приватно показать живое демо Sherlock — системы для такси. Это не туториал. И код этих экранов можем показать.
Однако спасибо за идею, возможно мы сделаем удобную обертку для такой операции.
На всякий случай отмечу, что это будет работать только для managed-экземпляра, для которого уже выполнен merge. В detached-экземплярах старых значений нет, там только список номеров измененных полей. И значений там быть не должно, иначе будет дополнительная нагрузка на память и на сериализацию, в то время как нужны эти старые значения в 0.1% случаев.
Ну а в этом приложении я просто захожу в основной UI с компа, смотрю отчет, иногда создаю новый счет или категорию. Вносить операции и видеть баланс можно с мобильного UI.
В этом приложении никаких асинхронных процессов пока нет. Можете зайти в Administration -> User Sessions — увидите одну свою сессию.
Поэтому сделан второй UI на чистом JavaScript+Bootstrap. Через него не все можно сделать, зато удобно пользоваться на мобилках. Трудозатраты на него конечно на порядок выше чем на основной UI.
Визуальная разница надеюсь понятна из скриншотов в начале статьи.
Этот подход используется нами во многих коммерческих приложениях — основной полнофункциональный UI для сотрудников предприятия, пользующихся системой, а на классических веб-технологиях красивые веб-сайты для внешних пользователей.
А вообще систему учета персональных финансов думаю и полностью свободную можно найти.
Но мы предпочитаем пока использовать Java как более простой «мэйнстрим» язык. Проще найти кадры и организовать работу в команде.
Код datasources (как и всего фреймворка GenericUI) физически располагается в случае веб-клиента на веб-сервере, а в случае десктоп клиента на машине пользователя. Не забывайте, что для веб-клиента мы используем Vaadin, который дает нам возможность писать только server-side.
Про наши источники данных (datasources) можно почитать здесь. К сожалению, пока информация там сухая и мало примеров, но представление получить можно.
Но так же сложно соскочить например с Vaadin или Swing, хотя это и более низкоуровневые вещи. Или попробуйте соскочить с Oracle Database, если вы написали на нем кучу логики в PL/SQL.
Вообще так называемая независимость от вендора, которую пропагандируют разработчики стандартов — в большой степени красивая сказка. Как только вам нужно сделать что-то большое и серьезное, придется использовать всякие проприетарные расширения. Иногда обновить версию используемого фреймворка в работающей системе сложно, не то что сменить поставщика.
Мы работаем над тем, чтобы на освоение CUBA не надо было тратить пару лет. Соответственно соскочить будет проще — меньше сожалений.
По сути вашего комментария. Конечно странно тут обсуждать фреймворк, который к нам не имеет никакого отношения и я его не использовал. Но форма, которая открывается по вашей ссылке, действительно довольно типичная, и я возьмусь прокомментировать.
> Там 100% будет нужна сумма заказа
В чем проблема? Делаете поле и связываете с атрибутом AMOUNT сущности.
> там стопудово нужно будет отключать кучу кнопок если OrderLines пустые
В CUBA есть «стандартные actions», которые отслеживают, что какая-нибудь строка таблицы выбрана. Если не выбрана, кнопки недоступны (например «Edit»).
> наверняка будет какой-нибудь поиск дубликатов customer-ов
Да, чтобы это отслеживать на этапе ввода, а не после коммита формы, нужно написать метод сервиса на среднем слое и вызывать например его в листенере изменения таблицы (это грубо, там несколько разных типов листенеров).
> в строке заказа нельзя поправить количество заказанного не заходя в попап-меню
В CUBA есть «редактируемые таблицы», когда вы объявляете какую-то колонку редактируемой и можно вводить в нее значения не открывая дополнительных окон.
> идея «замеппим поля таблиц на контролы, контролы разложим в XML-ке»
У нас несколько сложнее — контролы мапятся на графы сущностей, извлекаемые со среднего слоя в datasources экрана. Возможно, это частично помогает нам не ломать «горизонтальные» механизмы специфическим кодом.
Это дело вкуса. Как минимум XML привычнее, его знают все. И я не уверен, что для JSON существует сравнимое с XSD по возможностям решение, и с соответствующей поддержкой от IDE.
> В коде я могу делать что-то типа:
Мы тоже делаем это в коде :)
В XML только статический layout, и кроме прочего может быть объявлен пустой контейнер, ссылку на который вы по ID получаете в Java-контроллере, создаете компоненты и кладете в контейнер.
Другое дело, что это приходится делать нечасто, так как компоненты, связанные с данными автоматически скрываются или делаются read-only, если например атрибут, который они отображают, запрещен данному пользователю по security. А вот чтобы учесть Status из вашего примера, действительно придется написать примерно такой же код.
Чтобы успокоить уважаемых читателей, скажу, что в CUBA нигде нет XML-условных операторов и циклов. Для этого есть контроллеры на Java. А вот наследование XML-компоновки экранов есть, оно очень помогает в расширениях (адаптациях для заказчиков) продуктов переопределять компоновку базовых экранов.
По следующим причинам:
1. XML хорошо читается, особенно когда теги семантические, т.е.
<textField id="myField"/>а не<component class="com.lalala.TextField" id="myField">. Под «хорошо читается» я имею в виду то, что когда вы открываете исходник такого экрана, то при некотором навыке понимаете как он будет выглядеть в работе, без всяких визуализирующих Студий.2. XML с семантическими тегами легко писать руками, IDE подсказывает вам возможные теги и атрибуты по XSD (а она у нас разумеется есть).
3. XML легко генерить сторонними инструментами типа плагина к IDE или Студии.
>Возможно у нас с вами разный подход к разработке, ибо у меня нет «сотни строк кода, даже для простых экранов».
Очевидно, вы создали для себя свой собственный слой абстракции :)
> А профит от первоначального ускорения создания форм, очень быстро нивелируется разборками с глюками системы уйдя в «минус».
Это ваш опыт. У нас он другой, повторяю про наличие реальных больших проектов, в том числе и с веб/десктоп интерфейсом. Уверен, что существует множество условий, при которых применение нашего подхода с экранами в XML более оправданно. Разумеется, ваша точка зрения также оправданна во многих случаях.
По поводу прослоек — вы правы, это еще одна абстракция. Но, как известно, абстракция — неплохой, если не единственный способ борьбы со сложностью. Добавлять или не добавлять этот слой поверх упомянутых вами фрейморков — это выбор разработчиков, и мы считаем что для большого класса проектов эта абстракция дает больше плюсов чем минусов.
А вот по поводу XML выскажусь. На наш взгляд отделение компоновки экранов от логики — это совершенно необходимая вещь в больших проектах. Писать кучу сложных экранов на чистом Vaadin или Swing — это кошмар, мы через это прошли. Посмотрите примеры кода создания экранов на сайте Vaadin — это сотни строк кода, даже для простых экранов — создать все компоненты, задать им свойства, разложить по контейнерам. Нет, спасибо. Сопровождать это потом очень трудно, мы реально делали это на Swing раньше.
Применять или не применять визуальные инструменты типа нашей Студии — это по желанию. Но layout в XML — для нас это однозначно.
Что касаемо работоспособности одновременно веб и десктоп — можем интересующимся приватно показать живое демо Sherlock — системы для такси. Это не туториал. И код этих экранов можем показать.