Я не вижу особого смысла в этом, кроме того, что это может быть удобно тем, что либо вы используете jquery уже, либо хорошо его знаете. Однако в qooxdoo есть свой low level API, который позволяет делать тоже самое, что позволяет jQuery. Единственное, что выглядить это будет немного по разному с т.зр. «синтаксита». Т.е. это говорит о том, что qooxdoo можно использовать и на сайте, для создания каких-либо небольших функциональных блоков, как и другие библиотеки, однако одна дает еще одно весомое преимущество — OO — классы, mixins, инерфейсы, «нормальное» наследование.
Действительно, есть разные техники повышения производительности, например widget pooling, на сайте qooxdoo, если не ошибаюсь, есть описание таких подходов (а если нет, то можно в mail list найти). Но это отностся ко всем фреймворкам.
Дело в том, что после изменения лицензии ExtJS не всегда удается использовать как в open source, так и в коммерческих проектах. Хотя в ExtJS очень много хороших решений внутри.
qooxdoo имеет LGPL/EPL лицензию и таких проблем не возникает.
Уверен, что есть много хороших фреймворков, но остановлюсь на любимом, qooxdoo.
У qooxdoo есть очень много сильных сторон, которые многим разработчиком придуться по душе. Например ООП, статические, абстрактные классы, привычное для разработчиков высокого уровня наследование, интерфейсы, mixins, мощнейшая система properties и много еще чего интересного. Надо также заметить, что над этим фреймворком трудится full-time команда и поддерживается все это очень крупной немецкой компанией 1&1, так что можно смело использовать его в своих проектах.
qooxdoo имеет двойную лицензию LGPL/EPL, что говорить о том что можно использовать практически везде, включаю коммерческие проекты.
По поводу «с производительностью там стало все намного лучше (да нет, не особо, вот тестировал примеры в Google Chrome), но вот со внутренностью наверное нет..». Все, как говорится, познается в сравнении, поэтому не буду говорить о performance (хотя у меня такой проблемы не было.), а вот «внутренности» затрону… Ребята очень сильно потрудились над 0.8 версией и переписали очень многое, layouts, widgets, theming, очень много-о-о… qooxdoo — это один из самых элегантных javascript frameworks, которые я только встречал, начиная с архтектуры и заканчивая комментированием кода и кучей документации. Я советовал бы всем посмотреть на архитекруту этой библиотеки…
В поставке этого фреймоворка еще моного чего помимо его самого… :) JavaScript code compressor, code beautifier, система сборки (которая с первого взгляда может показаться сложноватой, но при дальнейшем изучении окажется незаменимой)…
Давно хотел написать про эту библиотеку парочку статей, если кому интересно, то можно и сделать. Сам я являюсь разработчиком QxTransformer (xml->js converter, qxtransformer.org) и qooxdoo contributorом.
Dojo интересна с точки зрения новшеств, которые она предоставляет. Не более (но и не менее). Я имею в виду dojox. Даже если вы посмотрите на свою статью, то больше вы говорите о dojox нежели о core и dijit. На самом деле так и есть, это самое интересное. Вся остальная функциональность и виджеты (dojo core и dijit) есть практически везде, и на dojo демо это не выглядит впечатляюще.
Я переодически возвращаюсь к этой библиотеке, но у меня как-то с ней не клеится. В некоторых компонентах код написан плохо. Cometd client, который вы упомянули только чего стоит. Причем это наверное даже не проблемы просто кодирования, а они архитектурные.
Хотя как вы сказали ранее, что есть некоторые проблемы с получением денег по Donate кнопке, я все же попробую развить эту мысль. Основной идеей подхода является то, что в классическом способе вы просто вешаете кнопку и все. У пользователя создается ощущение(а на самом деле так и есть) что он платит за то, что уже имеет. А зачем платить за то что уже есть? А вот если построить это все с немного другим подходом:
1) Делаем список новой функциональности
2) Каждому елементу своя кнопка(ну или кнопка одна, а он просто выбирает, что для него наиболее важно) и если пользователь нажимает ее, это дает дополнительный приоритет этой функциональности перед остальными (т.е. вы реализуете эту функциональность быстрее относительно других в будущем)
При данном подходе у пользователя создается ощущение что он дотирует новую функциональность, которой еще нет, но возможно появится (если он нажмет на кнопку). И если она ему нужна, то это может стать стимулом.
Может этот подход более применим для каких либо библиотек/фреймворков, чем для сервиса. Просто как идея.
я бы порекомендовал сразу установить SpamFilter, потому как если проект онлайн, то просто замучаетесь с тикетами от ботов. http://trac.edgewall.org/wiki/SpamFilter
Так с LGPL. С LGPL вы не обязаны выпускать свое приложение под такой же лицензией, т.к. работа не является производной если вы просто используете библиотеку. Если модифицируете, то тут да. А вот с GPL - обязаны выпускать под GPL даже если просто используете библиотеку под GPL. Это еще называют вирусной природой лицензии GPL. На форуме ExtJs очень много по этому вопросу написано. Тут конечно все намного сложнее и будут модификации для opensource от команды.
а никто ничего не мутит. Это вызвало очень большой резонанс. В подавляющем большинстве это тянет за собой все. Это природа лицензии GPL. Так вот, если вы пишите проект, который использует ExtJS, весь код в котором используется библиотека должен быть выпущен под GPL.
А это уже проблема. А если он жестко связан с сервером, как в случае этого фреймвонка, то и весь бэкэнд затрагивается. Проблема не для коммерческих, здесь я этого не касаюсь. Это проблема для опенсорс проектов, которые выпущены под другими лицензиями. Все плагины, темы, доп функциональность будет выпущена под GPLv3. Большой потенциал ExtJS обеспечило комьюнити. Это факт. И точто такой же факт, что этого не было бы если бы ExtJS была бы не под LGPL до этого Хотя сейчас Jack Slocum услышал комьюнити и готовит исключения в лицензии для открытых проектов. Смена лицензии 3 раза популярности не прибавляет. В англоязычном интернете очень много об этом.
Сейчас возникли проблемы с лицензией ExtJS. Разработчики поменяли ее на с LGPL на GPLv3 в новой версии, что тянет за собой все related проекты. Советую присмотреться к этому повнимательнее прежде чем использовать в своих проектах.
А что является причиной той самой "обратной совместимости"? Ведь спецификация HTML и CSS не поменялась. Игнорирование стандартов как таковых. Почему ни от кого из производителей более ли менее популярных браузеров не слышно, что им понадобится ввести режим совместимости со старым? Потому что есть стандарты, по которым они работали и продолжают. Они исправляют ошибки, а не делают режим совместимости со сделанными.
А вообще не вижу другого варианта для IE, им придется сделать "режим обратной совместимости" со всем, что они написали до этого или продолжать в том же духе. Но радуют даже попытки.
Ну вот ребята из IE и съели. Вроде бы и стандарты хочется поддерживать, но в тоже время и от своего наследия отказаться не могут. Это и говорит, что путь был тупиковый. Отсюда и эти варианты, описаные в статье.
Кстати, вот один из проектов на qooxdoo: gmx.com. Mail system.
А проект действительно развивается быстро… И community у них очень здоровское и очень открытое, это большое преимущество.
qooxdoo имеет LGPL/EPL лицензию и таких проблем не возникает.
Что касаемо qooxdoo, код вы можете посмотреть прямо в Demo Browser (http://demo.qooxdoo.org/current/demobrowser/), просто нажав на JS Code справа.
У qooxdoo есть очень много сильных сторон, которые многим разработчиком придуться по душе. Например ООП, статические, абстрактные классы, привычное для разработчиков высокого уровня наследование, интерфейсы, mixins, мощнейшая система properties и много еще чего интересного. Надо также заметить, что над этим фреймворком трудится full-time команда и поддерживается все это очень крупной немецкой компанией 1&1, так что можно смело использовать его в своих проектах.
qooxdoo имеет двойную лицензию LGPL/EPL, что говорить о том что можно использовать практически везде, включаю коммерческие проекты.
По поводу «с производительностью там стало все намного лучше (да нет, не особо, вот тестировал примеры в Google Chrome), но вот со внутренностью наверное нет..». Все, как говорится, познается в сравнении, поэтому не буду говорить о performance (хотя у меня такой проблемы не было.), а вот «внутренности» затрону… Ребята очень сильно потрудились над 0.8 версией и переписали очень многое, layouts, widgets, theming, очень много-о-о… qooxdoo — это один из самых элегантных javascript frameworks, которые я только встречал, начиная с архтектуры и заканчивая комментированием кода и кучей документации. Я советовал бы всем посмотреть на архитекруту этой библиотеки…
В поставке этого фреймоворка еще моного чего помимо его самого… :) JavaScript code compressor, code beautifier, система сборки (которая с первого взгляда может показаться сложноватой, но при дальнейшем изучении окажется незаменимой)…
Давно хотел написать про эту библиотеку парочку статей, если кому интересно, то можно и сделать. Сам я являюсь разработчиком QxTransformer (xml->js converter, qxtransformer.org) и qooxdoo contributorом.
Я переодически возвращаюсь к этой библиотеке, но у меня как-то с ней не клеится. В некоторых компонентах код написан плохо. Cometd client, который вы упомянули только чего стоит. Причем это наверное даже не проблемы просто кодирования, а они архитектурные.
1) Делаем список новой функциональности
2) Каждому елементу своя кнопка(ну или кнопка одна, а он просто выбирает, что для него наиболее важно) и если пользователь нажимает ее, это дает дополнительный приоритет этой функциональности перед остальными (т.е. вы реализуете эту функциональность быстрее относительно других в будущем)
При данном подходе у пользователя создается ощущение что он дотирует новую функциональность, которой еще нет, но возможно появится (если он нажмет на кнопку). И если она ему нужна, то это может стать стимулом.
Может этот подход более применим для каких либо библиотек/фреймворков, чем для сервиса. Просто как идея.
А это уже проблема. А если он жестко связан с сервером, как в случае этого фреймвонка, то и весь бэкэнд затрагивается. Проблема не для коммерческих, здесь я этого не касаюсь. Это проблема для опенсорс проектов, которые выпущены под другими лицензиями. Все плагины, темы, доп функциональность будет выпущена под GPLv3. Большой потенциал ExtJS обеспечило комьюнити. Это факт. И точто такой же факт, что этого не было бы если бы ExtJS была бы не под LGPL до этого Хотя сейчас Jack Slocum услышал комьюнити и готовит исключения в лицензии для открытых проектов. Смена лицензии 3 раза популярности не прибавляет. В англоязычном интернете очень много об этом.
А вообще не вижу другого варианта для IE, им придется сделать "режим обратной совместимости" со всем, что они написали до этого или продолжать в том же духе. Но радуют даже попытки.
Статья превосходная. Спасибо.