Comments 51
Не тыкал новый дизайнер, но расскажу про его историю.
Когда 3 назад, когда ExtJS был молодой и едва ли перевалил на вторую версию, какой-то энтузиаст решил склепать простейший конструктор для основных элементов визуализации ExtJS. Ну склепал… на ExtJS. Это было очень круто, т.к. можно было уже в первых версиях сделать хоть что-то, каркас окна, панели. Проект был больше вызовом нежели практическим инструментом.
Проект рос, развивался и видимо перешел под крыло комьюнити. Раньше он кстати был совершенно халявен.
И вот он дорос до полноценной среды разработки. Вполне предсказуемы косяки такого развития (вы их явно видите). Но нужен ли такой дизайнер? За 200 баксов не уверен, может кому-то нужен, но когда он был свободным — он явно был востребован. Помогал здорово сократить время конструирования интерфейса. Собственно изначально он был рожден давать каркас, но не логику. Туго было с логикой. Проще писать ручками.
Ну и в завершение скажу по опыту работы с прадедом этого редактора. 2/3 того что вам кажется багами — это ваши ошибки в логике размещения компонентов. В ExtJS очень ядренная структура рендеров и прочей инициализации. И это все лучше расставлять ручками. Редактор обязывает делать все шаблонно и «правильно», иначе оно глючит. Это не IDE рзработчика, это просто «мастер» или конструктор.
PS Чтоб закрутить шуруп важно понимать что молоток предназначен для иных целей.
Когда 3 назад, когда ExtJS был молодой и едва ли перевалил на вторую версию, какой-то энтузиаст решил склепать простейший конструктор для основных элементов визуализации ExtJS. Ну склепал… на ExtJS. Это было очень круто, т.к. можно было уже в первых версиях сделать хоть что-то, каркас окна, панели. Проект был больше вызовом нежели практическим инструментом.
Проект рос, развивался и видимо перешел под крыло комьюнити. Раньше он кстати был совершенно халявен.
И вот он дорос до полноценной среды разработки. Вполне предсказуемы косяки такого развития (вы их явно видите). Но нужен ли такой дизайнер? За 200 баксов не уверен, может кому-то нужен, но когда он был свободным — он явно был востребован. Помогал здорово сократить время конструирования интерфейса. Собственно изначально он был рожден давать каркас, но не логику. Туго было с логикой. Проще писать ручками.
Ну и в завершение скажу по опыту работы с прадедом этого редактора. 2/3 того что вам кажется багами — это ваши ошибки в логике размещения компонентов. В ExtJS очень ядренная структура рендеров и прочей инициализации. И это все лучше расставлять ручками. Редактор обязывает делать все шаблонно и «правильно», иначе оно глючит. Это не IDE рзработчика, это просто «мастер» или конструктор.
PS Чтоб закрутить шуруп важно понимать что молоток предназначен для иных целей.
мы для себя за несколько дней написали среду разработки extJS на нем самом. Да, она генерирует только код отображения и связей между формами, но, блин… Она так не глючит! Мы ей пользуемся, хотя бы.
Вам в школе не говорили, что каждое новое предложение начинается с заглавной буквы, а в конце нужно ставить точку?
Со слов автора получается, что ExtDesigner — гуйня какая-то.
UFO just landed and posted this here
Версия под windows вполне работоспособная, сегодня поигрался — ошибки не выскакивали. 200 зеленых это не стоит конечно же, но триала на 14 дней для новичка вполне хватит что бы понять, как по быстрому наклепать каркасов в extJS, ведь исходный код доступен в соответствующей вкладке. А дальше — ручками прописываем логику для уже созданных каркасов.
P.S. Все таки я думаю эта штука должна быть бесплатной.
P.S. Все таки я думаю эта штука должна быть бесплатной.
Люди опытные, поделитесь, пожалуйста, немного конструктивными мыслями на тему выбора фремворка из ExtJS, Dojo, JQuery, Cappuccino, Prototype и т.п. На чём пишется наиболее maintainable код и красивые гуи, при интенсивной работе с данными (через PHP-бэкэнд) и web-сервисами? Заранее прошу прощения, совершенно не хочу провоцировать холивар, но надо что-то выбираь для проекта, а опыта не много в этом конкретном вопросе. Заранее спасиб за конструктив.
Если нет опыта — пощупайте каждый, хоть немного. У каждого свои возможности и, следовательно, своя область применения. Про приведенный список — сказать что один из лучше другого — по меньшей мере некорректно
красивые гуи, при интенсивной работе с данными (через PHP-бэкэнд) и web-сервисами
ExtJS, qooxdoo. Остальное из списка — небольшие библиотеки для несложного AJAX и манипуляций с DOM. Про Capuccino ничего сказать не могу, кроме того, что там какие-то махинации с неким Objective J.
ExtJS, qooxdoo
Ok. Спасибо, я так понимаю Вы знакомы и с тем и с тем? Можно в кратце основные концептуальные различия, плюсы/минусы, не что следует обратить внимание при выборе?
стальное из списка — небольшие библиотеки для несложного AJAX и манипуляций с DOM.
И Dōjō тоже? Погуглив и посмотрев сравнения я пришёл к выводу что это чуть ли не самый продвинутый JS-фреймворк.
Я думаю основное, на что нужно обратить внимание — ExtJS не бесплатна для коммерческих проектов с закрытым кодом. В остальном различия не столь существенны. Ещё qooxdoo предлагает и требует целую систему разработки с утилитами и прочим, ExtJS проще в этом смысле, можно писать традиционно: js-файл с логикой, подключаем к страничке, всё. Если готовы распространять по GPLv3 исходники, конкретно ту часть, что использует ExtJS — используйте ExtJS, лучше него только flex/silverlight. Если нужно RIA, но не устраивает GPLv3, то берите qooxdoo. Если вам не нужны виджеты и мощный GUI, то достаточно будет jQuery/любой-другой-удобной-для-вас.
Dojo имеет в составе библиотеку виджетов, но они недалеко ушли от jQuery UI или, допустим, YUI. Есть ещё полезные штуки вроде data или i18n. jQuery тоже можно довести до такого уровня плагинами :) Ещё он включён в комплект ZendFramework. Для RIA точно не годится.
Dojo имеет в составе библиотеку виджетов, но они недалеко ушли от jQuery UI или, допустим, YUI. Есть ещё полезные штуки вроде data или i18n. jQuery тоже можно довести до такого уровня плагинами :) Ещё он включён в комплект ZendFramework. Для RIA точно не годится.
Сбасибо. Очень информативно излагаете. Приятно что есть люди, готовые поделиться опытом.
А если я пишу внутрикорпоративное веб-приложение для конкретной компании под конкретную задачу или просто навороченый web-сайт? В обоих случаях не предполагается продукт как-либо распространять, это просто код на одном конкретном интранет или интернет сайте. Фирме-заказчику я исходники в соотсвтетствие с GPL дам если попросят. Я всё равно обязан этот код выложить на всеобщее обозрение либо купить коммерческую лицензию?
Ну мне совсем десктопный гуи нужен. Вот такое не нужно, нужен просто навороченый web-сайт.
Я думаю основное, на что нужно обратить внимание — ExtJS не бесплатна для коммерческих проектов с закрытым кодом.
А если я пишу внутрикорпоративное веб-приложение для конкретной компании под конкретную задачу или просто навороченый web-сайт? В обоих случаях не предполагается продукт как-либо распространять, это просто код на одном конкретном интранет или интернет сайте. Фирме-заказчику я исходники в соотсвтетствие с GPL дам если попросят. Я всё равно обязан этот код выложить на всеобщее обозрение либо купить коммерческую лицензию?
Для RIA точно не годится.
Ну мне совсем десктопный гуи нужен. Вот такое не нужно, нужен просто навороченый web-сайт.
Я всё равно обязан этот код выложить на всеобщее обозрение либо купить коммерческую лицензию?
Ну если по-честному, то должны :) Но если ваш продукт никто за пределами фирмы не увидит — то можно и не говорить никому.
нужен просто навороченый web-сайт
Как я уже написал — если сложный GUI не требуется, можно обойтись традиционными средствами. То есть jQuery с плагинами, mootools. Dojo попробовать. Вдруг он вам понравится? Каждый разработчик обычно выбирает библиотеку по наитию. Мне jQuery нравится, но это чисто субъективно, они все похожи по возможностям и идеологии. ExtJS/Qooxdoo другие. Но даже у ExtJS есть отдельная мини-библиотека ExtJS Core — она аналогична jQuery, только виджетов нет совсем. Может вам она придётся по душе. И она под лицензией MIT :)
Строго говоря всякие табы, карусельки, выпадающие меню и т.п. пишутся довольно быстро и просто даже без всяких библиотек. Просто в библиотеках уже решены проблемы с разными грабельками в разных браузерах.
Dojo тоже имеет неслабую поддержку от Zend Framework.
Попробуйте Google Web Toolkit ещё.
По скорости работы и поддержке браузерами ему ни один фреймворк из перечисленных не конкурент.
А писать надо будет не на Javascript, а на Java.
Кому-то это минус, а по мне — так плюс.
По скорости работы и поддержке браузерами ему ни один фреймворк из перечисленных не конкурент.
А писать надо будет не на Javascript, а на Java.
Кому-то это минус, а по мне — так плюс.
Еще есть Google Closure Library, но вид у нее неважнецкий. ExtJS красивее.
Я считаю, хороший интерфейс пишется ручками, с легким (никаких десятков яваскрипт и css файлов в заголовке!), хорошо сверстанным HTML-интерфейсом (а не генерируется неуклюже яваскриптом из XML), а для каких-то штук вроде аякса используется легкая (не-jQuery) библиотека + самописные функции, причем только там, где это действительно нужно.
Можно применить техники клиентской оптимизации, вроде использвоания CSS-спрайтов, сжатия/выставления кеширующих заголовков, подробьнее можно почитать на webo.in
Также стоит уделить внимание бекенду. Недопустимо, чтобы простейшие операции выполнялись по пол-секунды или больше — в сочетании с расходами на передачу по сети, загрузку доп-х файлов, рендеринг, выполнение яваскрипта это создаст у пользователя впечатление «тормознутости» интерфейса.
«Красивые» GUI не пишутся, а рисуются дизайнером в соотв-х графических редакторах.
Можно применить техники клиентской оптимизации, вроде использвоания CSS-спрайтов, сжатия/выставления кеширующих заголовков, подробьнее можно почитать на webo.in
Также стоит уделить внимание бекенду. Недопустимо, чтобы простейшие операции выполнялись по пол-секунды или больше — в сочетании с расходами на передачу по сети, загрузку доп-х файлов, рендеринг, выполнение яваскрипта это создаст у пользователя впечатление «тормознутости» интерфейса.
«Красивые» GUI не пишутся, а рисуются дизайнером в соотв-х графических редакторах.
Для проекта требовались в основном деревья и таблицы. Пробовал ExtJS, но когда припёрло написать свой виджет стало совсем невыносимо, да и с быстродействием у ExtJS не ахти если нагруженное приложение. Потом открыл для себя JQuery и понял что такое счастье, танцы с бубном закончились. Мои проблемы решили datatables и dynatree. Весит в 3 раза меньше и летает. Информацию отдавал Django'й.
Вы не совсем корректно сравниваете фреймворки.
ExtJS это очень мощная библиотека. Её можно разделить на Адаптер, Ядро и Компоненты.
Адаптер — это то, что можно сравнивать с Prototype, голым jQuery и даже YUI.
Ядро — представляет инфраструктуру для классов и абстракцию адаптера.
Компоненты — это уже конечные виджеты и прочее добро.
Адаптер можно выбрать родной ExtJS, можно Prototype, jQuery, YUI. Т.е. вы можете работать с ExtJS через Prototype, если вам эта библиотека роднее. Если вам достаточно голого prototype, jQuery и прочих подобных библиотек, то зачем подпрягать такого монстра как ExtJS? Он просто на 5% не будет даже использоваться…
А вот если вам нужна библиотека ГОТОВЫХ компонентов, то ExtJS это очень хороший выбор. Довольно гибкая штука где практически все есть для работы. Но как любой монстр — обязывает работать в стиле ExtJS.
ExtJS — рай для RAI, причем такого радикального RAI. Посмотрите демки и возможности на сайте, если вы видите то, из чего будет состоять ваш сайт — берите ExtJS. Если это вам в целом все не нужно, то на вкус выбирайте что по проще. Если выберите библиотеку, которая контачит с ExtJS, то в будущем можно и Ext подтянуть к сайту.
В общем не сравнивайте ExtJS с обычными библиотеками. Он гораздо больше. Это библиотека компонентов прежде всего. Prototype и jQuery — это библиотеки функций и инфраструктуры. Т.е. они могут быть частью ExtJS, а Ext выбирайте если вам нужны именно компоненты.
PS у ExtJS очень высокий порог вхождения, такие дела…
ExtJS это очень мощная библиотека. Её можно разделить на Адаптер, Ядро и Компоненты.
Адаптер — это то, что можно сравнивать с Prototype, голым jQuery и даже YUI.
Ядро — представляет инфраструктуру для классов и абстракцию адаптера.
Компоненты — это уже конечные виджеты и прочее добро.
Адаптер можно выбрать родной ExtJS, можно Prototype, jQuery, YUI. Т.е. вы можете работать с ExtJS через Prototype, если вам эта библиотека роднее. Если вам достаточно голого prototype, jQuery и прочих подобных библиотек, то зачем подпрягать такого монстра как ExtJS? Он просто на 5% не будет даже использоваться…
А вот если вам нужна библиотека ГОТОВЫХ компонентов, то ExtJS это очень хороший выбор. Довольно гибкая штука где практически все есть для работы. Но как любой монстр — обязывает работать в стиле ExtJS.
ExtJS — рай для RAI, причем такого радикального RAI. Посмотрите демки и возможности на сайте, если вы видите то, из чего будет состоять ваш сайт — берите ExtJS. Если это вам в целом все не нужно, то на вкус выбирайте что по проще. Если выберите библиотеку, которая контачит с ExtJS, то в будущем можно и Ext подтянуть к сайту.
В общем не сравнивайте ExtJS с обычными библиотеками. Он гораздо больше. Это библиотека компонентов прежде всего. Prototype и jQuery — это библиотеки функций и инфраструктуры. Т.е. они могут быть частью ExtJS, а Ext выбирайте если вам нужны именно компоненты.
PS у ExtJS очень высокий порог вхождения, такие дела…
Если выйдет на главную, то радикал заблочит картинки.
На выбор: habrahabr.ru/blogs/hosting/89162/ и habrahabr.ru/blogs/hosting/89338/
На выбор: habrahabr.ru/blogs/hosting/89162/ и habrahabr.ru/blogs/hosting/89338/
Ковырялся ещё когда она была публичной бетой. Похоже ничего не изменилось. Даже то, что экспортировать результат нельзя :)
extjs@conference.jabber.ru
тестируем =)
тестируем =)
ExtJS — тяжедая, тормозная и концептуально неправильная библиотека, никому не советую пользоваться.
тяжёлая, тормозная — понятно. про концептуальную неправильность можно поподробнее?
Вы всерьез ожидаете от тролля аргументов?
Например, в том, что принимается попытка в среду на DOM/Javascript перенести приемы из традиционных библиотек (например, вроде MFC или Qt, или GTK), где каждая кнопка делается отдельным объектом. мне это и в C++ то кажется излишним усложнением, а уж в яваскрипте, по моему это неразумно.
Более того, фактически этими объектами-обертками дублиуется функционал DOM'а.
Мне не нравится, так же как мне всегда не нравились такие вещи, когда например на PHP пытаются переписать Java- или C++-фреймворк — в результате обычно получается кривая и тормозная фигня. В каждой среде свои особенности, и так слепо переносить приемы — не лучший выход.
И более того, их демку, имитирующую окна Windows, тоже считаю дурной, так как нет никакого смысла дублировать виндовый рабочий стол/панель задач/окна еще и внутри окна бразера (особенно учитывая, что этот интерфейс был придуман во времена Win 95 и сегодня просто устарел).
Более того, фактически этими объектами-обертками дублиуется функционал DOM'а.
Мне не нравится, так же как мне всегда не нравились такие вещи, когда например на PHP пытаются переписать Java- или C++-фреймворк — в результате обычно получается кривая и тормозная фигня. В каждой среде свои особенности, и так слепо переносить приемы — не лучший выход.
И более того, их демку, имитирующую окна Windows, тоже считаю дурной, так как нет никакого смысла дублировать виндовый рабочий стол/панель задач/окна еще и внутри окна бразера (особенно учитывая, что этот интерфейс был придуман во времена Win 95 и сегодня просто устарел).
С задачами для «среды DOM/Javascript» (вроде всяких вебдванольных красивостей и AJAXа), прекрасно справляется Ext Core.
ExtJS же предназначен ровно для тех же задач, что и MFC, Qt и GTK. И разработчики приходят к ExtJS после MFC, Qt и GTK. Основываться на привычных для этих разработчиков подходах и копировать best practices из десктопных GUI-фреймворков — это как раз концептуально правильно.
На замечение о демке отвечать не буду. Оно не имеет никакого отношения к теме концепутальной неправильности ExtJS.
ExtJS же предназначен ровно для тех же задач, что и MFC, Qt и GTK. И разработчики приходят к ExtJS после MFC, Qt и GTK. Основываться на привычных для этих разработчиков подходах и копировать best practices из десктопных GUI-фреймворков — это как раз концептуально правильно.
На замечение о демке отвечать не буду. Оно не имеет никакого отношения к теме концепутальной неправильности ExtJS.
> Основываться на привычных для этих разработчиков подходах и копировать best practices из десктопных GUI-фреймворков — это как раз концептуально правильно.
Хаха, вот вы и попались. Этот подход — «копировать best practices» абсолютно дурной. Например, майкрософт (подозреваю, что с целью спасти толпы индусов-десктопщиков от надвигающейся безработицы) когда-то сделала имитацию «событий» в своем ASP. Стоит ли говорить, насколько кривой результат получается при попыьке перенести эти самые «best practices». До сих пор мы страдаем от глючащих без яваскрипта, плохо индексируемых, утяжеленных многокилобайтовым VIEW_STATE сайтов.
Программирование под веб имеет мало общего с программированием под WinAPI, и попытка перенести «best practices» — неудачная имхо. Хотя бы потому, что скорость выполнения Си++ и яваскрипт-кода разная, и Dom c WinAPI тоже вещи радикально различающиеся.
Это кстати не первая попытка, кроме ASP, есть еще Delphi for PHP (представляете, там тоже можно формочки рисовать!), Frontpage и Dreamveawer. Все они генерируют хлам по сравнению с работой нормального верстальщика. Веб — это не Си++ и не WinAPI, тут нуден другой подход.
Хаха, вот вы и попались. Этот подход — «копировать best practices» абсолютно дурной. Например, майкрософт (подозреваю, что с целью спасти толпы индусов-десктопщиков от надвигающейся безработицы) когда-то сделала имитацию «событий» в своем ASP. Стоит ли говорить, насколько кривой результат получается при попыьке перенести эти самые «best practices». До сих пор мы страдаем от глючащих без яваскрипта, плохо индексируемых, утяжеленных многокилобайтовым VIEW_STATE сайтов.
Программирование под веб имеет мало общего с программированием под WinAPI, и попытка перенести «best practices» — неудачная имхо. Хотя бы потому, что скорость выполнения Си++ и яваскрипт-кода разная, и Dom c WinAPI тоже вещи радикально различающиеся.
Это кстати не первая попытка, кроме ASP, есть еще Delphi for PHP (представляете, там тоже можно формочки рисовать!), Frontpage и Dreamveawer. Все они генерируют хлам по сравнению с работой нормального верстальщика. Веб — это не Си++ и не WinAPI, тут нуден другой подход.
Вы зря привязались к DOMу. Это мешает вам разглядеть в ExtJS то, чем он является. Оборачиванием DOMa занимаются jQuery, Prototype, Ext Core и подобные библиотеки. ExtJS совсем о другом.
DOM и WinAPI — вещи радикально различающиеся, но GUI-компоненты ExtJS и GUI-компоненты MFC — вещи принципиально схожие. Веб — это не C++ и не WinAPI, но и ExtJS — это не веб, это тонкие клиенты. Если бы вы в своём первом комментарии написали «не советую использовать на сайтах» вместо «никому не советую пользоваться», я бы вам и слова не сказал.
DOM и WinAPI — вещи радикально различающиеся, но GUI-компоненты ExtJS и GUI-компоненты MFC — вещи принципиально схожие. Веб — это не C++ и не WinAPI, но и ExtJS — это не веб, это тонкие клиенты. Если бы вы в своём первом комментарии написали «не советую использовать на сайтах» вместо «никому не советую пользоваться», я бы вам и слова не сказал.
Где каждая кнопка делается отдельным объектом.
А по-моему это здóрово. По идее олжно повышать maintainability кода.
нет никакого смысла дублировать виндовый рабочий стол/панель задач/окна еще и внутри окна бразера (особенно учитывая, что этот интерфейс был придуман во времена Win 95 и сегодня просто устарел).
А вот тут согласен. По-моему это скорее понт просто, демонстрация возможностей, а не решение для жизни.
Тяжелая ~600кб
А тормознутость в чем заключается?
А тормознутость в чем заключается?
Ну вообще на сложных конфигурациях с большим количеством вложенных элементов наблюдается подтормаживание при пересчете лейаутов, особенно если компоненты тяжелые.
В том, что создается субъективное ощущение «тормознутости» при загрузке страницы, браузер явно как-то хуже работает со сложными приложениями с окнами и прочей ерундой.
Justadreamer: на столе стоят рядом миска с орешками и чай, хотела орешков зачерпнуть, сунула руку в чашку с чаем и сижу задумчиво, лимон щупаю…
На виндах ситуация с ошибками получше, но суть та же.
Призванный облегчить построение extJs приложений он со своей задачей (облегчить) не справляется.
Не ожидал от Ext такой сырости в релизе 1.0.
Призванный облегчить построение extJs приложений он со своей задачей (облегчить) не справляется.
Не ожидал от Ext такой сырости в релизе 1.0.
кратко о своём опыте общения с Ext Designer:
в Kubuntu x64 вылетала при сохранении и открытии проекта. пришлось потестить в винде. маленький баг который увидел это когда к гриду привязываешь дата стор, а потом потребовалось сменить у стора id то вылетела ошибка и дизайнер упал.
а вообще работает вполне мило и шустро.
в Kubuntu x64 вылетала при сохранении и открытии проекта. пришлось потестить в винде. маленький баг который увидел это когда к гриду привязываешь дата стор, а потом потребовалось сменить у стора id то вылетела ошибка и дизайнер упал.
а вообще работает вполне мило и шустро.
Пусть оффтоп, но все-таки:
искал давеча js-фреймворк для создания GUI. Ну, смотрел ExtJS, ясное дело. Смутила вся эта коммерческая направленность и стремные лицензионные условия (и цены на коммерческие лицензии). Потом нашел вот такую прикольную штуку: www.sproutcore.com/ — кто-нибудь имеет опыт работы с ней? Было бы любопытно сравнение с ExtJS почитать для выполнения аналогичных задач. В любом случае, даже несмотря на возможный недостаток функционала, подкупает лицензией MIT — можно использовать и в хвост, и в гриву.
искал давеча js-фреймворк для создания GUI. Ну, смотрел ExtJS, ясное дело. Смутила вся эта коммерческая направленность и стремные лицензионные условия (и цены на коммерческие лицензии). Потом нашел вот такую прикольную штуку: www.sproutcore.com/ — кто-нибудь имеет опыт работы с ней? Было бы любопытно сравнение с ExtJS почитать для выполнения аналогичных задач. В любом случае, даже несмотря на возможный недостаток функционала, подкупает лицензией MIT — можно использовать и в хвост, и в гриву.
Я юзаю оперу и примеры из этой библиотеки на ней не запускались. Наверно они все-таки поторопились с релизом… Все-таки sproutcore очень молодой проект и во многом отстает от extjs. Но перспективы радужные, да :)
На 10.51 у меня все запускается и работает нормально. На более старых не проверял… Вы на какой тестили? Мне как раз для оперы и надо — планирую использовать для построения интерфейса для ТВ-приставок, а там именно оперные движки большей частью…
Вообще, поддержку Оперы они заявляют… А в google groups люди пишут, что в Опере не работает только частично CSS и XHR. Ну, CSS и поправить можно, а XHR мне для моих целей все равно переписывать придется в пользу JSONP или как там его…
В любом случае, лицензионная политика ExtJS просто не оставляет выбора. Я в инете начитался, что их за это многие ругают…
Вообще, поддержку Оперы они заявляют… А в google groups люди пишут, что в Опере не работает только частично CSS и XHR. Ну, CSS и поправить можно, а XHR мне для моих целей все равно переписывать придется в пользу JSONP или как там его…
В любом случае, лицензионная политика ExtJS просто не оставляет выбора. Я в инете начитался, что их за это многие ругают…
Собственно проблемы с CSS на лицо. Не поленился, сейчас установил и библиотеку и демо-примеры, запустил sc-server для sproutcore-samples. В Опере (10.51 WinXP) некорректно отображается главное меню выбора. Кстати, такой баг наблюдался еще в бете, но раз до сих пор в таком месте не исправили, то каких еще косяков ждать от либы (сарказм :) )
Еще есть Qooxdoo. Говорят, что они старше, чем Ext JS.
Принципиальных преимуществ или недостатков по сравнению с Ext JS не имеет. В каких-то мелочах выигрывает, в каких-то проигрывает. Распространяется по LGPL.
Образцы элементов интерфейса:
demo.qooxdoo.org/current/showcase/
Синтетические примеры:
qooxdoo.org/demo (идут в два столбца)
Скриншоты продуктов на базе этого фреймворка:
qooxdoo.org/community/real_life_examples
Принципиальных преимуществ или недостатков по сравнению с Ext JS не имеет. В каких-то мелочах выигрывает, в каких-то проигрывает. Распространяется по LGPL.
Образцы элементов интерфейса:
demo.qooxdoo.org/current/showcase/
Синтетические примеры:
qooxdoo.org/demo (идут в два столбца)
Скриншоты продуктов на базе этого фреймворка:
qooxdoo.org/community/real_life_examples
поддерживаю автора, пробовал — сыровато
Фотки на радиКАЛе. Скоро все отключат. Ваши ставки господа :)
Sign up to leave a comment.
ExtDesigner — щупаем ручками