LINUX.ORG.RU

Qooxdoo - делимся опытом использования

 ,


0

3

Здравствуйте!

Qooxdoo: количество виджетов из коробки огромное, лицензия лояльна к нищебродам в отличие от Sencha ExtJS, однако, кривая обучения довольно крутая, и сам по себе фреймворк отличается нестандартным подходом - с помощью утилит командной строки нужно создавать отдельно дебажную и релизную версии.

Если у кого-то есть опыт реального применения Qooxdoo, прошу поделиться в комментариях, а так же рассказать о подводных камнях. Ссылки на реально существующие проекты или GitHub приветствуются.

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

Ответ на: комментарий от anonymous

Может, тогда тут есть эксперты по Dojo? Попытаюсь сейчас писать фронт на нём, но не очень получается. Интересует, например, как описать класс диалога, чтобы загрузка контента была динамической.

dunmaksim
() автор топика
Ответ на: комментарий от dunmaksim

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

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

У меня условия задачи сильно другие.

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

Я где-то месяц писал с использованием Angular Bootstrap, потом Angular Material, но всё уперлось в отсутствие нормальной имитации контролов и окон.

С радостью пересел бы на ExtJS, да дорого.

Примечание: SAP OpenUI смотрел, не то.

dunmaksim
() автор топика
Ответ на: комментарий от Shadow

Когда выбираешь инструмент для своей вебни, надобно задать себе вопрос, на что твоя вебня больше похожа: на ТЕКСТ (как страница из книги или журнала) или ИНТЕРФЕЙС (как панель управления с кнопочками и лампочками). Это принципиально разные вещи с принципиально разными задачами. Сейчас есть нездоровая тенденция делать ИНТЕРФЕЙСЫ с помощью инструментов для вёрстки ТЕКСТА. Это источник страданий, не надо так делать.

anonymous
()
14 января 2017 г.

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

Особенность его в том, что в простейшем случае нет необходимости заниматься разработкой элементов UI на чистом HTML+CSS. Небольшое количество стандартных визуальных компонентов позволяет решать широкий спектр задач в пользовательском интерфейсе. Фреймворк монолитен и все находится в дистрибутиве.

Проблемы точно возникнут у тех, кто не привык разрабатывать в парадигме ООП; у тех, кто любит CSS(соответственно, хорошо знает и пытается его использовать, но в qooxdoo есть подсистема appearance для настройки внешнего вида); у тех, кто считает, что браузерное приложение не должно быть похоже на настольное.

Автор, описание Вам нужно переписать. Такое же описание подходит для большинства фреймворков.

Приходилось разрабатывать приложение для управления ресурсами компании. В приложении были и графики, и inline-редактирование данных в таблице, а коммуникация осуществлялась по JSONRPC. Приходилось новые виджеты делать (наследованием от базового и не только). Использовалось множество контрибов. Другое приложение было для работы с векторной графикой.

Для корпоративных приложений подходит замечательно, т.к. можно сокращать трудозатраты на разработку.

johnsky
()
Ответ на: комментарий от dunmaksim

Интересует, например, как описать класс диалога, чтобы загрузка контента была динамической.

Про дожо не скажу, на мой взгляд он монструозен и тенденция, сейчас такая, основные идеи изложены тут: https://blog.madewithlove.be/post/webpack-your-bags/ (там есть пример концептуальный создания класса как компонента)

В итоге, насколько мне это понятно, было что-то типа requirejs, а сейчас тренд использования webpack.

Посмотрите vuejs, todomvc для вдохновения - сам не использовал, но подумываю что-то оттуда или концептуально.

anonymous
()
Ответ на: комментарий от anonymous

В общем, да, AMD, которое в Dojo из коробки (а в Angular только со второй версии или через выкрутасы). В итоге, немного помучив Qooxdoo, отказался от него, поскольку очень уж сложно для меня. Остановился на Dojo, взяв такой подход:

  • описываю классы на JS, используя dijit/_TemplatedMixin, dijit/_WidgetBase и dijit/_WidgetsInTemplateMixin;
  • с помощью Django возвращаю, а с dojo/text! подгружаю шаблон для виджета, где в зависимости от прав пользователя те или иные контролы заблокированы

Может, это сложный подход, но ничего лучше я не придумал.

dunmaksim
() автор топика
Ответ на: комментарий от dunmaksim

Сейчас AMD плавно вовлекается и развивается в webpack. Встречаются проекты переходящие или перешедшие на AMD.

Не все радует в webpack (например гигантские размеры (в каждом пакете по пачке lodash - в итоге быстро набегает 500гб), монструозность сборки, сложности всякие, динамизм ненативный ...) в отличие от AMD и не все понятно, но много разных полезностей.

Обдумываю возможность использования связки AMD (requirejs или что-то еще) + webpack.

anonymous
()
3 декабря 2017 г.

Некропост

Очень понадобилось что-то такое аки сабж. Фреймворк на JS для создания интерфесов (важно не гипертекста с кнопочками, а сложного интерфейса для ajax). Долго искал среди вариантов, остановился на сабже ибо: 1 пипец как похож на Qt; 2 полностью удовлетворяет списку требований; 3 адекватная производительность; 4 годная документация.
ЗЫ очень радует мобильная версия, возможно применю в будущем.
ЗЗЫ Некропост сюда, ибо вдруг кому понадобится отзыв, тред - первая ссылка в гугле на русском.

erfea ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.