Представляем Sencha Ext JS 5

[@Remitmaster]

Ext JS сложный, как в плане использования так и в его разработке и поддержке. Когда я его первый раз увидел, подумал что он долго не проживет, но со временем понял обратное. Работа просто колоссальная по объему, и ребята продолжают развивать проект. Единственно, не очень много информации на русском. Обновления радуют, будем изучать и применять :)

[@Minoru]

если его хорошо изучить, то никакой он не сложный, учитывая то, что у них всегда отлично документированные исходники

[@MegaMufa]

Отличная документация у них была до недавних пор. Пока они не убрали возможность комментировать. Половину возможностей узнал именно из комментариев и примеры кода там были как раз кстати. А в оф. описании про них ни слова не было.

[@alexstz]

А это да, вообще с круглыми глазами обнаружил, что комментов больше нет, было архиполезно

[@alexstz]

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

[@MegaMufa]

Я тоже вливался на основе готовой кодовой базы. Но лучше бы я это делал с нуля. Такому говну от коллег научился. Потом пришлось долго на новый уклад переучиваться.

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

[@qmax]

А dojo пробовали?

[@Remitmaster]

Смотрел, но не пробовал. Если есть опыт для сравнения обоих, поделитесь, будет полезно.

[@qmax]

Я вот с этой же целью спрашиваю :)

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

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

[@MegaMufa]

Полезный и довольно удобный фреймворк. Ему тяжело найти альтернативу для построения rich приложений.
Хорошо подходит для разных crm-ок.

Но сенча следует общей моде испытывать сырой продукт на своих пользователях. Я два года пишу на ексте и два года приходится время от вермени бороться с багами самого фреймворка. А это довольно сложно, учитывая объемы его кодовой базы.
Большой плюс команед за то, что реагируют на багрепорты и исправляют найденые баги. Но скорость оставляет желать лучшего.

[@knekrasov]

Писал на эксте в период актуальности версий 3 и 4. Ощущения те же самые: только-только стабилизировали, наконец, ветку 3 — выпустили сырую четверку.
Очень хочется надеяться, что с пятой версией история не повторится.

[@uSide]

Может глупый вопрос, но на сайте не нашел. У них лицензирование осталось как раньше? Т.е. для некоммерческих продуктов бесплатно?

[@alexstz]

Да вот непонятно, в факе написано:

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.

Видимо, только коммерческое использование ;(

[@virusman]

GPL-версия ещё есть, просто скрыта в страницах сайта: www.sencha.com/products/extjs/details

[@bob_lyashenko]

После года работы поняли что не то, перешли на angular.js, имхо, это лучшее что сейчас есть
* главный минус этого (extjs) фреймворка конечно же то что он здоровенный, негибкий и неповоротливый

[@alexstz]

Не холивара ради, а истины для: в чём именно негибкость и неповоротливость?

[@youlose]

Могу я сказать (тоже ушли с extjs на angularjs):
— начинающему человеку начать что-то делать из тектового редактора сложно, потому что надо знать очень много и многих важных моментов, которых в документации нет, приходиться гуглить или лазить в исходник (в extjs лазил часто, а вот в ангуляр пока только один раз)
— сложно и непонятно работают layout, то есть в первый раз что-то отцентровать по горизонтали и вертикали очень проблематично
— их предлагаемый подход event-driven контроллеров в чужом проекте приводит к долгим и упорным лазиньям что же и откуда вызывается, причём разбираться сложнее чем в лапше jQuery
— sencha architect для новичков неудобен (я вообще на extjs ещё на второй версии пользовался, потому особо не испытываю дискомфорта, но я учил своего коллегу — это Боль, тупо динамическое хранилище создать — это целое приключение для человека который ни разу это не дала)
— сделать свои элементы управления сложнее, в ангуляре достаточно базовых знаний JS + верстки и какое-то говнокодерское решение уже работает, на extjs сложнее
— переделать дизайн ОЧЕНЬ проблематично (у нас директор — дизайнер, потому один из гвоздей в крышку гроба extjs был в том, что он любит разные красивые админки придумывать, тут extjs вообще плох)
— взаимодействие между элементами форм намного сложнее чем в ангуляре (значения комбобокса зависящие от другого комбобокса, например)

[@youlose]

это целое приключение для человека который ни разу это не дала
это целое приключение для человека который ни разу этого не делал

[@Dolios]

Большую часть того, что вы написали, можно было заенить фразой «высокий порог вхождения» :)
На самом деле, это не плохо и не хорошо. Просто сам фреймворк сложный. Для очень большого набора задач его использование просто не оправдано. Но есть ряд задач, когда без него (или его аналога) никак. Каждой задаче свой инструмент.

[@Goodkat]

Там действительно много «негибких» моментов, когда стандартные компоненты нельзя параметризировать без копипасты всего кода в свой класс или залезания в приватные свойства и методы.

[@limitium]

Ого. Работал и с тем и другим. Очень интересно, что у вас за проект где можно так легко менять одно на другое. Ведь эти фреймоврки решают сильно разные задачи.

[@bo883]

Использовали давно в одном большом проекте, когда проект был почти готов поняли что он слишком сложен(очевидно можно было сделать просто), медлителен короче мы ошиблись с выбором. Пришлось все переделывать.
Есть интерес к данному фремворку но использовать уже наврятли…

[@qmax]

А киньте пример с MVVM?

[@alexstz]

fiddle.sencha.com/#fiddle/5kn

[@qmax]

Что-то я не въеду, чем это от MVC отличается…

[@alexstz]

Тем, что нигде в коде нет строчек form.loadRecord() или form.updateRecord(). В общих чертах MVVM описан здесь: Ext JS 5: MVC, MVVM и др

[@qmax]

Чтото я не улавливаю разницы между
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 });

или не туда смотрю?

[@alexstz]

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

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

И далее есть файл вьюмодели /app/view/DetailViewModel.js, а в /app/view/Detail.js — биндинги. Вообще, пример простоват и разница со старым подходом не слишком заметна. В этих примерах (англ.) тема раскрыта глубже.

[@alexstz]

Повторюсь: в таком простом примере особой разницы нет, согласен. Ну только разве что обратно данные с формы записываются автоматически. Видимо, смысл раскрывается в использовании сложных биндингов, как в примере по ссылке выше.

[@VasilioRuzanni]

Ай яй яй, 2014-й на дворе, а все иконки картинками в стандартных темах!

[@pihel]

А у extjs 5 есть совместимость с 4 версией? Могу я подменить библиотеку и продолжить работу?

[@alexstz]

По идее, да. Но лично из моего опыта, есть нюансы. Если переходить с 4.2, то, думаю, проблем быть не должно. А если с более ранних, то какие-то вещи могли измениться. Например, при переходе, кажется, на 4.2, removeAll() у Store начал не очищать хранилище, а удалять все записи.

[@pihel]

Спасибо, надо будет провести эксперимент.

[@khusamov]

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

[@alexstz]

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

var batch = session.getSaveBatch();
batch.start();
// затем batch можно использовать для перезапуска процесса