Комментарии 54
Читал и плакал, вспоминая Oracle ADF…
Его рекламные проспекты, схемы, графики, пламенные речи, декларативность… и то что получилось (да и сейчас получается) в итоге.
Надеюсь у вас результат лучше.
Его рекламные проспекты, схемы, графики, пламенные речи, декларативность… и то что получилось (да и сейчас получается) в итоге.
Надеюсь у вас результат лучше.
а можно поподробнее?
Подробно получится книга листов на 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 для всего» очень быстро теряется и начинает отжирать время (как основной ресурс) просто в страшных количествах. Тут как правило все уже начинают понимать, к чему приводит экономия там где не надо, но уже не в силах отказаться от сделанного, слишком много ресурсов вложено в доведение этих костылей до ума. а руководство, как правило, не умеет признавать свои ошибки и отказываться от расточительных проектов… ежики плакали, кололись, но продолжали жрать кактус.
Но в целом, декларативность, которая очень круто выглядит на демонстрациях и в туториалах (все эти тонны 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 для всего» очень быстро теряется и начинает отжирать время (как основной ресурс) просто в страшных количествах. Тут как правило все уже начинают понимать, к чему приводит экономия там где не надо, но уже не в силах отказаться от сделанного, слишком много ресурсов вложено в доведение этих костылей до ума. а руководство, как правило, не умеет признавать свои ошибки и отказываться от расточительных проектов… ежики плакали, кололись, но продолжали жрать кактус.
Ничего не могу сказать по поводу ADF, в любом случае у нас совсем другой подход.
А вот по поводу XML выскажусь. На наш взгляд отделение компоновки экранов от логики — это совершенно необходимая вещь в больших проектах. Писать кучу сложных экранов на чистом Vaadin или Swing — это кошмар, мы через это прошли. Посмотрите примеры кода создания экранов на сайте Vaadin — это сотни строк кода, даже для простых экранов — создать все компоненты, задать им свойства, разложить по контейнерам. Нет, спасибо. Сопровождать это потом очень трудно, мы реально делали это на Swing раньше.
Применять или не применять визуальные инструменты типа нашей Студии — это по желанию. Но layout в XML — для нас это однозначно.
Что касаемо работоспособности одновременно веб и десктоп — можем интересующимся приватно показать живое демо Sherlock — системы для такси. Это не туториал. И код этих экранов можем показать.
А вот по поводу XML выскажусь. На наш взгляд отделение компоновки экранов от логики — это совершенно необходимая вещь в больших проектах. Писать кучу сложных экранов на чистом Vaadin или Swing — это кошмар, мы через это прошли. Посмотрите примеры кода создания экранов на сайте Vaadin — это сотни строк кода, даже для простых экранов — создать все компоненты, задать им свойства, разложить по контейнерам. Нет, спасибо. Сопровождать это потом очень трудно, мы реально делали это на Swing раньше.
Применять или не применять визуальные инструменты типа нашей Студии — это по желанию. Но layout в XML — для нас это однозначно.
Что касаемо работоспособности одновременно веб и десктоп — можем интересующимся приватно показать живое демо Sherlock — системы для такси. Это не туториал. И код этих экранов можем показать.
Я тоже много писал на Swing раньше, сейчас на Vaadin.
Возможно у нас с вами разный подход к разработке, ибо у меня нет «сотни строк кода, даже для простых экранов».
>Применять или не применять визуальные инструменты типа нашей Студии — это по желанию.
Вот это хороший подход, правильный.
>Что касаемо работоспособности одновременно веб и десктоп…
Я не сомневаюсь, что можно сделать генерацию различных клиентов через XML. Я просто знаю, ибо видел не раз, чего в итоге стоит такое решение в больших проектах. И не верю что может получится серебряная пуля.
Логика очень простая, когда я выбираю vaadin, я попадаю в зависимость от них и их решений по развитию.
Когда выбираю решения типа вашего, я попадаю в зависимость от двух вендоров сразу, и их взаимодействия. Т.е. в случае проблем, головняка будет даже не в 2 раза, а больше…
А профит от первоначального ускорения создания форм, очень быстро нивелируется разборками с глюками системы уйдя в «минус».
Возможно у нас с вами разный подход к разработке, ибо у меня нет «сотни строк кода, даже для простых экранов».
>Применять или не применять визуальные инструменты типа нашей Студии — это по желанию.
Вот это хороший подход, правильный.
>Что касаемо работоспособности одновременно веб и десктоп…
Я не сомневаюсь, что можно сделать генерацию различных клиентов через XML. Я просто знаю, ибо видел не раз, чего в итоге стоит такое решение в больших проектах. И не верю что может получится серебряная пуля.
Логика очень простая, когда я выбираю vaadin, я попадаю в зависимость от них и их решений по развитию.
Когда выбираю решения типа вашего, я попадаю в зависимость от двух вендоров сразу, и их взаимодействия. Т.е. в случае проблем, головняка будет даже не в 2 раза, а больше…
А профит от первоначального ускорения создания форм, очень быстро нивелируется разборками с глюками системы уйдя в «минус».
> Я тоже много писал на Swing раньше, сейчас на Vaadin.
>Возможно у нас с вами разный подход к разработке, ибо у меня нет «сотни строк кода, даже для простых экранов».
Очевидно, вы создали для себя свой собственный слой абстракции :)
> А профит от первоначального ускорения создания форм, очень быстро нивелируется разборками с глюками системы уйдя в «минус».
Это ваш опыт. У нас он другой, повторяю про наличие реальных больших проектов, в том числе и с веб/десктоп интерфейсом. Уверен, что существует множество условий, при которых применение нашего подхода с экранами в XML более оправданно. Разумеется, ваша точка зрения также оправданна во многих случаях.
>Возможно у нас с вами разный подход к разработке, ибо у меня нет «сотни строк кода, даже для простых экранов».
Очевидно, вы создали для себя свой собственный слой абстракции :)
> А профит от первоначального ускорения создания форм, очень быстро нивелируется разборками с глюками системы уйдя в «минус».
Это ваш опыт. У нас он другой, повторяю про наличие реальных больших проектов, в том числе и с веб/десктоп интерфейсом. Уверен, что существует множество условий, при которых применение нашего подхода с экранами в XML более оправданно. Разумеется, ваша точка зрения также оправданна во многих случаях.
Очевидно, вы создали для себя свой собственный слой абстракции :)
Выше была упомянута 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, конечно, пришлось написать немного функций-хелперов, но они именно хелперы, а не отдельный слой абстракции.
>Но layout в XML — для нас это однозначно.
А почему именно в XML, что мешает сделать слой абстракции в коде? Почему джависты чуть что хватаются делать DSL поверх XML?
А почему именно в XML, что мешает сделать слой абстракции в коде? Почему джависты чуть что хватаются делать DSL поверх XML?
Хороший вопрос.
По следующим причинам:
1. XML хорошо читается, особенно когда теги семантические, т.е.
2. XML с семантическими тегами легко писать руками, IDE подсказывает вам возможные теги и атрибуты по XSD (а она у нас разумеется есть).
3. XML легко генерить сторонними инструментами типа плагина к IDE или Студии.
По следующим причинам:
1. XML хорошо читается, особенно когда теги семантические, т.е.
<textField id="myField"/> а не <component class="com.lalala.TextField" id="myField">. Под «хорошо читается» я имею в виду то, что когда вы открываете исходник такого экрана, то при некотором навыке понимаете как он будет выглядеть в работе, без всяких визуализирующих Студий.2. XML с семантическими тегами легко писать руками, IDE подсказывает вам возможные теги и атрибуты по XSD (а она у нас разумеется есть).
3. XML легко генерить сторонними инструментами типа плагина к IDE или Студии.
Не могу согласиться что 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?
Но вообще я имел ввиду не XML vs JSON vs что-угодно, а eDSL vs XML. Т.е. почему у вас именно XML, почему нельзя сделать чтобы layout-ы можно делать удобно прямо в коде? Даже не смотря на то, что в Java нет человеческих литералов, все равно можно обложиться хелперами и всякими fluent-интерфейсами, и делать все может и немного многословнее, но зато — как минимум гораздо гибче.
В коде я могу делать что-то типа:
if (user.allowedToEditThis && entity.Status != Status.Closed) {
layout.add(new TextField(....))
}
Как я такое буду делать в XML?
> Не могу согласиться что XML так уж хорош. Читается, редактируется он, как по мне, отвратительно, а генерируется он не удобнее всяких остальных JSON-ов.
Это дело вкуса. Как минимум XML привычнее, его знают все. И я не уверен, что для JSON существует сравнимое с XSD по возможностям решение, и с соответствующей поддержкой от IDE.
> В коде я могу делать что-то типа:
Мы тоже делаем это в коде :)
В XML только статический layout, и кроме прочего может быть объявлен пустой контейнер, ссылку на который вы по ID получаете в Java-контроллере, создаете компоненты и кладете в контейнер.
Другое дело, что это приходится делать нечасто, так как компоненты, связанные с данными автоматически скрываются или делаются read-only, если например атрибут, который они отображают, запрещен данному пользователю по security. А вот чтобы учесть Status из вашего примера, действительно придется написать примерно такой же код.
Это дело вкуса. Как минимум XML привычнее, его знают все. И я не уверен, что для JSON существует сравнимое с XSD по возможностям решение, и с соответствующей поддержкой от IDE.
> В коде я могу делать что-то типа:
Мы тоже делаем это в коде :)
В XML только статический layout, и кроме прочего может быть объявлен пустой контейнер, ссылку на который вы по ID получаете в Java-контроллере, создаете компоненты и кладете в контейнер.
Другое дело, что это приходится делать нечасто, так как компоненты, связанные с данными автоматически скрываются или делаются read-only, если например атрибут, который они отображают, запрещен данному пользователю по security. А вот чтобы учесть Status из вашего примера, действительно придется написать примерно такой же код.
Я сам делаю опердени (т.е. приложения из форм и таблиц), в том числе на вебе. И мой опыт показывает что на большинстве будут требоваться всякие хитрые штуки, типа этого 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.
Короче моя точка зрения в том, что если уж делать декларативное, нужно что-то сильно хитрее.
Взять какую-нибудь банальную форму 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.
Короче моя точка зрения в том, что если уж делать декларативное, нужно что-то сильно хитрее.
Первый раз слышу такое слово — опердень.
По сути вашего комментария. Конечно странно тут обсуждать фреймворк, который к нам не имеет никакого отношения и я его не использовал. Но форма, которая открывается по вашей ссылке, действительно довольно типичная, и я возьмусь прокомментировать.
> Там 100% будет нужна сумма заказа
В чем проблема? Делаете поле и связываете с атрибутом AMOUNT сущности.
> там стопудово нужно будет отключать кучу кнопок если OrderLines пустые
В CUBA есть «стандартные actions», которые отслеживают, что какая-нибудь строка таблицы выбрана. Если не выбрана, кнопки недоступны (например «Edit»).
> наверняка будет какой-нибудь поиск дубликатов customer-ов
Да, чтобы это отслеживать на этапе ввода, а не после коммита формы, нужно написать метод сервиса на среднем слое и вызывать например его в листенере изменения таблицы (это грубо, там несколько разных типов листенеров).
> в строке заказа нельзя поправить количество заказанного не заходя в попап-меню
В CUBA есть «редактируемые таблицы», когда вы объявляете какую-то колонку редактируемой и можно вводить в нее значения не открывая дополнительных окон.
> идея «замеппим поля таблиц на контролы, контролы разложим в XML-ке»
У нас несколько сложнее — контролы мапятся на графы сущностей, извлекаемые со среднего слоя в datasources экрана. Возможно, это частично помогает нам не ломать «горизонтальные» механизмы специфическим кодом.
По сути вашего комментария. Конечно странно тут обсуждать фреймворк, который к нам не имеет никакого отношения и я его не использовал. Но форма, которая открывается по вашей ссылке, действительно довольно типичная, и я возьмусь прокомментировать.
> Там 100% будет нужна сумма заказа
В чем проблема? Делаете поле и связываете с атрибутом AMOUNT сущности.
> там стопудово нужно будет отключать кучу кнопок если OrderLines пустые
В CUBA есть «стандартные actions», которые отслеживают, что какая-нибудь строка таблицы выбрана. Если не выбрана, кнопки недоступны (например «Edit»).
> наверняка будет какой-нибудь поиск дубликатов customer-ов
Да, чтобы это отслеживать на этапе ввода, а не после коммита формы, нужно написать метод сервиса на среднем слое и вызывать например его в листенере изменения таблицы (это грубо, там несколько разных типов листенеров).
> в строке заказа нельзя поправить количество заказанного не заходя в попап-меню
В CUBA есть «редактируемые таблицы», когда вы объявляете какую-то колонку редактируемой и можно вводить в нее значения не открывая дополнительных окон.
> идея «замеппим поля таблиц на контролы, контролы разложим в XML-ке»
У нас несколько сложнее — контролы мапятся на графы сущностей, извлекаемые со среднего слоя в datasources экрана. Возможно, это частично помогает нам не ломать «горизонтальные» механизмы специфическим кодом.
Опердень — это сокращение от «операционный день банка». Это такой класс банковских приложений, которые состоят из форм и таблиц чуть более чем полностью. Название прижилось в определенных кругах как нарицательное название всех бизнес-приложений из таблиц и форм.
>У нас несколько сложнее — контролы мапятся на графы сущностей, извлекаемые со среднего слоя в datasources экрана. Возможно, это частично помогает нам не ломать «горизонтальные» механизмы специфическим кодом.
Т.е. у вас контролы и их логика работают поверх каких-то viewmodel, которые туда-сюда мэппятся в модель, а дальше в базу? Это действительно хороший шаг и спасет от многих проблем. А есть где почитать именно про этот момент?
>У нас несколько сложнее — контролы мапятся на графы сущностей, извлекаемые со среднего слоя в datasources экрана. Возможно, это частично помогает нам не ломать «горизонтальные» механизмы специфическим кодом.
Т.е. у вас контролы и их логика работают поверх каких-то viewmodel, которые туда-сюда мэппятся в модель, а дальше в базу? Это действительно хороший шаг и спасет от многих проблем. А есть где почитать именно про этот момент?
У нас иногда всплывает определение наших английских коллег — «system of records». Тоже довольно точно передает тот класс приложений, который вы описали. Именно формы и таблицы. Плюс отчеты, иногда карты и графики. И все.
Про наши источники данных (datasources) можно почитать здесь. К сожалению, пока информация там сухая и мало примеров, но представление получить можно.
Про наши источники данных (datasources) можно почитать здесь. К сожалению, пока информация там сухая и мало примеров, но представление получить можно.
Почитал, но не очень понял вот что: как я понимаю viewmodel у вас представлена классом с определенными интерфейсами, а класс как я понимаю живет на сервере. Как тогда вводить поведение на клиенте (типа того же подсчета суммы order lines)?
У фреймворка Vaadin всё поведeние на сервере, если вы в терминах Клиент=Браузер. Если вы в терминах Сервер=Средний слой, то модель живёт на веб-клиенте вместе с поведением (классом контроллера).
Да, это набор Java-итерфейсов и их релизаций. Чтобы разобраться с тем, что мы называем клиентом, посмотрите пожалуйста на эту диаграмму.
Код datasources (как и всего фреймворка GenericUI) физически располагается в случае веб-клиента на веб-сервере, а в случае десктоп клиента на машине пользователя. Не забывайте, что для веб-клиента мы используем Vaadin, который дает нам возможность писать только server-side.
Код datasources (как и всего фреймворка GenericUI) физически располагается в случае веб-клиента на веб-сервере, а в случае десктоп клиента на машине пользователя. Не забывайте, что для веб-клиента мы используем Vaadin, который дает нам возможность писать только server-side.
интерестно посмотреть
Ну, абстракции какие-то в любом случае будут. И декларативщина — тоже, в каком-то объеме. И если она удачная — почему бы и нет?
Хотя я вот тоже натерпелся XML-DSL-ей с мета-конфигурациями мета-данных о мета-layout-ами, со своими XML-условными операторами, циклами и наследованием. Так что для меня фраза «конфигурируется в XML» — это звоночек :)
Хотя я вот тоже натерпелся XML-DSL-ей с мета-конфигурациями мета-данных о мета-layout-ами, со своими XML-условными операторами, циклами и наследованием. Так что для меня фраза «конфигурируется в XML» — это звоночек :)
Все хорошо в меру.
Чтобы успокоить уважаемых читателей, скажу, что в CUBA нигде нет XML-условных операторов и циклов. Для этого есть контроллеры на Java. А вот наследование XML-компоновки экранов есть, оно очень помогает в расширениях (адаптациях для заказчиков) продуктов переопределять компоновку базовых экранов.
Чтобы успокоить уважаемых читателей, скажу, что в CUBA нигде нет XML-условных операторов и циклов. Для этого есть контроллеры на Java. А вот наследование XML-компоновки экранов есть, оно очень помогает в расширениях (адаптациях для заказчиков) продуктов переопределять компоновку базовых экранов.
Что бы было понятнее, посмотрите на скрин системы из статьи
Пример с сайта разработчиков CUBA
Обратите внимание на кнопки выбора/очистки у полей слева.
Борьба с таки глюками, а они могут быть гораздо серьезнее, отнимает просто адовое количество времени.
Если вообще будет техническая возможность исправить это…
Пример с сайта разработчиков CUBA
Обратите внимание на кнопки выбора/очистки у полей слева.
Борьба с таки глюками, а они могут быть гораздо серьезнее, отнимает просто адовое количество времени.
Если вообще будет техническая возможность исправить это…
Это обычная проблема В CSS теме конкретного проекта, ничего более.
Ну в данном конкретно случае, возможно вы и правы.
Но речь идет не о конкретной какой-то ошибке. А о том, что появляется еще одна прослойка абстракция над другими абстракциями. Которая добавляет проблем, которые неизвестно где аукнутся.
Но речь идет не о конкретной какой-то ошибке. А о том, что появляется еще одна прослойка абстракция над другими абстракциями. Которая добавляет проблем, которые неизвестно где аукнутся.
Данный конкретный случай — это лень разработчиков (это не наш проект, наших партнеров) и апатия пользователей. Ну и разумеется наш косяк, что мы опубликовали такой скриншот. Правда теперь после вашего комментария как-то и неудобно его убирать…
По поводу прослоек — вы правы, это еще одна абстракция. Но, как известно, абстракция — неплохой, если не единственный способ борьбы со сложностью. Добавлять или не добавлять этот слой поверх упомянутых вами фрейморков — это выбор разработчиков, и мы считаем что для большого класса проектов эта абстракция дает больше плюсов чем минусов.
По поводу прослоек — вы правы, это еще одна абстракция. Но, как известно, абстракция — неплохой, если не единственный способ борьбы со сложностью. Добавлять или не добавлять этот слой поверх упомянутых вами фрейморков — это выбор разработчиков, и мы считаем что для большого класса проектов эта абстракция дает больше плюсов чем минусов.
Посмотрел видео работы с системой: http://vimeo.com/77210510
Выглядит с одной стороны логично, с другой — довольно запутанно: постоянно надо нажимать кучу разных элементов интерфейса. Я, как разработчик, наверно бы в итоге сбежал от этой «интерфейсной магии». :)
Но, наверняка, многим заказчикам нравится возможность клепать всё из UI.
Выглядит с одной стороны логично, с другой — довольно запутанно: постоянно надо нажимать кучу разных элементов интерфейса. Я, как разработчик, наверно бы в итоге сбежал от этой «интерфейсной магии». :)
Но, наверняка, многим заказчикам нравится возможность клепать всё из UI.
Видео о приложении Студия, чтобы можно было быстро начать. Программисты хорошо работают и без неё, поскольку есть хороший плагин для IntelliJ Idea (плагин именно для программистов, без «интерфейсной магии»).
По поводу запутанно, XAF видели? Вот уж где царство Шеогората, так это там.
Кстати хотелось бы знать, krivopustov, в каких условиях записывалось видео? (примерная конфигурация железа).
Кстати хотелось бы знать, krivopustov, в каких условиях записывалось видео? (примерная конфигурация железа).
Студия в начале полезна тем, что можно покликать мышкой, посмотреть что получается в проекте — какие файлы где создаются, где что регистрируется. Потом постепенно можно то же самое делать просто в IDE. И плагин для IDEA на самом деле не обязателен, весь код проекта — это Java плюс XML для компоновки экранов и нескольких конфигов.
Да и даже когда все знаешь досконально изнутри, для многих задач такой визуальный интерфейс удобнее, чем код править.
Да и даже когда все знаешь досконально изнутри, для многих задач такой визуальный интерфейс удобнее, чем код править.
Про шишки с Vaadin интересно, напишите пожалуйста. Я сейчас сам пишу проект на Vaadin и Scala и тоже набиваю шишки.
У нас много своих компонентов на Vaadin и многое из API Vaadin (особенно то, что они не хотят чинить) исправлено в форке, идущем параллельно их ветке 7.1. Регулярно постим им баги и сабмитим патчи в Gerrit (иногда они их принимают). Опыт в Vaadin копим ещё со времён IT Mill, когда ещё никакого Vaadin Ltd то не было. Подробный пост про Vaadin и причуды обязательно будет.
Я тут зафорчу тред немного ) Подскажите, пожалуйста, вы наталкивались, а, быть может и исправили этот баг у себя? dev.vaadin.com/ticket/13034. Сколько ни имел дела с Vaadin сообществом, ответов не добивался.
Да, такая проблема есть, это их баг с автоматической высотой в окнах. Можно вопроизвести даже положив в окно вертикальный бокс с кучей длинных надписей gist.github.com/jreznot/7823647. Мы решаем проблемы со скроллингом явным использованием панели со скроллингом (и указываем режим скроллбаров — вертикальный/горизонтальный/оба), в которую кладём то, что может не умещаться.
Авторы черпали вдохновение с платформы 1C.Enterprise?
Как-то с названием не супер.
лучше бы что-то типа v8.1c.ru/metod/videotutorial/000000022.html выложили — сразу стало бы понятно про то, какая это «платформа»
Пожалуйста. На сайте все есть:
www.cuba-platform.com/ru/quickstart
www.cuba-platform.com/ru/quickstart
ну, «создание связной сущности» и «микроучетная система ремонтов» — все-таки разные по уровню вещи.
Согласен. У нас немного другой подход, мы стараемся длинные ролики не делать.
Вместо этого делаем отдельные по разным темам, мне кажется это удобнее.
Часть уже есть здесь: www.cuba-platform.com/ru/tutorials
Сейчас здесь в основном обзорные ролики по некоторым компонентам платформы, постепенно будем добавлять ролики непосредственно по процессу разработки. Все желаемое сразу к сожалению сделать не получается, так как это достаточно трудоемкий процесс.
Вместо этого делаем отдельные по разным темам, мне кажется это удобнее.
Часть уже есть здесь: www.cuba-platform.com/ru/tutorials
Сейчас здесь в основном обзорные ролики по некоторым компонентам платформы, постепенно будем добавлять ролики непосредственно по процессу разработки. Все желаемое сразу к сожалению сделать не получается, так как это достаточно трудоемкий процесс.
Выглядит интересно. Но основная проблема с подобными технологиями — нельзя просто взять и соскочить. Получается замкнутый круг: чтобы начать разбираться в какой-то технологии, нужно потратить на нее пару лет. А потратив, сложно перейти на что-то другое в случае косяков.
Согласен, соскочить сложно.
Но так же сложно соскочить например с Vaadin или Swing, хотя это и более низкоуровневые вещи. Или попробуйте соскочить с Oracle Database, если вы написали на нем кучу логики в PL/SQL.
Вообще так называемая независимость от вендора, которую пропагандируют разработчики стандартов — в большой степени красивая сказка. Как только вам нужно сделать что-то большое и серьезное, придется использовать всякие проприетарные расширения. Иногда обновить версию используемого фреймворка в работающей системе сложно, не то что сменить поставщика.
Мы работаем над тем, чтобы на освоение CUBA не надо было тратить пару лет. Соответственно соскочить будет проще — меньше сожалений.
Но так же сложно соскочить например с Vaadin или Swing, хотя это и более низкоуровневые вещи. Или попробуйте соскочить с Oracle Database, если вы написали на нем кучу логики в PL/SQL.
Вообще так называемая независимость от вендора, которую пропагандируют разработчики стандартов — в большой степени красивая сказка. Как только вам нужно сделать что-то большое и серьезное, придется использовать всякие проприетарные расширения. Иногда обновить версию используемого фреймворка в работающей системе сложно, не то что сменить поставщика.
Мы работаем над тем, чтобы на освоение CUBA не надо было тратить пару лет. Соответственно соскочить будет проще — меньше сожалений.
Согласен. Поэтому я и предпочитаю работать с Core Java + совсем уже монстрами типа Spring, с которых соскакивать не придется — все их используют. Но это все же немного другая область.
> Иногда обновить версию используемого фреймворка в работающей системе сложно, не то что сменить поставщика.
Это вы, должно быть, про миграцию с шестого Ваадина на седьмой с ловлей кучи лулзов в стиле нескролящихся и прыгающих окон? =)
Это вы, должно быть, про миграцию с шестого Ваадина на седьмой с ловлей кучи лулзов в стиле нескролящихся и прыгающих окон? =)
Или попробуйте соскочить с Oracle Database, если вы написали на нем кучу логики в PL/SQL.
а зачем соскакивать с PL/SQL? разве нельзя просто его вызывать из CUBA?
Или попробуйте соскочить с Oracle Database, если вы написали на нем кучу логики в PL/SQL.
Речь идёт о сферическом глубоком использовании именно возможностей PL/SQL Oracle в сферическом проекте.
Разумеется, вызывать можно. CUBA никак не ограничивает возможности обращения к БД через JDBC или ORM native queries.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CUBA — платформа для быстрой разработки бизнес-приложений на Java