Comments 46
Покушение на лавры ExtJS? ;)
UFO just landed and posted this here
По словам разработчиков, web-приложения при помощи Qooxdoo можно создавать даже без знания HTML, CSS и DOM модели.
… ну вот и какого, спрашивается, качества будут эти веб-приложения, если их смогут создавать люди без знания HTML, CSS и DOM-модели?
Я разрабатываю приложения на ExtJS, и я крайне редко прибегаю к знаниям html,css,dom-модели. Точнее сказать, вообще никогда. Css, разве что, или простенькие >b>, >p> и т.д., если в панели нужно разместить сложную структуру.
По фрейду :))
<b> <p, простите.
<b> <p, простите.
Я хотел скзаать, что эти фреймворки направлены на то, чтобы максимально приблизить программирование гуя к созданию интерфейсов под десктоп. А какой там html? /не считая всяких украшательств для форматирования текста на кнопочках/
Сложный html здесь во многих случаях даже противопоказан — для обеспечения кроссбраузерности, о которой уже подумали за вас разработчики фреймворка.
Сложный html здесь во многих случаях даже противопоказан — для обеспечения кроссбраузерности, о которой уже подумали за вас разработчики фреймворка.
Угу. А я исправляю ошибки и оптимизирую проекты, которые сделаны на популярных фреймворках «без знания дом-модели, штмл и цсс». При этом я страшно ругаюсь.
Я понимаю вас, но наверняка вы говорите не о таких проектах как те, что сделаны на основе ExtJS — в большинстве своём ориентированные на альтернативу десктопу в вебе. Там это просто не нужно. И ваши исправления тоже(если говорить о тех, которые описали вы).
вы думаете. что люди без знания CSS, HTML и DOM будут знать Javascript и использовать его фреймворки?
1. Чем оно все же лучше чем extjs? Я посмотрел демки — не впечатлили, намного хуже по возможностям чем Ехт.
То что фреймворк старше — не делает его лучше.
2. Согдасен с тем что можно работать не зная «дома» с такого рода фреймворками. В этом их задача или изюминка, что можно разрабатывать интерфейсы и свою аппликацию не заморачиваясь постоянным низкоуровневым изобретанием велосипедов.
Хотя если хочеться допилить фреймворк, сделать красивей или быстрей, то знания нужны.
То что фреймворк старше — не делает его лучше.
2. Согдасен с тем что можно работать не зная «дома» с такого рода фреймворками. В этом их задача или изюминка, что можно разрабатывать интерфейсы и свою аппликацию не заморачиваясь постоянным низкоуровневым изобретанием велосипедов.
Хотя если хочеться допилить фреймворк, сделать красивей или быстрей, то знания нужны.
Я так понимаю, преимущества — в лицензии. Qooxdoo — свободный фреймворк.
ExtJS имеет коммерческую лицензию.
ExtJS имеет коммерческую лицензию.
Extjs имеет двойную лицензию.
На бесплатной основе предоставляется по лицензии GPLv3
На бесплатной основе предоставляется по лицензии GPLv3
Упс, сейчас вчитался — лицензию, совместимую с GPLv3
Кстати наличие коммерческой лицензии — хороший способ поддержать любимый проект. Я купил и не жалею. И это не остановило меня от выкладывания моих изменений в ехт и плагинах.
А расскажите, какую это вам принесло пользу? Помимо моральных приятностей.
Как минимум я получил свои деньги сполна обратно в виде премии за скорость и качество разработки админки с использованием 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 вроде имеет улучшения в этом плане, но сам до сих пор со второй версией, не могу мигрировать т.к. все таки много чего сам перелопатил внутри ехт, хоть и делал как оверлоад функций.
Про ExtJS я в курсе, сам уже 3 месяца работаю над большим проектом, который так же организован, как ваш, а также помимо json-представлений имеет представления в виде html, построенные на YAML.
Я интересуюсь, что вам дала покупка коммерческой лицензии?
И, спасибо за такой комментарий — потянул бы на топик-обзор.
Я интересуюсь, что вам дала покупка коммерческой лицензии?
И, спасибо за такой комментарий — потянул бы на топик-обзор.
UFO just landed and posted this here
Постраничное разбиение тоже предлагаете на клиенте делать?
Сортировка зачастую тратит значительное количество ресурсов системы, и её можно переложить на клиента, если это не отразится на производительности клиентской части в целом. Как правило, это именно так.
Разбиение на страницы при перекладывании на клиента увеличивает как потребление памяти, так и размер получаемых данных, и увеличивает сильно(в разы, если брать в расчёт один запрос данных json), а это уже на сегодняшний момент критично.
Разбиение на страницы при перекладывании на клиента увеличивает как потребление памяти, так и размер получаемых данных, и увеличивает сильно(в разы, если брать в расчёт один запрос данных json), а это уже на сегодняшний момент критично.
Америку не открывал, просто изложил те вещи которые все постоянно используют, но в 90% вариантах случаях каждый программист их заного имплементирует в своей админке/системе.
Между прочим не только админки это могут использовать. Системы статистики, билинга, аффилиатские системы, там где много букаф, цифер и т.д. Группировки, фильтры еще как нужно. И никак не связано с администрированием чего либо.
Между прочим не только админки это могут использовать. Системы статистики, билинга, аффилиатские системы, там где много букаф, цифер и т.д. Группировки, фильтры еще как нужно. И никак не связано с администрированием чего либо.
Штука очень хорошая и интересная, но работает как-то неспешно… Таймаут, что ли, большой выставили на действие после клика.
и где использовать такие гуи-фреймворки, ориентированые на незнание HTML, DOM, CSS?
вероятно что это какие то проекты с большим количеством гуи приближенного к десктопному,
но тогда возникает вопрос — нахрена они нужны, если для этого есть Java, Flash, Silverlight у которых предостаточно удобных инструметов для разработки, включая и визуальные редакторы?
вероятно что это какие то проекты с большим количеством гуи приближенного к десктопному,
но тогда возникает вопрос — нахрена они нужны, если для этого есть Java, Flash, Silverlight у которых предостаточно удобных инструметов для разработки, включая и визуальные редакторы?
Из собственного опыта — CRM, ERP. Намного удобней, чем решения, ориентированные на ajax или просто html-представления.
ну если там знания html ненужны, что действительно удобнее набивать жабаскрипт-код для создания интефрейса, вместо использования визуальных редакторов для интерфейса в случае Java, Flash, Silverlight?
Не представляю себе серьёзное корпоративное приложение, сделанное на Flash/Silverlight.
На java получится десктопное приложение, а речь идёт о другом.
Код для создания интерфейса на js набивается очень и очень легко, а для ExtJS сейчас разрабатывается Adobe Air — приложение для визуального редактирования интерфейса. Сейчас пока доступна только превью-версия, ждём релиз.
На java получится десктопное приложение, а речь идёт о другом.
Код для создания интерфейса на js набивается очень и очень легко, а для ExtJS сейчас разрабатывается Adobe Air — приложение для визуального редактирования интерфейса. Сейчас пока доступна только превью-версия, ждём релиз.
Да и те же gwave, meebo.
Понравился пример со связывание данных
demo.qooxdoo.org/current/showcase/#table
Но возникает вопрос, насколько удобно совмещать работу с Quuxdoo с работой в jQuery?
demo.qooxdoo.org/current/showcase/#table
Но возникает вопрос, насколько удобно совмещать работу с Quuxdoo с работой в jQuery?
Я не вижу особого смысла в этом, кроме того, что это может быть удобно тем, что либо вы используете jquery уже, либо хорошо его знаете. Однако в qooxdoo есть свой low level API, который позволяет делать тоже самое, что позволяет jQuery. Единственное, что выглядить это будет немного по разному с т.зр. «синтаксита». Т.е. это говорит о том, что qooxdoo можно использовать и на сайте, для создания каких-либо небольших функциональных блоков, как и другие библиотеки, однако одна дает еще одно весомое преимущество — OO — классы, mixins, инерфейсы, «нормальное» наследование.
Сейчас врятли подобные продукты получат развитие(если они конечно задаются такой целью), когда лидеры завоевали рынок. Но будут появляться как грибы после дождя
Судя по первым строчкам на странице «тестовой среды» сразу заметны недостатки по сравнению с 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 может быть гораздо больше.
работаю более года с ExtJS, всегда ругался на то, что даже для создания кнопки в доме используется несколько таблиц… В Qooxdoo конечно все блочно и вроде бы нет лишних элементов, но не смотря на это как то он медленнее работает чем Ext
Ну так блоки/таблицы это не так критично — главное что и как с DOM делать. Вот в Qooxdoo для каждого элемента (тега) прописывается inline стиль, и при каждом чихе он правится (меняются значения свойств) по цепочке, то есть вместо того чтобы менять для одного элемента (ну пусть 2-3), меняется для десятков — отсюда и потери в скорости. А еще большинство элементов (можно сказать что практически все) абсолютно позиционированы, то есть вместо того чтобы дать браузеру заниматься layout'ом — этим всецело занимается фреймворк…
посмотрите на вес этого фреймворка…
Sign up to leave a comment.
Релиз Javascript фреймворка Qooxdoo 1.0