Пользователь
0,0
рейтинг
11 марта 2013 в 14:36

Разработка → ExtJS4: практические впечатления

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

А хочется понять, на что годится та или иная библиотека в практических применениях, хочется прочитать о чьем-нибудь опыте. А с этим не очень. Например, по ExtJS я ничего такого не нашел. Пришлось пробовать самому.

Далее следуют мои впечатления от работы на ExtJS 4.1.1. Они по определению субъективны и не претендуют на вселенские обобщения.

Итак, условия. Мне нужно написать красивый веб-интерфейс достаточно большой сложности. Очень хочется, чтобы все это выглядело приложением, а не сайтом. Приложение интранетноое, поэтому красота особенно не нужна. Пользователи гораздо больше ценят удобство и скорость своей работы, чем рюшечки, к которым за три дня привыкаешь. Еще они любят предлагать всякие изменения и очень одобряют, когда эти изменения делаются быстро. Вопрос совместимости с браузерами не стоит — будут сидеть на том, что я скажу.

Дополнительное условие — я не очень люблю возиться с веб-интерфейсом и стараюсь отделаться от этой части побыстрее.

Итак, положительные стороны ExtJS 4.1.1.

Глобально поставленной цели с ее помощью добиться можно — на ней действительно можно написать веб-приложение. Оно будет выглядеть профессионально и красиво, я бы даже сказал, роскошно. Богатый выбор элементов управления, тщательно подобранные цвета, заранее написанные стили. Достаточно сказать, что можно вообще не иметь дела ни с HTML, ни с CSS, и забыть их оба как страшный сон. Доступ к DOM в библиотеке на всякий случай есть, но я ни разу им не пользовался — все решается и так.

Приложение легко стыкуется с REST, главное, чтобы REST отдавал данные в правильном (и не особо сложном) формате. Достаточно описать только, куда ходить за данными — и вуаля. Из коробки работает весь джентльменский набор CRUD.

Практически все действия пользователя можно вынести в интерфейс и не грузить ими сервер. На долю последнего остается только дополнительная проверка правильности данных и работа с базой. Это очень его упрощает — буквально до 5-10 кб кода (nodejs, mojo — я пробовал несколько вариантов, везде получается хорошо).

Теперь о недостатках.

Он один, но глобальный — всё это, как те самые елочные игрушки, не радует. Программирование на ExtJS не только не приносит никакого удовольствия, но совсем наоборот. Это изобильный источник фрустраций, комплексов и зажимов.

Общий стиль библиотеки лучше всего передается словом «монстроподобность». Это эдакий мастодонт, в котором счет файлов с исходниками идет на десятки. При подключении страницы в браузер грузится около 6 мегабайтов всякого добра и это время весьма и весьма заметно.

Из-за жутко медленной загрузки невозможно программировать моим любимым способом, которому я научился еще от Форта — мелкими правками. Вносишь одно изменение, смотришь результат, правишь. Повторить. Так не получается — пока этот слон загрузится после каждого изменения, забываешь, что хотел сделать. Мысли уже унеслись куда-то далеко, на сочные поля зелени и белые горы с водопадами.

Учить ExtJS жутко трудно. Она огромная, непонятно с чего начинать. Учебники и книжки в основном относятся к третьей версии, а она, в свою очередь, мало похожа на версию 4, в которой почти все сделано по-другому. По этой же причине почти бесполезны форумы, ибо все, что там написано, давно устарело.

Стыдно сказать, но я банальное приложение писал с нуля почти неделю, страдая при этом резкими перепадами настроения. Мне все время хотелось биться головой об стену — непонятно было абсолютно все. Ни одну технологию я с такими страданиями не учил.

Второе приложение, впрочем, было не лучше. Чуть быстрей, но не намного.

В 4 версии ваше приложение должно быть сделано по принципу MVC. На практике это означает, что даже hello world будет состоять из десятка файлов, разложенных по нескольким разным каталогам. И прежде чем приступить к программированию любой задачи, эти файлы надо будет создать и разложить. Это не HTML, который открывается даже с пустой страницей. Ситуация напоминает профессиональных штангистов, которым, прежде чем подойти к снаряду, надо по несколько часов разминаться и разогревать мышцы.

Набор стандартный. В модели описываются ваши данные, в хранилище (Storage) — как до этих данных добраться, в видах — как все это будет выглядеть. Здесь все более-менее логично.

Контроллер типа соединяет вид с обработчиками, но на деле в четвертой версии он до ума не доведен и обычно бесполезен. Предполагается, что у вас будет глобальный контроллер для каждой сущности и совершенно невозможно с его помощью написать какой-то самодостаточный виджет, который можно было бы потом вставлять куда хочешь.

С данными тоже не все благополучно. Хранилище предполагает, что все данные всегда совершенно однородны. Можно, правда, описывать какие-то вложенные сущности на манер «один ко многим», но эти дополнительные данные только читаются — записать их нельзя, что делает всю затею бесполезной.

Описание интерфейса — это нечто. Он описывается чисто декларативно — и это плюс. Но как он описывается, господи. С помощью декларации данных Яваскрипта — а видов данных там немного, массивы да хеши. Поэтому любой экран, всего с парой контролов, — это длиннющая портянка декларативного кода, со структурами, многократно вложенными друг в друга. Искать при таких условиях, в каком месте стоит лишняя скобка — это ад. Упростить декларации невозможно — надо описывать каждый чих, полезных значений по умолчанию практически не существует.

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

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

Или пишут тебе пользователи — у нас не грузится таблица. Открываешь — и правда, не грузится. Вчера грузилась, а сегодня нет, притом, что в этом месте ты ничего не менял.

Не лучше обстоит дело и с твоими собственными ошибками. Диагностика очень часто крайне загадочна и только после пары месяцев ты начинаешь догадываться, что «undefined» где-то глубоко в недрах ExtJS означает пропущенный атрибут Store при описании выпадающего списка.

Соответственно, становится бесполезной и отладка. Твой собственный код чисто декларативный, отлаживать там нечего, а разбираться с мегабайтами кода самой библиотеке — занятие, требующее огромного мужества.

Писать собственные контролы или модифицировать старые — занятие еще то. Впрочем, если модификации не очень большие, то это делается относительно легко — наследуется старый объект и в него вносятся изменения. Обычно это самый легкий способ заставить библиотеку делать то, что тебе нужно. Но если изменений чуть больше — следует резкий скачок сложности. Из декларативных описаний мы оказывается где-то глубоко в яме со львами, ДОМом, неочевидными событиями, родительскими объектами и черт знает чем еще.

В целом, общий стиль фреймворка напоминает майкрософтовский. Легко, очень легко делать то, что заранее было предусмотрено авторами, но шаг влево, шаг вправо — сразу расстрел.

Исходя из всего вышесказанного, в своем следующем проекте (а у меня их много разных) я все-таки для интерфейса попробую что-нибудь другое.
Юрий Жиловец @gatoazul
карма
133,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (60)

  • +14
    >Или пишут тебе пользователи — у нас не грузится таблица. Открываешь — и правда, не грузится. Вчера грузилась, а сегодня нет, притом, что в этом месте ты ничего не менял.

    1. Чудес на свете не бывает.
    2. Не менял в этом месте, значит менял в другом.
    • +1
      А вы слышали о таком понятии, как хрупкий код и избыточные зависимости?
  • +4
    Сколько Вы проработали с ExtJS?
    • +2
      Вы хотите меня утешить, как в рассказе Шекли? Мол, первую тысячу лет трудно, а потом привыкаешь.
  • 0
    что «undefined» где-то глубоко в недрах ExtJS
    А как же стектрейс?
    • +2
      А стектрейс ничего не говорит, т.к. атрибут не указан в конструкторе, а ошибка произошла при вызове какого-нибудь метода…
      • 0
        Иногда просто видно, в чьем именно конструкторе не указан атрибут. И очень помогает Add conditional breakpoint…:)
        • +1
          А иногда undefined из-за пропущенного атрибута становится какая-то внутренняя переменная, иногда становится атрибут в каком-то другом объекте… Ну я же работал с ExtJS разных версий, знакомые грабли :)
    • 0
      А стектрейс тоже вложен раз десять, причем там только модули самой библиотеки, твоих нет
  • –6
    Стыдно сказать, но я банальное приложение писал с нуля почти неделю, страдая при этом резкими перепадами настроения.


    ну так справка же есть доки, sencha.com, архитект в котором можно приложение создать перетаскав мышкой элементы а потом посмотреть код.

    Статья не объективна.
    • +1
      Вы бы хоть первый абзац ее внимательно прочитали. Там же русским языком написано: статья не то что не объективна, но прямо субъективна.
  • +3
    Диагностика очень часто крайне загадочна и только после пары месяцев ты начинаешь догадываться, что «undefined» где-то глубоко в недрах ExtJS означает пропущенный атрибут Store при описании выпадающего списка.

    `debugger;`, «Break On All Errors» (FireBug), «Pause on all exceptions» (Web Inspector) или `try{ } catch(error){ console.log(error.stack) }`, не?
  • +1
    Вы бы полотно текста скринами хотя-бы разбавили. Я уже не говорю про разбиение текста на разделы. Если хотите донести свою мысль, потрудитесь привести примеры, которые поддерживают ваши утверждения, и насколько легче это было-бы на технологии X.
    Как образец объективной и понятной критики — почитайте «PHP — фрактал плохого дизайна».
    • 0
      Вы, наверное, литературный критик? В таком случае не стоит ссылаться на довольно посредственно переведенную статью.
      • +1
        Меня, наверное, в младшей школе учили излагать мысли на бумаге. От безосновательной критики качество вашего опуса не повысится.
  • +5
    Очень странная статья. Уже второй год использую четвертую версию и таких проблем не обнаружил.

    В самом коде библиотеки ошибки есть и они легко вылавливаются стандартными методами. Я даже кучку хаков написал с исправлениями. И разработчикам высылаю. Но ошибок в системе очень мало.

    Освоить систему очень просто, там есть руководство по созданию MVC-приложения и оно вполне добротное. Для начала пойдет. И оно написано про четвертую версию! А никак не про третью. Также есть демо-примерчики. Они очень хорошо показывают приемы работы. Их даже слишком много. Я до сих не все освоил.

    Отладка ничем не отличается от отладки JS-приложений. Есть три версии библиотеки: нормальная, debug и develop (последняя более удобно при отладке, так как сообщения более информативны).

    Система работает надежно. Никаких сбоев не наблюдал ни разу. Разве что переход на новые версии конечно не без фокусов.

    Работает и загружается весьма быстро.

    Банальное приложение писать неделю можно если а) не знаешь английский язык, б) мало опыта с JavaScript. Иначе не поверю что неделю можно писать свое первое приложение.
    • 0
      Я даже кучку хаков написал с исправлениями. И разработчикам высылаю. Но ошибок в системе очень мало.
      А после каждого релиза переписываете свои хаки? :)
      Ошибок хоть и мало, но самому пофиксить их сложно — только если полностью переписать код компонент. Чего только стоит кривой скроллинг в гриде, который исправили только в 4.1.1. Баг в рендерере ячеек таблиц не пофиксили до сих пор, хотя на форуме обещали исправить ещё к версии 4.0.7.

      • 0
        Да, пожалуй единственная проблема ExtJs — это достаточно большое количество мелких багов, всё время приходится писать хаки и да, они ломаются от версии к версии. Жаль, что нет ExtCore 4 под открытой лицензией.
      • 0
        Да, иногда хаки приходится переписывать (на то они и хаки, чтобы переписывать).

        Баги в любой системе есть. Не вижу смысла на них жаловаться. Тем более что лучше Ext ничего нет.

        Есть смысл написать книжку как программировать под Ext. Есть смысл написать свою библиотеку исправлений каждого релиза.

    • 0
      Я перевел с английского языка книжку по экономике в 500 страниц и работаю с JS лет десять. Более адекватные предположения будут?
      • +2
        Не будут. Тогда не ясно, почему вам не помогли руководства, что написали разработчики. Мне лично помогли. Я как раз на них и обучился.
        • +1
          Я тоже обучился именно на них. Но заняло это очень много времени из-за сложности фреймворка, крайне крутой кривой обучения, а также частично из-за того, что разные руководства делают одни и те же вещи по-разному.
  • +3
    При подключении страницы в браузер грузится около 6 мегабайтов всякого добра и это время весьма и весьма заметно.

    Вы сборщиком пользовались? С трудом представляю, чего такого можно было понаписать, чтобы собраный код был около 6 мегабайт.
    • 0
      а вот ExtJS смог. jQuery + UI + десяток плагинов тоже не 2Кб даже в пожатом и собранном виде занимает.
  • +4
    Поэтому любой экран, всего с парой контролов, — это длиннющая портянка декларативного кода, со структурами, многократно вложенными друг в друга. Искать при таких условиях, в каком месте стоит лишняя скобка — это ад.
    Разбейте создание контролов на функции, вызывайте их последовательно в 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);
    }
    
    Правда, от этого потеряется совместимость кода UI с Архитектом. С другой стороны, если вы пользуетесь Архитектом, то в UI-файл с портянкой декларативного кода вам заглядывать и вовсе не обязательно.

    Из-за жутко медленной загрузки невозможно программировать моим любимым способом, которому я научился еще от Форта — мелкими правками. Вносишь одно изменение, смотришь результат, правишь. Повторить. Так не получается — пока этот слон загрузится после каждого изменения, забываешь, что хотел сделать.
    Может, у вас сервер где-то далеко?
    У меня в локальной сети приложение с неминимированной дебаг-версией библиотеки со всеми комментариями и несколькими десятками собственных компонент при включенном файрбаге загружается секунд за 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?
    • 0
      А где Вы взяли версию 4.2?
      • 0
        Скачали бета-версию на sencha.com, где ж ещё? :)
    • 0
      >Собственно, а какие альтернативы есть для ExtJs? Dojo? YUI?
      Ммммм… qooxdoo?
      • +2
        Ещё есть Kendo UI (на jQuery). GPL v3
        • –1
          Да, некоторое время пользовался ExtJS, очень не хватало обычного jquery, в частности для ajax запросов. Начал смотреть альтернативы, остановился на kendo. Проект ещё достаточно молод и, соответственно, имеет недостатки, в частности ExtJS функционально мощнее будет. Но kendo отлично дружит с jquery и визуально симпатичнее.
          С лицензией примерно то же самое, GPL3 для «базовых» возможностей, дополнительный библиотеки — платные.

          ExtJS также был сложен в понимании, мне кажется главная проблема — слишком большая зависимость моего javascript стиля кодирования от jquery.
      • 0
        Любопытно будет посмотреть SmartClient
      • 0
        www.jeasyui.com/ — изумительное решение.
    • +1
      У меня грузится 11 секунд вместе с данными. Это достаточно много.
  • +2
    a) Грузить файлы на страницу по отдельности — плохо. Конкатенировать и сжимать.
    b) Учить ext не трудно. У них одна из самых потрясающих документаций, что я видел.
    c) ext не создан для hello world. Он создан для больших приложений, и его структура поддерживает порядок как нельзя лучше.

    Описаные далее проблемы вообще не проблемы фреймворка.
    • +1
      Видите ли, у фреймворков вообще не бывает проблем. Проблемы бывают только у людей.
  • +1
    Мне нужно написать красивый веб-интерфейс...
    Приложение интранетноое, поэтому красота особенно не нужна.
    • –2
      … но не повредит, если не будет требовать слишком больших усилий. Изучайте диалектику, друг мой
  • +2
    Если знакомы с Java, попробуйте Vaadin.
    Очень простая и удобная библиотека.
    Только надо понимать что она «серверсайд», у многих из-за непонимания этого проблемы и претензии на ровном месте.
  • +1
    Мои 3 копейки.

    Для своего проекта (инструмент на данный момент для внутреннего пользования, но с перспективой открыть доступ другим компаниям нашей области) несколько месяцев назад выбрал ExtJS4. До этого полтора года разрабатывалось все на html+jquery. Пошёл на это, т.к. понял, что очень большая часть времени уходит на разработку всяких панелек/деревьев/кнопок/гридов/тулбаров и т.д. — всего того, что в эксте — из коробки.

    Согласен, что многие из описаных проблем — имеют место быть. Онако, все они решаемы, если потрудиться. Уж простите, но всякие отступы/скобки и т.д. — это смешно. Освойте нормальный редактор с подсветкой, проверкой парности и т.д. Быстро открыть нужный файл — это тоже к удобству редактора. Меня это — несколько кнопок. У меня эту ситуацию сильно облегчает CoffeeScript, на котором всё и написано.

    6 мег. Это откуда? У меня на странице один js-файл экста, который зипуется на сервере и кэшируется браузером и весит на порядок меньше 6М. И второй с моим приложением, который при деплое автоматом собирается, чистится, жмётся и так же отлично кэшируется (спасибо Rails).

    «Ничего не трогал, а оно сломалось» — это уже простите, как заметили выше — магии не бывает. Набирайтесь опыта и осваивайте технологии тестирования — помогает.

    Как и любой инструмент, ExtJS 4 — не идеален, но при этом вполне добротный инструмент для решения определенного круга проблем, который надо уметь готовить. Ну и при этом, насколько мне известно, по сути, не имеющий альтернатив.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Есть платная и бесплатная (GNU GPL license v3) лицензии.
    • 0
      > Уж простите, но всякие отступы/скобки и т.д. — это смешно. Освойте нормальный редактор с подсветкой, проверкой парности и т.д

      Вам не приходилось по срочному звонку править код через фтп-соединение на сервере где нету vim, в каком-нибудь редакторе без подсветки и прочих плюшек? Хорошая IDE необходима, конечно. Но оправдывать плохую структуру кода тем, что есть софт который может решить эти проблемы — как то не совсем верно.
  • 0
    «Предполагается, что у вас будет глобальный контроллер для каждой сущности и совершенно невозможно с его помощью написать какой-то самодостаточный виджет, который можно было бы потом вставлять куда хочешь.»

    Никаких проблем для созданія самодостаточних віджетов при использовании MVC нет
  • +4
    Вы сейчас описали весь ужас, который испытывает разработчик, когда с jq переходит на ext =) Поработайте пол года, а лучше год, потом расскажите как оно. Лично я сам так же первое время мучался, когда ломался мозг в попытках принять новые абстракции и концепции. Но когда понимаешь и принимаешь, то приходит просветление и разрабатывать становится просто и быстро. Из всех недостатков, которые вы перечислили, только ошибки в коде являются проблемой. Всё остальное — от непонимания.
  • 0
    Пользуюсь extjs и плагинами с первых и даже нулевых версий, доволен всем. По поводу тормозов, — на современных машинах загрузка не отличается от загрузки чего-то более легкого, за то по функционалу врядли найдется какой либо другой фреймворк.
  • +1
    Можно, правда, описывать какие-то вложенные сущности на манер «один ко многим», но эти дополнительные данные только читаются — записать их нельзя, что делает всю затею бесполезной.


    Это первое, что расстраивает при первом знакомстве. И я, удручённый, допилил комплексную отправку модели и всех её ассоциаций обратно на сервер. И, о чудо, теперь можно загрузить сложную структуру и править её в реальном времени! Отзывчивость UI будет, уууххх! Мы так и делали, а пустя некоторое время, я понял, что выстрелил себе в ногу :)

    Например, есть некая модель пользователя, а у него есть список контактов и куча других ассоциаций. Редактируем один контакт, и отправляем пользователя обратно на сервер обновиться. Сервер в ответ возвращает новую структуру, которая уже никак не связана с записью, которая сейчас всё ещё открыта на редактирование. Ведь, фактически, это json, который пропустили через Reader, который, в свою очередь, выдал набор инстансов модели. Если тупо взять и положить их обратно в коллекцию, то получится, что в редакторе находится ссылка на устаревшую запись. Самый проблемный случай — когда мы добавляем несколько записей, те отправляем модели без идентификатора, чтобы сервер знал, что это записи на добавление. Если ничего не сделать, то при повторном нажатии на заветный Save, сервер может решить, что вы добавляете ещё одну запись в контакты, а возможно и удаляете только что созданый (ведь его нет в коллекции, верно?) Чтобы решить проблему, прошёл через муки реализации синхронизации данных…

    В любом случае, Ext рекомендует использовать отдельные сервисы для CRUD операций над коллекциями (Ext.data.Store, если быть точным) и тогда проблем не будет. Загрузили данные в коллекцию, вытащили запись, обновили, store.sync() и горя не будет. Я был молод, горяч и не прислушался, теперь сильно сожалею :) Вообще, в ExtJS все решения достаточно логичны, чтобы убедиться, стоит только самому реализовать недостающую функциональность. Зачастую, становится понятно, что вот они, эти грабли, которые обошли ребята из сенчи :)
  • 0
    В моем профиле стоит дата Join Date 5 Jul 2007, именно тогда я взял Premium и начал активно использовать ExtJS.
    (На тот момент было много нововведений и фиксов, которые не были доступны в публичном доступе.)

    ExtJS — целый мир, своя идеология. Иногда приходилось тратить часы для создания элементов, которые можно было бы отрисовать за 5 минут.
    В целом была создана достаточно обширная система, унифицированная и масштабируемая.

    Небольшие примеры из прошлого (надеюсь несколько thumbnails никому не помешают):

    1. Как сейчас модно Dashboard


    2. Просмотров записей (новостей, статей и т.п.)


    3. Контекстное меню на запись


    4. Редактирование записи


    5. Настройки системы (динамические формы)


    Конечно, что было раньше и сейчас — небо и земля. Большинство расширений только создавалось, тестировалось, при обновлении ExtJS приходилось переписывать свой app. Сейчас многие расширения уже вошли в основную библиотеку, все отлажено и оттестировано.

    Но… на данный момент я всецело и полностью отказался от прекрасного ExtJS (без иронии) и нисколько не жалею.

    ПС: извиняюсь за длинный пост.
    • +1
      Самого интересного не написали — так почему отказались от ExtJS?
      • 0
        Честно — надоело.

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

        Выше я привел снимки экрана стандартизированных элементов. К примеру, чтобы создать новый модуль в системе, достаточно было бы занести параметры конфигурации и он получал целый ряд стандартизированных элементов управления (деревья, спики, формы, контектсные меню, режимы отображения, мульти-загрузка файлов и т.п.), т.е. некий фреймворк внутри ExtJS, но когда дело доходит до сильно кастомных интерфейсов под задачи отличные, от создания CMS, то… или тратить t * K времени на модификацию и написание extensions под ExtJS (где K — коэффициент, прямо пропорциональный полету фантазий заказчика) или отказываться от ExtJS.
    • 0
      да, действительно, почему отказались?
  • 0
    Могу порекомендовать автору поработать с ExtJS 3.3 — 3.4 версии. Если грубо говорить то 3 версия это набор кирпичей, а 4 это уже готовые здания из этих кирпичей. В первом случае hello word будет существенно быстрей работать и на много меньше времени занимать, но вот app = {} сами будете проектировать. Выбор за вами.
  • 0
    Пользуюсь ExtJS уже около трех лет. Не могу не ответить на Ваш пост.

    При подключении страницы в браузер грузится около 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 для стандартного компонента. Вот с обновлением на новую версию все гораздо печальнее.

    Или пишут тебе пользователи — у нас не грузится таблица. Открываешь — и правда, не грузится. Вчера грузилась, а сегодня нет, притом, что в этом месте ты ничего не менял.

    Если что-то где-то сломалось, значит все-таки что-то где-то изменилось.

    В целом мне кажется, что статья очень субъективная. Я не являюсь фанатом этого фреймворка, и не берусь его защищать, но мне кажется что с задачами, для которых он создан, он справляется весьма успешно.
    • 0
      Спасибо за советы. Некоторые из них оказались весьма полезны.
  • 0
    так и не понял, есть ли альтернатива EXTJS?
    • +1
      • 0
        w2ui.com/web/ вот еще.
        Да все это я видел, просто не понятно полноценные ли это альтернативы?
      • 0
        Посмотрел мельком грид библиотеки kendoui.com. Реализация ужасная. Скролл не виртуальный, а нативный (через scrollTop). А это означает, что грид рендерит сразу все подгружаемые строки. Теперь представьте ситуацию, когда в синхронном режиме вам нужно работать с 1000 строками без paging. Возможно в этой бибилиотеке есть другой грид, но этот — точно не конкурент гриду ExtJs. Еще посмотрел разметку ячеек. Судя по разметке, ячейки особо стилизовать нельзя, что тоже не есть хорошо.
      • 0
        А это www.smartclient.com/#fetchOperationFS по моему мнению вообще плагиат на ExtJs
        • 0
          Я отвечал на вопрос «есть ли альтернативы ExtJS», а не на вопрос: «Есть ли альтернативы, которые по мнению deser имеют прекрасную реализацию и не являются плагиатом на ExtJS» ;-)
  • +1
    Как и у некоторых других отписавшихся, в период знакомства с 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/

    Надеюсь, кого-то это заинтересует.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.