Как стать автором
Обновить

Комментарии 35

Ext JS сложный, как в плане использования так и в его разработке и поддержке. Когда я его первый раз увидел, подумал что он долго не проживет, но со временем понял обратное. Работа просто колоссальная по объему, и ребята продолжают развивать проект. Единственно, не очень много информации на русском. Обновления радуют, будем изучать и применять :)
если его хорошо изучить, то никакой он не сложный, учитывая то, что у них всегда отлично документированные исходники
Отличная документация у них была до недавних пор. Пока они не убрали возможность комментировать. Половину возможностей узнал именно из комментариев и примеры кода там были как раз кстати. А в оф. описании про них ни слова не было.
А это да, вообще с круглыми глазами обнаружил, что комментов больше нет, было архиполезно
Ну, так можно по любой теме сказать: если хорошо изучить, то не сложно… ;) Вообще, порог вхождения есть как и в любом другом фреймворке. В нашей команде новые разработчики влились быстро благодаря готовым проектам на Ext JS и при помощи тех, кто уже в теме. По примерам, конечно, обучение идёт гораздо быстрее.
Я тоже вливался на основе готовой кодовой базы. Но лучше бы я это делал с нуля. Такому говну от коллег научился. Потом пришлось долго на новый уклад переучиваться.

Екст мне чем то С++ напоминает. В нем одно действие можно сделать множеством способов: хороших и не очень. При этом в разных частях документации оно делается оп разному. Это путает.
А dojo пробовали?
Смотрел, но не пробовал. Если есть опыт для сравнения обоих, поделитесь, будет полезно.
Я вот с этой же целью спрашиваю :)

На dojo опыт есть.
Сейчас смотрю на документацию по extjs и он мне кажется сделанным на порядок грамотнее и профессиональнее.
Хотя немного удручает исключительно програмное создание интерфейса.

В народе говорят — dojo мощнее.
Возможно, это из-за гигабайтовой свалки плагинов в dojox (с недосовместимыми интерфейсами и недописаной документацией)
Полезный и довольно удобный фреймворк. Ему тяжело найти альтернативу для построения rich приложений.
Хорошо подходит для разных crm-ок.

Но сенча следует общей моде испытывать сырой продукт на своих пользователях. Я два года пишу на ексте и два года приходится время от вермени бороться с багами самого фреймворка. А это довольно сложно, учитывая объемы его кодовой базы.
Большой плюс команед за то, что реагируют на багрепорты и исправляют найденые баги. Но скорость оставляет желать лучшего.
Писал на эксте в период актуальности версий 3 и 4. Ощущения те же самые: только-только стабилизировали, наконец, ветку 3 — выпустили сырую четверку.
Очень хочется надеяться, что с пятой версией история не повторится.
Может глупый вопрос, но на сайте не нашел. У них лицензирование осталось как раньше? Т.е. для некоммерческих продуктов бесплатно?
Да вот непонятно, в факе написано:
What Sencha products are available under the GPL v3?
Public releases of Sencha Touch, Sencha Touch Charts, Sencha Ext JS and Sencha GXT are all available under GPL v3.

А при попытке скачать предлагает 45-дневную версию. Скорее всего, они ещё не обновили информацию о лицензировании.

UPD. Хотя нет, вот же оно (линк):
Sencha offers two licensing options for Ext JS 5, a Commercial Software License, and Commercial OEM License.

Видимо, только коммерческое использование ;(
После года работы поняли что не то, перешли на angular.js, имхо, это лучшее что сейчас есть
* главный минус этого (extjs) фреймворка конечно же то что он здоровенный, негибкий и неповоротливый
Не холивара ради, а истины для: в чём именно негибкость и неповоротливость?
Могу я сказать (тоже ушли с extjs на angularjs):
— начинающему человеку начать что-то делать из тектового редактора сложно, потому что надо знать очень много и многих важных моментов, которых в документации нет, приходиться гуглить или лазить в исходник (в extjs лазил часто, а вот в ангуляр пока только один раз)
— сложно и непонятно работают layout, то есть в первый раз что-то отцентровать по горизонтали и вертикали очень проблематично
— их предлагаемый подход event-driven контроллеров в чужом проекте приводит к долгим и упорным лазиньям что же и откуда вызывается, причём разбираться сложнее чем в лапше jQuery
— sencha architect для новичков неудобен (я вообще на extjs ещё на второй версии пользовался, потому особо не испытываю дискомфорта, но я учил своего коллегу — это Боль, тупо динамическое хранилище создать — это целое приключение для человека который ни разу это не дала)
— сделать свои элементы управления сложнее, в ангуляре достаточно базовых знаний JS + верстки и какое-то говнокодерское решение уже работает, на extjs сложнее
— переделать дизайн ОЧЕНЬ проблематично (у нас директор — дизайнер, потому один из гвоздей в крышку гроба extjs был в том, что он любит разные красивые админки придумывать, тут extjs вообще плох)
— взаимодействие между элементами форм намного сложнее чем в ангуляре (значения комбобокса зависящие от другого комбобокса, например)
это целое приключение для человека который ни разу это не дала
это целое приключение для человека который ни разу этого не делал
Большую часть того, что вы написали, можно было заенить фразой «высокий порог вхождения» :)
На самом деле, это не плохо и не хорошо. Просто сам фреймворк сложный. Для очень большого набора задач его использование просто не оправдано. Но есть ряд задач, когда без него (или его аналога) никак. Каждой задаче свой инструмент.
Там действительно много «негибких» моментов, когда стандартные компоненты нельзя параметризировать без копипасты всего кода в свой класс или залезания в приватные свойства и методы.
Ого. Работал и с тем и другим. Очень интересно, что у вас за проект где можно так легко менять одно на другое. Ведь эти фреймоврки решают сильно разные задачи.
Использовали давно в одном большом проекте, когда проект был почти готов поняли что он слишком сложен(очевидно можно было сделать просто), медлителен короче мы ошиблись с выбором. Пришлось все переделывать.
Есть интерес к данному фремворку но использовать уже наврятли…
А киньте пример с MVVM?
Что-то я не въеду, чем это от MVC отличается…
Тем, что нигде в коде нет строчек form.loadRecord() или form.updateRecord(). В общих чертах MVVM описан здесь: Ext JS 5: MVC, MVVM и др
Чтото я не улавливаю разницы между
var detailView = Ext.ComponentQuery.query('form')[0];
//set the form record manually
detailView.loadRecord(record);

и

var detailView = Ext.ComponentQuery.query('mvvm-DetailView')[0];

//set the form's ViewModel binding
detailView.getViewModel().setData({ rec: record });

или не туда смотрю?
Мм, почему же?.. Вот даже приложение начинается с

Ext.application({
    name : 'MVVM',
    ...

И далее есть файл вьюмодели /app/view/DetailViewModel.js, а в /app/view/Detail.js — биндинги. Вообще, пример простоват и разница со старым подходом не слишком заметна. В этих примерах (англ.) тема раскрыта глубже.
Повторюсь: в таком простом примере особой разницы нет, согласен. Ну только разве что обратно данные с формы записываются автоматически. Видимо, смысл раскрывается в использовании сложных биндингов, как в примере по ссылке выше.
Ай яй яй, 2014-й на дворе, а все иконки картинками в стандартных темах!
А у extjs 5 есть совместимость с 4 версией? Могу я подменить библиотеку и продолжить работу?
По идее, да. Но лично из моего опыта, есть нюансы. Если переходить с 4.2, то, думаю, проблем быть не должно. А если с более ранних, то какие-то вещи могли измениться. Например, при переходе, кажется, на 4.2, removeAll() у Store начал не очищать хранилище, а удалять все записи.
Спасибо, надо будет провести эксперимент.

Здравствуйте! Спасибо за статью!
Вопрос про сессии.
Из описания не ясно, какую конкретно проблему решают сессии?
Как-то и без сессии ничего сложного нет в сохранении записей на сервере.
О каком счетоводстве идет речь?
Что значит "новые записи правильно ссылаются на другие записи в этой транзакции"?

Если очень грубо, то сессия чем-то похожа на контекст БД в какой-нибудь ORM. Она смотрит, какие записи добавились, удалились или обновились, а потом одним заходом отправляет соответствующие команды на сервер. Это бывает особенно удобно, когда у вас есть зависимые записи по типу master-detail: сессия создаст master-запись, получит её id, подставит этот id в поле внешнего ключа зависимых и только потом сохранит их. Для этого, конечно, необходима правильная настройка в модели. Когда таких мест в приложении много, либо зависимых коллекций больше одной, то преимущества сессий становятся более очевидными.
Что мне ещё нарвится, так это обработка ошибок: если что-то в процессе не сохранилось, то можно дать пользователю возможность исправить ошибку, а затем повторно вызвать метод — процесс продолжится с того места, где он упал.
Чаще всего мы имеем дело с гридами и другими компонентами, использующими хранилища, поэтому сессию можно подключить к нескольким хранилищам.
В качестве примера можно представить отправку электронного письма, где главная сущность — это само письмо, а зависимые — получатели и вложения. При сохранении мы вызовем:

var batch = session.getSaveBatch();
batch.start();
// затем batch можно использовать для перезапуска процесса
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории