Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
>Или пишут тебе пользователи — у нас не грузится таблица. Открываешь — и правда, не грузится. Вчера грузилась, а сегодня нет, притом, что в этом месте ты ничего не менял.
1. Чудес на свете не бывает.
2. Не менял в этом месте, значит менял в другом.
1. Чудес на свете не бывает.
2. Не менял в этом месте, значит менял в другом.
Сколько Вы проработали с ExtJS?
что «undefined» где-то глубоко в недрах ExtJSА как же стектрейс?
А стектрейс ничего не говорит, т.к. атрибут не указан в конструкторе, а ошибка произошла при вызове какого-нибудь метода…
А стектрейс тоже вложен раз десять, причем там только модули самой библиотеки, твоих нет
Стыдно сказать, но я банальное приложение писал с нуля почти неделю, страдая при этом резкими перепадами настроения.
ну так справка же есть доки, sencha.com, архитект в котором можно приложение создать перетаскав мышкой элементы а потом посмотреть код.
Статья не объективна.
Диагностика очень часто крайне загадочна и только после пары месяцев ты начинаешь догадываться, что «undefined» где-то глубоко в недрах ExtJS означает пропущенный атрибут Store при описании выпадающего списка.
`debugger;`, «Break On All Errors» (FireBug), «Pause on all exceptions» (Web Inspector) или `try{ } catch(error){ console.log(error.stack) }`, не?
Вы бы полотно текста скринами хотя-бы разбавили. Я уже не говорю про разбиение текста на разделы. Если хотите донести свою мысль, потрудитесь привести примеры, которые поддерживают ваши утверждения, и насколько легче это было-бы на технологии X.
Как образец объективной и понятной критики — почитайте «PHP — фрактал плохого дизайна».
Как образец объективной и понятной критики — почитайте «PHP — фрактал плохого дизайна».
Очень странная статья. Уже второй год использую четвертую версию и таких проблем не обнаружил.
В самом коде библиотеки ошибки есть и они легко вылавливаются стандартными методами. Я даже кучку хаков написал с исправлениями. И разработчикам высылаю. Но ошибок в системе очень мало.
Освоить систему очень просто, там есть руководство по созданию MVC-приложения и оно вполне добротное. Для начала пойдет. И оно написано про четвертую версию! А никак не про третью. Также есть демо-примерчики. Они очень хорошо показывают приемы работы. Их даже слишком много. Я до сих не все освоил.
Отладка ничем не отличается от отладки JS-приложений. Есть три версии библиотеки: нормальная, debug и develop (последняя более удобно при отладке, так как сообщения более информативны).
Система работает надежно. Никаких сбоев не наблюдал ни разу. Разве что переход на новые версии конечно не без фокусов.
Работает и загружается весьма быстро.
Банальное приложение писать неделю можно если а) не знаешь английский язык, б) мало опыта с JavaScript. Иначе не поверю что неделю можно писать свое первое приложение.
В самом коде библиотеки ошибки есть и они легко вылавливаются стандартными методами. Я даже кучку хаков написал с исправлениями. И разработчикам высылаю. Но ошибок в системе очень мало.
Освоить систему очень просто, там есть руководство по созданию MVC-приложения и оно вполне добротное. Для начала пойдет. И оно написано про четвертую версию! А никак не про третью. Также есть демо-примерчики. Они очень хорошо показывают приемы работы. Их даже слишком много. Я до сих не все освоил.
Отладка ничем не отличается от отладки JS-приложений. Есть три версии библиотеки: нормальная, debug и develop (последняя более удобно при отладке, так как сообщения более информативны).
Система работает надежно. Никаких сбоев не наблюдал ни разу. Разве что переход на новые версии конечно не без фокусов.
Работает и загружается весьма быстро.
Банальное приложение писать неделю можно если а) не знаешь английский язык, б) мало опыта с JavaScript. Иначе не поверю что неделю можно писать свое первое приложение.
Я даже кучку хаков написал с исправлениями. И разработчикам высылаю. Но ошибок в системе очень мало.А после каждого релиза переписываете свои хаки? :)
Ошибок хоть и мало, но самому пофиксить их сложно — только если полностью переписать код компонент. Чего только стоит кривой скроллинг в гриде, который исправили только в 4.1.1. Баг в рендерере ячеек таблиц не пофиксили до сих пор, хотя на форуме обещали исправить ещё к версии 4.0.7.
Да, пожалуй единственная проблема ExtJs — это достаточно большое количество мелких багов, всё время приходится писать хаки и да, они ломаются от версии к версии. Жаль, что нет ExtCore 4 под открытой лицензией.
Да, иногда хаки приходится переписывать (на то они и хаки, чтобы переписывать).
Баги в любой системе есть. Не вижу смысла на них жаловаться. Тем более что лучше Ext ничего нет.
Есть смысл написать книжку как программировать под Ext. Есть смысл написать свою библиотеку исправлений каждого релиза.
Баги в любой системе есть. Не вижу смысла на них жаловаться. Тем более что лучше Ext ничего нет.
Есть смысл написать книжку как программировать под Ext. Есть смысл написать свою библиотеку исправлений каждого релиза.
Я перевел с английского языка книжку по экономике в 500 страниц и работаю с JS лет десять. Более адекватные предположения будут?
При подключении страницы в браузер грузится около 6 мегабайтов всякого добра и это время весьма и весьма заметно.
Вы сборщиком пользовались? С трудом представляю, чего такого можно было понаписать, чтобы собраный код был около 6 мегабайт.
Поэтому любой экран, всего с парой контролов, — это длиннющая портянка декларативного кода, со структурами, многократно вложенными друг в друга. Искать при таких условиях, в каком месте стоит лишняя скобка — это ад.Разбейте создание контролов на функции, вызывайте их последовательно в initComponent(), примерно так:
initComponent: function() {
var form = this._createForm();
var mainGrid = this._createMainGrid();
var contextGrid = this._createContextGrid();
this.items = [form, mainGrid, contextGrid];
this.tbar = this._createToolbar();
this.callParent(arguments);
}
Из-за жутко медленной загрузки невозможно программировать моим любимым способом, которому я научился еще от Форта — мелкими правками. Вносишь одно изменение, смотришь результат, правишь. Повторить. Так не получается — пока этот слон загрузится после каждого изменения, забываешь, что хотел сделать.Может, у вас сервер где-то далеко?
У меня в локальной сети приложение с неминимированной дебаг-версией библиотеки со всеми комментариями и несколькими десятками собственных компонент при включенном файрбаге загружается секунд за 10 (onload: 6.46s).
Саму ExtJs-библиотеку грузить каждый раз, кстати, не нужно — отдавайте 304 Not Modified, она же не меняется при ваших правках.
Приложение в продакшене с минимированными библиотеками грузится меньше секунды — там больше времени уходит на рендеринг, если машина слабая.
В библиотеке есть ошибки. Не очень много, но есть.Это да :(
Причём некоторые ошибки эти не фиксятся подолгу, несмотря на обещания на форуме пофиксить в следующей версии. А в 4.2 полностью переделали Grid, так что работающие в версии 4.1.1 страницы с ним даже не рендерятся :)
Не лучше обстоит дело и с твоими собственными ошибками. Диагностика очень часто крайне загадочна и только после пары месяцев ты начинаешь догадываться, что «undefined» где-то глубоко в недрах ExtJS означает пропущенный атрибут Store при описании выпадающего списка.Для откладки желательно использовать полную debug-версию с комментариями, иначе получаешь в консоли "b is undefined" вместо сообщения об ошибке :)
Исходя из своего двухлетнего опыта использования ExtJs в следующем подобном intranet-проекте со сложным UI я предпочту ExtJs, так как со всеми багами я уже знаком и мне
Собственно, а какие альтернативы есть для ExtJs? Dojo? YUI?
А где Вы взяли версию 4.2?
>Собственно, а какие альтернативы есть для ExtJs? Dojo? YUI?
Ммммм… qooxdoo?
Ммммм… qooxdoo?
Ещё есть Kendo UI (на jQuery). GPL v3
Да, некоторое время пользовался ExtJS, очень не хватало обычного jquery, в частности для ajax запросов. Начал смотреть альтернативы, остановился на kendo. Проект ещё достаточно молод и, соответственно, имеет недостатки, в частности ExtJS функционально мощнее будет. Но kendo отлично дружит с jquery и визуально симпатичнее.
С лицензией примерно то же самое, GPL3 для «базовых» возможностей, дополнительный библиотеки — платные.
ExtJS также был сложен в понимании, мне кажется главная проблема — слишком большая зависимость моего javascript стиля кодирования от jquery.
С лицензией примерно то же самое, GPL3 для «базовых» возможностей, дополнительный библиотеки — платные.
ExtJS также был сложен в понимании, мне кажется главная проблема — слишком большая зависимость моего javascript стиля кодирования от jquery.
Любопытно будет посмотреть SmartClient
www.jeasyui.com/ — изумительное решение.
У меня грузится 11 секунд вместе с данными. Это достаточно много.
a) Грузить файлы на страницу по отдельности — плохо. Конкатенировать и сжимать.
b) Учить ext не трудно. У них одна из самых потрясающих документаций, что я видел.
c) ext не создан для hello world. Он создан для больших приложений, и его структура поддерживает порядок как нельзя лучше.
Описаные далее проблемы вообще не проблемы фреймворка.
b) Учить ext не трудно. У них одна из самых потрясающих документаций, что я видел.
c) ext не создан для hello world. Он создан для больших приложений, и его структура поддерживает порядок как нельзя лучше.
Описаные далее проблемы вообще не проблемы фреймворка.
Мне нужно написать красивый веб-интерфейс...
Приложение интранетноое, поэтому красота особенно не нужна.
Если знакомы с Java, попробуйте Vaadin.
Очень простая и удобная библиотека.
Только надо понимать что она «серверсайд», у многих из-за непонимания этого проблемы и претензии на ровном месте.
Очень простая и удобная библиотека.
Только надо понимать что она «серверсайд», у многих из-за непонимания этого проблемы и претензии на ровном месте.
Мои 3 копейки.
Для своего проекта (инструмент на данный момент для внутреннего пользования, но с перспективой открыть доступ другим компаниям нашей области) несколько месяцев назад выбрал ExtJS4. До этого полтора года разрабатывалось все на html+jquery. Пошёл на это, т.к. понял, что очень большая часть времени уходит на разработку всяких панелек/деревьев/кнопок/гридов/тулбаров и т.д. — всего того, что в эксте — из коробки.
Согласен, что многие из описаных проблем — имеют место быть. Онако, все они решаемы, если потрудиться. Уж простите, но всякие отступы/скобки и т.д. — это смешно. Освойте нормальный редактор с подсветкой, проверкой парности и т.д. Быстро открыть нужный файл — это тоже к удобству редактора. Меня это — несколько кнопок. У меня эту ситуацию сильно облегчает CoffeeScript, на котором всё и написано.
6 мег. Это откуда? У меня на странице один js-файл экста, который зипуется на сервере и кэшируется браузером и весит на порядок меньше 6М. И второй с моим приложением, который при деплое автоматом собирается, чистится, жмётся и так же отлично кэшируется (спасибо Rails).
«Ничего не трогал, а оно сломалось» — это уже простите, как заметили выше — магии не бывает. Набирайтесь опыта и осваивайте технологии тестирования — помогает.
Как и любой инструмент, ExtJS 4 — не идеален, но при этом вполне добротный инструмент для решения определенного круга проблем, который надо уметь готовить. Ну и при этом, насколько мне известно, по сути, не имеющий альтернатив.
Для своего проекта (инструмент на данный момент для внутреннего пользования, но с перспективой открыть доступ другим компаниям нашей области) несколько месяцев назад выбрал ExtJS4. До этого полтора года разрабатывалось все на html+jquery. Пошёл на это, т.к. понял, что очень большая часть времени уходит на разработку всяких панелек/деревьев/кнопок/гридов/тулбаров и т.д. — всего того, что в эксте — из коробки.
Согласен, что многие из описаных проблем — имеют место быть. Онако, все они решаемы, если потрудиться. Уж простите, но всякие отступы/скобки и т.д. — это смешно. Освойте нормальный редактор с подсветкой, проверкой парности и т.д. Быстро открыть нужный файл — это тоже к удобству редактора. Меня это — несколько кнопок. У меня эту ситуацию сильно облегчает CoffeeScript, на котором всё и написано.
6 мег. Это откуда? У меня на странице один js-файл экста, который зипуется на сервере и кэшируется браузером и весит на порядок меньше 6М. И второй с моим приложением, который при деплое автоматом собирается, чистится, жмётся и так же отлично кэшируется (спасибо Rails).
«Ничего не трогал, а оно сломалось» — это уже простите, как заметили выше — магии не бывает. Набирайтесь опыта и осваивайте технологии тестирования — помогает.
Как и любой инструмент, ExtJS 4 — не идеален, но при этом вполне добротный инструмент для решения определенного круга проблем, который надо уметь готовить. Ну и при этом, насколько мне известно, по сути, не имеющий альтернатив.
Есть платная и бесплатная (GNU GPL license v3) лицензии.
> Уж простите, но всякие отступы/скобки и т.д. — это смешно. Освойте нормальный редактор с подсветкой, проверкой парности и т.д
Вам не приходилось по срочному звонку править код через фтп-соединение на сервере где нету vim, в каком-нибудь редакторе без подсветки и прочих плюшек? Хорошая IDE необходима, конечно. Но оправдывать плохую структуру кода тем, что есть софт который может решить эти проблемы — как то не совсем верно.
Вам не приходилось по срочному звонку править код через фтп-соединение на сервере где нету vim, в каком-нибудь редакторе без подсветки и прочих плюшек? Хорошая IDE необходима, конечно. Но оправдывать плохую структуру кода тем, что есть софт который может решить эти проблемы — как то не совсем верно.
«Предполагается, что у вас будет глобальный контроллер для каждой сущности и совершенно невозможно с его помощью написать какой-то самодостаточный виджет, который можно было бы потом вставлять куда хочешь.»
Никаких проблем для созданія самодостаточних віджетов при использовании MVC нет
Никаких проблем для созданія самодостаточних віджетов при использовании MVC нет
Вы сейчас описали весь ужас, который испытывает разработчик, когда с jq переходит на ext =) Поработайте пол года, а лучше год, потом расскажите как оно. Лично я сам так же первое время мучался, когда ломался мозг в попытках принять новые абстракции и концепции. Но когда понимаешь и принимаешь, то приходит просветление и разрабатывать становится просто и быстро. Из всех недостатков, которые вы перечислили, только ошибки в коде являются проблемой. Всё остальное — от непонимания.
Пользуюсь extjs и плагинами с первых и даже нулевых версий, доволен всем. По поводу тормозов, — на современных машинах загрузка не отличается от загрузки чего-то более легкого, за то по функционалу врядли найдется какой либо другой фреймворк.
Можно, правда, описывать какие-то вложенные сущности на манер «один ко многим», но эти дополнительные данные только читаются — записать их нельзя, что делает всю затею бесполезной.
Это первое, что расстраивает при первом знакомстве. И я, удручённый, допилил комплексную отправку модели и всех её ассоциаций обратно на сервер. И, о чудо, теперь можно загрузить сложную структуру и править её в реальном времени! Отзывчивость UI будет, уууххх! Мы так и делали, а пустя некоторое время, я понял, что выстрелил себе в ногу :)
Например, есть некая модель пользователя, а у него есть список контактов и куча других ассоциаций. Редактируем один контакт, и отправляем пользователя обратно на сервер обновиться. Сервер в ответ возвращает новую структуру, которая уже никак не связана с записью, которая сейчас всё ещё открыта на редактирование. Ведь, фактически, это json, который пропустили через Reader, который, в свою очередь, выдал набор инстансов модели. Если тупо взять и положить их обратно в коллекцию, то получится, что в редакторе находится ссылка на устаревшую запись. Самый проблемный случай — когда мы добавляем несколько записей, те отправляем модели без идентификатора, чтобы сервер знал, что это записи на добавление. Если ничего не сделать, то при повторном нажатии на заветный Save, сервер может решить, что вы добавляете ещё одну запись в контакты, а возможно и удаляете только что созданый (ведь его нет в коллекции, верно?) Чтобы решить проблему, прошёл через муки реализации синхронизации данных…
В любом случае, Ext рекомендует использовать отдельные сервисы для CRUD операций над коллекциями (Ext.data.Store, если быть точным) и тогда проблем не будет. Загрузили данные в коллекцию, вытащили запись, обновили, store.sync() и горя не будет. Я был молод, горяч и не прислушался, теперь сильно сожалею :) Вообще, в ExtJS все решения достаточно логичны, чтобы убедиться, стоит только самому реализовать недостающую функциональность. Зачастую, становится понятно, что вот они, эти грабли, которые обошли ребята из сенчи :)
В моем профиле стоит дата Join Date 5 Jul 2007, именно тогда я взял Premium и начал активно использовать ExtJS.
(На тот момент было много нововведений и фиксов, которые не были доступны в публичном доступе.)
ExtJS — целый мир, своя идеология. Иногда приходилось тратить часы для создания элементов, которые можно было бы отрисовать за 5 минут.
В целом была создана достаточно обширная система, унифицированная и масштабируемая.
Небольшие примеры из прошлого (надеюсь несколько thumbnails никому не помешают):
1. Как сейчас модно Dashboard
2. Просмотров записей (новостей, статей и т.п.)
3. Контекстное меню на запись
4. Редактирование записи
5. Настройки системы (динамические формы)
Конечно, что было раньше и сейчас — небо и земля. Большинство расширений только создавалось, тестировалось, при обновлении ExtJS приходилось переписывать свой app. Сейчас многие расширения уже вошли в основную библиотеку, все отлажено и оттестировано.
Но… на данный момент я всецело и полностью отказался от прекрасного ExtJS (без иронии) и нисколько не жалею.
ПС: извиняюсь за длинный пост.
(На тот момент было много нововведений и фиксов, которые не были доступны в публичном доступе.)
ExtJS — целый мир, своя идеология. Иногда приходилось тратить часы для создания элементов, которые можно было бы отрисовать за 5 минут.
В целом была создана достаточно обширная система, унифицированная и масштабируемая.
Небольшие примеры из прошлого (надеюсь несколько thumbnails никому не помешают):
1. Как сейчас модно Dashboard
2. Просмотров записей (новостей, статей и т.п.)
3. Контекстное меню на запись
4. Редактирование записи
5. Настройки системы (динамические формы)
Конечно, что было раньше и сейчас — небо и земля. Большинство расширений только создавалось, тестировалось, при обновлении ExtJS приходилось переписывать свой app. Сейчас многие расширения уже вошли в основную библиотеку, все отлажено и оттестировано.
Но… на данный момент я всецело и полностью отказался от прекрасного ExtJS (без иронии) и нисколько не жалею.
ПС: извиняюсь за длинный пост.
Самого интересного не написали — так почему отказались от ExtJS?
Честно — надоело.
Захотелось вернуться, когда каждый пиксель можно отрисовать в нужном месте с требуемой функциональностью, что на ExtJS порой требует больших трудозатрат.
Выше я привел снимки экрана стандартизированных элементов. К примеру, чтобы создать новый модуль в системе, достаточно было бы занести параметры конфигурации и он получал целый ряд стандартизированных элементов управления (деревья, спики, формы, контектсные меню, режимы отображения, мульти-загрузка файлов и т.п.), т.е. некий фреймворк внутри ExtJS, но когда дело доходит до сильно кастомных интерфейсов под задачи отличные, от создания CMS, то… или тратить t * K времени на модификацию и написание extensions под ExtJS (где K — коэффициент, прямо пропорциональный полету фантазий заказчика) или отказываться от ExtJS.
Захотелось вернуться, когда каждый пиксель можно отрисовать в нужном месте с требуемой функциональностью, что на ExtJS порой требует больших трудозатрат.
Выше я привел снимки экрана стандартизированных элементов. К примеру, чтобы создать новый модуль в системе, достаточно было бы занести параметры конфигурации и он получал целый ряд стандартизированных элементов управления (деревья, спики, формы, контектсные меню, режимы отображения, мульти-загрузка файлов и т.п.), т.е. некий фреймворк внутри ExtJS, но когда дело доходит до сильно кастомных интерфейсов под задачи отличные, от создания CMS, то… или тратить t * K времени на модификацию и написание extensions под ExtJS (где K — коэффициент, прямо пропорциональный полету фантазий заказчика) или отказываться от ExtJS.
да, действительно, почему отказались?
Могу порекомендовать автору поработать с ExtJS 3.3 — 3.4 версии. Если грубо говорить то 3 версия это набор кирпичей, а 4 это уже готовые здания из этих кирпичей. В первом случае hello word будет существенно быстрей работать и на много меньше времени занимать, но вот app = {} сами будете проектировать. Выбор за вами.
Пользуюсь ExtJS уже около трех лет. Не могу не ответить на Ваш пост.
Вы, случайно, не ext-all-debug-w-comments.js используете? Иначе я не могу могу понять откуда у Вас такой объем данных. Глянул на свой достаточно большой проект на ExtJS, в котором кроме него еще используется OpenLayers + HighCharts. Всего 2 мегабайта получилось.
Либо у Вас совсем плохо с английским, либо Вы очень плохо искали: docs.sencha.com/ext-js/4-1/#!/guide/getting_started. Достаточно большой объем информации, которого вполне достаточно чтобы понять что к чему. Плюс куча готовых примеров.
Попробуйте написать какой-нибудь простенький компонент из ExtJS на чистом JavaScript, да так, чтобы оно во всех браузерах работало. Вот тут я думаю будет повод биться об стену.
В ExtJS есть связи 1 к 1 и 1 ко многим. С записью там тоже все порядке. Нужно только правильно связать модели и указать для них прокси.
Помню на первом курсе института писали GUI приложение на Assembler'е под Windows. Вот там было «Но как он описывается, господи.» А для ExtJS есть Sencha Architect, в котором можно очень быстро накидать любую формочку и т.д. При условии, что Вы умеете работать с менеджерами расположения.
Возможно Вам нужно дробить вьюшки на более мелкие компоненты? Когда я делаю какую-то формочку или какой-то грид, то я просто создаю новый компонент, который наследую от Ext.grid.Panel или Ext.form.Panel и т.д. и ложу в отдельный файл. Да и к тому же если в приложении нужно одну и ту же фомочку заюзать в несколких местах, достаточно добавить
и в нужном месте вставить
Пожалуй единственный абзац, с которым можно согласиться и то не полостью. Ошибки есть. Не всегда быстро удается выявить причину. Но вот с правкой особых проблем нет. Всегда можно написать какой-нибудь override для стандартного компонента. Вот с обновлением на новую версию все гораздо печальнее.
Если что-то где-то сломалось, значит все-таки что-то где-то изменилось.
В целом мне кажется, что статья очень субъективная. Я не являюсь фанатом этого фреймворка, и не берусь его защищать, но мне кажется что с задачами, для которых он создан, он справляется весьма успешно.
При подключении страницы в браузер грузится около 6 мегабайтов всякого добра и это время весьма и весьма заметно.
Вы, случайно, не ext-all-debug-w-comments.js используете? Иначе я не могу могу понять откуда у Вас такой объем данных. Глянул на свой достаточно большой проект на ExtJS, в котором кроме него еще используется OpenLayers + HighCharts. Всего 2 мегабайта получилось.
Учить ExtJS жутко трудно. Она огромная, непонятно с чего начинать. Учебники и книжки в основном относятся к третьей версии, а она, в свою очередь, мало похожа на версию 4, в которой почти все сделано по-другому. По этой же причине почти бесполезны форумы, ибо все, что там написано, давно устарело.
Либо у Вас совсем плохо с английским, либо Вы очень плохо искали: docs.sencha.com/ext-js/4-1/#!/guide/getting_started. Достаточно большой объем информации, которого вполне достаточно чтобы понять что к чему. Плюс куча готовых примеров.
Стыдно сказать, но я банальное приложение писал с нуля почти неделю, страдая при этом резкими перепадами настроения. Мне все время хотелось биться головой об стену — непонятно было абсолютно все. Ни одну технологию я с такими страданиями не учил.
Попробуйте написать какой-нибудь простенький компонент из ExtJS на чистом JavaScript, да так, чтобы оно во всех браузерах работало. Вот тут я думаю будет повод биться об стену.
В 4 версии ваше приложение должно быть сделано по принципу MVC. На практике это означает, что даже hello world будет состоять из десятка файлов, разложенных по нескольким разным каталогам. И прежде чем приступить к программированию любой задачи, эти файлы надо будет создать и разложить.Ну во первых ваше приложение никому и ничего не должно. Вы можете написать его точно так же как и в третьей версии. Вот только когда оно разрастется будет очень грустно. Про десяток файлов, думаю вы тоже преувеличили: app.html, app.js, контроллер и представление.
С данными тоже не все благополучно. Хранилище предполагает, что все данные всегда совершенно однородны. Можно, правда, описывать какие-то вложенные сущности на манер «один ко многим», но эти дополнительные данные только читаются — записать их нельзя, что делает всю затею бесполезной.
В ExtJS есть связи 1 к 1 и 1 ко многим. С записью там тоже все порядке. Нужно только правильно связать модели и указать для них прокси.
Описание интерфейса — это нечто. Он описывается чисто декларативно — и это плюс. Но как он описывается, господи. С помощью декларации данных Яваскрипта — а видов данных там немного, массивы да хеши. Поэтому любой экран, всего с парой контролов, — это длиннющая портянка декларативного кода, со структурами, многократно вложенными друг в друга.
Помню на первом курсе института писали GUI приложение на Assembler'е под Windows. Вот там было «Но как он описывается, господи.» А для ExtJS есть Sencha Architect, в котором можно очень быстро накидать любую формочку и т.д. При условии, что Вы умеете работать с менеджерами расположения.
Поэтому любое изменение интерфейса или кода, даже исправление грамматической ошибки, обязательно предполагает долгий розыск того места, где, собственно надо править.
Возможно Вам нужно дробить вьюшки на более мелкие компоненты? Когда я делаю какую-то формочку или какой-то грид, то я просто создаю новый компонент, который наследую от Ext.grid.Panel или Ext.form.Panel и т.д. и ложу в отдельный файл. Да и к тому же если в приложении нужно одну и ту же фомочку заюзать в несколких местах, достаточно добавить
requires: ['MyApplication.view.MyForm'] и в нужном месте вставить
{
xtype: 'myform'
}
В библиотеке есть ошибки. Не очень много, но есть. Однако из-за общей сложности они превращаются в кошмар — их невозможно никак исправить. Непонятно, от чего они происходят, непонятно, что надо изменить, непонятно, вообще в чем дело.
Пожалуй единственный абзац, с которым можно согласиться и то не полостью. Ошибки есть. Не всегда быстро удается выявить причину. Но вот с правкой особых проблем нет. Всегда можно написать какой-нибудь override для стандартного компонента. Вот с обновлением на новую версию все гораздо печальнее.
Или пишут тебе пользователи — у нас не грузится таблица. Открываешь — и правда, не грузится. Вчера грузилась, а сегодня нет, притом, что в этом месте ты ничего не менял.
Если что-то где-то сломалось, значит все-таки что-то где-то изменилось.
В целом мне кажется, что статья очень субъективная. Я не являюсь фанатом этого фреймворка, и не берусь его защищать, но мне кажется что с задачами, для которых он создан, он справляется весьма успешно.
так и не понял, есть ли альтернатива EXTJS?
Написали же в коментах:
kendoui.com
www.smartclient.com
demo.qooxdoo.org
dojotoolkit.org/
yuilibrary.com/yui/quick-start/
kendoui.com
www.smartclient.com
demo.qooxdoo.org
dojotoolkit.org/
yuilibrary.com/yui/quick-start/
w2ui.com/web/ вот еще.
Да все это я видел, просто не понятно полноценные ли это альтернативы?
Да все это я видел, просто не понятно полноценные ли это альтернативы?
Посмотрел мельком грид библиотеки kendoui.com. Реализация ужасная. Скролл не виртуальный, а нативный (через scrollTop). А это означает, что грид рендерит сразу все подгружаемые строки. Теперь представьте ситуацию, когда в синхронном режиме вам нужно работать с 1000 строками без paging. Возможно в этой бибилиотеке есть другой грид, но этот — точно не конкурент гриду ExtJs. Еще посмотрел разметку ячеек. Судя по разметке, ячейки особо стилизовать нельзя, что тоже не есть хорошо.
А это www.smartclient.com/#fetchOperationFS по моему мнению вообще плагиат на ExtJs
Я отвечал на вопрос «есть ли альтернативы ExtJS», а не на вопрос: «Есть ли альтернативы, которые по мнению deser имеют прекрасную реализацию и не являются плагиатом на ExtJS» ;-)
Как и у некоторых других отписавшихся, в период знакомства с Ext JS и написания первых приложений, я был не раз близок к отчаянию из-за той самой крутой кривой обучения, непонятных ошибках, новых для меня концептов в их архитектуре. Но, действительно, с получением опыта, в голове у меня все более-менее разложилось по полочкам, и на уровне пользователя Ext JS (в противопоставление создателю новых компонент) я себя чувствую более чем комфортно. Но мне сильно не хотелось бы влезать на уровень рендеринга их компонент, HTML & CSS — считаю, это требует уже значительно больших знаний, чем есть у меня.
Что меня лично начало смущать в работе после того, как я достаточно свыкся с Ext JS, это как красиво привязывать Ext JS к серверной части. REST — это круто, но… даже для него нужна куча серверного кода, в моем случае контроллеров Ruby on Rails. Просто представьте себе, что нужно написать приложение, обслуживающее сотни таблиц в базе данных. Для каждой из них писать контроллер? Или вынести общий код в модули, а потом подключать? Но тогда этот код нужно сделать сильно умным — чтобы его можно было конфигурировать под специфические требования, связанные с каждой моделью данных. А потом становится нужна authorization, несколько гридов на одной странице, динамическая подгрузка Ext JS компоненты и т.д…. В общем, через год после работы с Ext JS и Рельсами, я решил применить весь свой полученный опыт к написанию расширения для Рельс, которое позволяло бы писать *компоненты*, которые — внимание! — содержали бы в себе каким-то чудесным образом и клиентскую, и серверную часть. Имея такие компоненты, их можно было бы расширять с помощью ООП, комбинировать (англ: nest) в новые компоненты, разрабатывать и тестировать изолированно от остального приложения, динамически подгружать и т.д. Так родился Netzke.
Как он поможет тем, кто жалуется на крутую кривую обучения? Он позволяет отодвинуть необходимость изучения Ext JS немного вперед в будущее (ну или растянуть его во времени, сделать менее критичным), и позволять составлять достаточно сложные приложения, пользуясь в основном Руби. Это достигается тем, что JavaScript код для компонент Нецке — «скрыт» внутри компоненты, и знать о нем даже не обязательно, пока не начинаешь писать новые компоненты.
Если интересно — вот пример приложения (это всего лишь демо, конечно) которое буквально можно сделать за 3-4 часа, пользуясь готовыми компонентами: yanit.heroku.com. Обратите внимание на весь тот богатый набор операций, который поддерживается *каждой* из таблиц.
Вот еще немного устаревший (Netzke обновился с тех пор), но вызвавший позитивные отзывы пост с хабра:
habrahabr.ru/post/133935/
Надеюсь, кого-то это заинтересует.
Что меня лично начало смущать в работе после того, как я достаточно свыкся с Ext JS, это как красиво привязывать Ext JS к серверной части. REST — это круто, но… даже для него нужна куча серверного кода, в моем случае контроллеров Ruby on Rails. Просто представьте себе, что нужно написать приложение, обслуживающее сотни таблиц в базе данных. Для каждой из них писать контроллер? Или вынести общий код в модули, а потом подключать? Но тогда этот код нужно сделать сильно умным — чтобы его можно было конфигурировать под специфические требования, связанные с каждой моделью данных. А потом становится нужна authorization, несколько гридов на одной странице, динамическая подгрузка Ext JS компоненты и т.д…. В общем, через год после работы с Ext JS и Рельсами, я решил применить весь свой полученный опыт к написанию расширения для Рельс, которое позволяло бы писать *компоненты*, которые — внимание! — содержали бы в себе каким-то чудесным образом и клиентскую, и серверную часть. Имея такие компоненты, их можно было бы расширять с помощью ООП, комбинировать (англ: nest) в новые компоненты, разрабатывать и тестировать изолированно от остального приложения, динамически подгружать и т.д. Так родился Netzke.
Как он поможет тем, кто жалуется на крутую кривую обучения? Он позволяет отодвинуть необходимость изучения Ext JS немного вперед в будущее (ну или растянуть его во времени, сделать менее критичным), и позволять составлять достаточно сложные приложения, пользуясь в основном Руби. Это достигается тем, что JavaScript код для компонент Нецке — «скрыт» внутри компоненты, и знать о нем даже не обязательно, пока не начинаешь писать новые компоненты.
Если интересно — вот пример приложения (это всего лишь демо, конечно) которое буквально можно сделать за 3-4 часа, пользуясь готовыми компонентами: yanit.heroku.com. Обратите внимание на весь тот богатый набор операций, который поддерживается *каждой* из таблиц.
Вот еще немного устаревший (Netzke обновился с тех пор), но вызвавший позитивные отзывы пост с хабра:
habrahabr.ru/post/133935/
Надеюсь, кого-то это заинтересует.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ExtJS4: практические впечатления