Комментарии 46
Покушение на лавры ExtJS? ;)
+3
НЛО прилетело и опубликовало эту надпись здесь
По словам разработчиков, web-приложения при помощи Qooxdoo можно создавать даже без знания HTML, CSS и DOM модели.
… ну вот и какого, спрашивается, качества будут эти веб-приложения, если их смогут создавать люди без знания HTML, CSS и DOM-модели?
+1
Я разрабатываю приложения на ExtJS, и я крайне редко прибегаю к знаниям html,css,dom-модели. Точнее сказать, вообще никогда. Css, разве что, или простенькие >b>, >p> и т.д., если в панели нужно разместить сложную структуру.
0
По фрейду :))
<b> <p, простите.
<b> <p, простите.
+1
Я хотел скзаать, что эти фреймворки направлены на то, чтобы максимально приблизить программирование гуя к созданию интерфейсов под десктоп. А какой там html? /не считая всяких украшательств для форматирования текста на кнопочках/
Сложный html здесь во многих случаях даже противопоказан — для обеспечения кроссбраузерности, о которой уже подумали за вас разработчики фреймворка.
Сложный html здесь во многих случаях даже противопоказан — для обеспечения кроссбраузерности, о которой уже подумали за вас разработчики фреймворка.
0
Угу. А я исправляю ошибки и оптимизирую проекты, которые сделаны на популярных фреймворках «без знания дом-модели, штмл и цсс». При этом я страшно ругаюсь.
+2
Я понимаю вас, но наверняка вы говорите не о таких проектах как те, что сделаны на основе ExtJS — в большинстве своём ориентированные на альтернативу десктопу в вебе. Там это просто не нужно. И ваши исправления тоже(если говорить о тех, которые описали вы).
0
вы думаете. что люди без знания CSS, HTML и DOM будут знать Javascript и использовать его фреймворки?
0
1. Чем оно все же лучше чем extjs? Я посмотрел демки — не впечатлили, намного хуже по возможностям чем Ехт.
То что фреймворк старше — не делает его лучше.
2. Согдасен с тем что можно работать не зная «дома» с такого рода фреймворками. В этом их задача или изюминка, что можно разрабатывать интерфейсы и свою аппликацию не заморачиваясь постоянным низкоуровневым изобретанием велосипедов.
Хотя если хочеться допилить фреймворк, сделать красивей или быстрей, то знания нужны.
То что фреймворк старше — не делает его лучше.
2. Согдасен с тем что можно работать не зная «дома» с такого рода фреймворками. В этом их задача или изюминка, что можно разрабатывать интерфейсы и свою аппликацию не заморачиваясь постоянным низкоуровневым изобретанием велосипедов.
Хотя если хочеться допилить фреймворк, сделать красивей или быстрей, то знания нужны.
+1
Я так понимаю, преимущества — в лицензии. Qooxdoo — свободный фреймворк.
ExtJS имеет коммерческую лицензию.
ExtJS имеет коммерческую лицензию.
0
Extjs имеет двойную лицензию.
На бесплатной основе предоставляется по лицензии GPLv3
На бесплатной основе предоставляется по лицензии GPLv3
0
Упс, сейчас вчитался — лицензию, совместимую с GPLv3
0
Кстати наличие коммерческой лицензии — хороший способ поддержать любимый проект. Я купил и не жалею. И это не остановило меня от выкладывания моих изменений в ехт и плагинах.
+1
А расскажите, какую это вам принесло пользу? Помимо моральных приятностей.
0
Как минимум я получил свои деньги сполна обратно в виде премии за скорость и качество разработки админки с использованием extjs. А моральное удовольствие в том что я не трахаюсь с домом, с хтмл, не изобретаю свои велосипеды на хтмл+ажакс+пхп заполнить форму в 15 сабмитов и кучей неудобных елементов, без поиска, без сортировки, фильтрации и т.д.
У меня есть сервер сайд, «чистый» от презентации, возращающий и принимающий json. И есть клиентская часть, в которой практически нет «ручного» хтмл. Для клиент-сайда я практически пишу все на чистом жаваскрипте (из-за этого мне стали интересны сервер сайд жаваскрипт проекты) используя готовые виджеты, которые из себя представляют готовые наборы виджетов extjs с готовым набором межвиджетных связей.
Пример: для создания грида, в котором я хочу иметь: название продукта, тип, цена, типы доставки. Хочу иметь возможность фильтровать грид, делать поиск (с подсветкой), хочу в зависимости от задачи иметь его в плоском виде или в древовидном. Иногда нужно дать возможность ручной перетасовки обьектов, для сортируемых списков. То я пишу:
var grid = mywidgets.products_grid({
tree: false,
sortable: true,
search: true,
store: {
additional_fields: [
{ name: «shipping», type: «string» },
…
]
},
grid: {
additional_columns: [
mywidgets.chunks.grid_columns.shipping()
]
}
});
Код выглядит чисто и читабельно. И такие виджеты легче поддерживать, расширять и тестировать. Т.к. очень хорошо помню как писал простыни на тыщу-две строк жаваскрипта, где досконально описывался грид, подключались плагины, прописывались взаимосвязи, вплодь до цвета подсветки результатов в поиске.
Еще за что пришлось платить, не в прямом смысле, но все равно доставило проблем — отжирание памяти и производительность.
Версия 3.1 вроде имеет улучшения в этом плане, но сам до сих пор со второй версией, не могу мигрировать т.к. все таки много чего сам перелопатил внутри ехт, хоть и делал как оверлоад функций.
У меня есть сервер сайд, «чистый» от презентации, возращающий и принимающий json. И есть клиентская часть, в которой практически нет «ручного» хтмл. Для клиент-сайда я практически пишу все на чистом жаваскрипте (из-за этого мне стали интересны сервер сайд жаваскрипт проекты) используя готовые виджеты, которые из себя представляют готовые наборы виджетов extjs с готовым набором межвиджетных связей.
Пример: для создания грида, в котором я хочу иметь: название продукта, тип, цена, типы доставки. Хочу иметь возможность фильтровать грид, делать поиск (с подсветкой), хочу в зависимости от задачи иметь его в плоском виде или в древовидном. Иногда нужно дать возможность ручной перетасовки обьектов, для сортируемых списков. То я пишу:
var grid = mywidgets.products_grid({
tree: false,
sortable: true,
search: true,
store: {
additional_fields: [
{ name: «shipping», type: «string» },
…
]
},
grid: {
additional_columns: [
mywidgets.chunks.grid_columns.shipping()
]
}
});
Код выглядит чисто и читабельно. И такие виджеты легче поддерживать, расширять и тестировать. Т.к. очень хорошо помню как писал простыни на тыщу-две строк жаваскрипта, где досконально описывался грид, подключались плагины, прописывались взаимосвязи, вплодь до цвета подсветки результатов в поиске.
Еще за что пришлось платить, не в прямом смысле, но все равно доставило проблем — отжирание памяти и производительность.
Версия 3.1 вроде имеет улучшения в этом плане, но сам до сих пор со второй версией, не могу мигрировать т.к. все таки много чего сам перелопатил внутри ехт, хоть и делал как оверлоад функций.
+4
Про ExtJS я в курсе, сам уже 3 месяца работаю над большим проектом, который так же организован, как ваш, а также помимо json-представлений имеет представления в виде html, построенные на YAML.
Я интересуюсь, что вам дала покупка коммерческой лицензии?
И, спасибо за такой комментарий — потянул бы на топик-обзор.
Я интересуюсь, что вам дала покупка коммерческой лицензии?
И, спасибо за такой комментарий — потянул бы на топик-обзор.
0
НЛО прилетело и опубликовало эту надпись здесь
Постраничное разбиение тоже предлагаете на клиенте делать?
0
Сортировка зачастую тратит значительное количество ресурсов системы, и её можно переложить на клиента, если это не отразится на производительности клиентской части в целом. Как правило, это именно так.
Разбиение на страницы при перекладывании на клиента увеличивает как потребление памяти, так и размер получаемых данных, и увеличивает сильно(в разы, если брать в расчёт один запрос данных json), а это уже на сегодняшний момент критично.
Разбиение на страницы при перекладывании на клиента увеличивает как потребление памяти, так и размер получаемых данных, и увеличивает сильно(в разы, если брать в расчёт один запрос данных json), а это уже на сегодняшний момент критично.
0
Америку не открывал, просто изложил те вещи которые все постоянно используют, но в 90% вариантах случаях каждый программист их заного имплементирует в своей админке/системе.
Между прочим не только админки это могут использовать. Системы статистики, билинга, аффилиатские системы, там где много букаф, цифер и т.д. Группировки, фильтры еще как нужно. И никак не связано с администрированием чего либо.
Между прочим не только админки это могут использовать. Системы статистики, билинга, аффилиатские системы, там где много букаф, цифер и т.д. Группировки, фильтры еще как нужно. И никак не связано с администрированием чего либо.
0
Штука очень хорошая и интересная, но работает как-то неспешно… Таймаут, что ли, большой выставили на действие после клика.
0
и где использовать такие гуи-фреймворки, ориентированые на незнание HTML, DOM, CSS?
вероятно что это какие то проекты с большим количеством гуи приближенного к десктопному,
но тогда возникает вопрос — нахрена они нужны, если для этого есть Java, Flash, Silverlight у которых предостаточно удобных инструметов для разработки, включая и визуальные редакторы?
вероятно что это какие то проекты с большим количеством гуи приближенного к десктопному,
но тогда возникает вопрос — нахрена они нужны, если для этого есть Java, Flash, Silverlight у которых предостаточно удобных инструметов для разработки, включая и визуальные редакторы?
-1
Из собственного опыта — CRM, ERP. Намного удобней, чем решения, ориентированные на ajax или просто html-представления.
0
ну если там знания html ненужны, что действительно удобнее набивать жабаскрипт-код для создания интефрейса, вместо использования визуальных редакторов для интерфейса в случае Java, Flash, Silverlight?
0
Не представляю себе серьёзное корпоративное приложение, сделанное на Flash/Silverlight.
На java получится десктопное приложение, а речь идёт о другом.
Код для создания интерфейса на js набивается очень и очень легко, а для ExtJS сейчас разрабатывается Adobe Air — приложение для визуального редактирования интерфейса. Сейчас пока доступна только превью-версия, ждём релиз.
На java получится десктопное приложение, а речь идёт о другом.
Код для создания интерфейса на js набивается очень и очень легко, а для ExtJS сейчас разрабатывается Adobe Air — приложение для визуального редактирования интерфейса. Сейчас пока доступна только превью-версия, ждём релиз.
0
Да и те же gwave, meebo.
0
Понравился пример со связывание данных
demo.qooxdoo.org/current/showcase/#table
Но возникает вопрос, насколько удобно совмещать работу с Quuxdoo с работой в jQuery?
demo.qooxdoo.org/current/showcase/#table
Но возникает вопрос, насколько удобно совмещать работу с Quuxdoo с работой в jQuery?
0
Я не вижу особого смысла в этом, кроме того, что это может быть удобно тем, что либо вы используете jquery уже, либо хорошо его знаете. Однако в qooxdoo есть свой low level API, который позволяет делать тоже самое, что позволяет jQuery. Единственное, что выглядить это будет немного по разному с т.зр. «синтаксита». Т.е. это говорит о том, что qooxdoo можно использовать и на сайте, для создания каких-либо небольших функциональных блоков, как и другие библиотеки, однако одна дает еще одно весомое преимущество — OO — классы, mixins, инерфейсы, «нормальное» наследование.
0
Сейчас врятли подобные продукты получат развитие(если они конечно задаются такой целью), когда лидеры завоевали рынок. Но будут появляться как грибы после дождя
-1
Судя по первым строчкам на странице «тестовой среды» сразу заметны недостатки по сравнению с Extjs:
Qooxdoo:
Extjs:
Вместо передачи одного параметра с набором опций, каждая опция в Quuxdoo задается отдельным параметром конструктора. А ведь опций в любом элементе UI может быть гораздо больше.
Qooxdoo:
var button1 = new qx.ui.form.Button("First Button", "icon/22/apps/internet-web-browser.png");
Extjs:
var button1 = new Ext.Button({
text: "First Button",
icon: "icon/22/apps/internet-web-browser.png"
});
Вместо передачи одного параметра с набором опций, каждая опция в Quuxdoo задается отдельным параметром конструктора. А ведь опций в любом элементе UI может быть гораздо больше.
-1
работаю более года с ExtJS, всегда ругался на то, что даже для создания кнопки в доме используется несколько таблиц… В Qooxdoo конечно все блочно и вроде бы нет лишних элементов, но не смотря на это как то он медленнее работает чем Ext
+1
Ну так блоки/таблицы это не так критично — главное что и как с DOM делать. Вот в Qooxdoo для каждого элемента (тега) прописывается inline стиль, и при каждом чихе он правится (меняются значения свойств) по цепочке, то есть вместо того чтобы менять для одного элемента (ну пусть 2-3), меняется для десятков — отсюда и потери в скорости. А еще большинство элементов (можно сказать что практически все) абсолютно позиционированы, то есть вместо того чтобы дать браузеру заниматься layout'ом — этим всецело занимается фреймворк…
0
посмотрите на вес этого фреймворка…
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Релиз Javascript фреймворка Qooxdoo 1.0