Cоздание прототипа социальной сети на ExtJS. Первые и не последние проблемы с ExtJS 4

[@TheHorse]

Ох, вспоминаю, как весело было превращать Ext.grid.Panel в делфовые гриды… До сих пор, не оклемался (extjs 3). А еще была трабла с тем, что Ext.Window, будучи внутри другого Ext.Window, терял отрисовку границ… А еще сплошная боль, вечно подписываться на afterrender, когда нужно события домавским елементам повесить. А еще… ну вы поняли…
Но больше всеге меня затронуло отсутсвие 3-state-checks для деревьев, и многоэтажных заголовков для гридов…

P. S. И все-же ExtJS — очень крутая штука. В javascript, она для меня как Qt для С++.

[@freeart]

Проблему с afterrender я обошел немного по другому — отказался от событий ExtJS, а привязывал свои через делегат jQuery.

Многоэтажные заголовки подключаются через плагин кстати.

[@TheHorse]

> Многоэтажные заголовки подключаются через плагин кстати.
Он очень кривой((

[@freeart]

Ну с этим не поспоришь… ))

[@diamant]

В ExtJs 4 сделали «нативные» многоэтажные заголовки. И они работали до версии 4.0.6, в которой их сломали. Теперь делаю в afterrender width+1, width-1 для каждого столбца, чтобы заголовки пересчитались и нормально отображались, и жду следующей версии :)

А плагин был кривой, да, и не совместим с другими плагинами и вьюшками.

[@veitmen]

Извините, я не понял зачем использовать Ext.Window внутри другого Ext.Window.

[@TheHorse]

Не нужно извиняться, ничего плохого вы не сделали. В моем проекте есть окно 'проводник', которое занимает 90% всего экрана. Остальное занимают тулбары, таскбары, менюшки. В этом проводнике можно открывать документы и прочие. Все эти документы и прочие, агрегированы в окно, чтобы удобная навигация была, можно было ресайзить, закрывать, минимизировать… Эти окна агрегируются в окно 'проводник'?, чтобы:
1. Документы не перекрывали таскбары, менюшки, тулбары.
2. Максимайз вызывал заполнение не всего экрана, а только части проводника.
3. Перемещение фокуса на тулбары, менюшки, прочие, не вызывало потерю видимости документов.

[@veitmen]

Понял. Спасибо! :)

[@kocherman]

Во-первых, почему вы не используете Ext.Direct или хотя бы просто RESTful для обмена информацией между Ext.data.Store и сервером? ИМХО самый простой вариант без лишних бубнов.

Во-вторых, по решению проблемы #1: когда вы удаляете все данные, а потом добавляете уже с новыми, вы задумывались о том, что будет видеть пользователь, когда у него будет стоять курсор на какой-то записи в гриде?

[@freeart]

Про удаление данных не совсем понял о чем вы, этот участок я не менял — этот участок я привел чтобы было понятно в каком месте происходит правка, данные удаляются, грид перерисовывается — не вижу проблемы

[@kocherman]

Да, второпях набрал комментарий. Когда мы удаляем записи из Ext.data.Store, информация, отображаемая в Grid, обновляется (а в нашем случае удаляется). Представим себе ситуацию, когда человек работает с этим гридом. Курсор с грида пропадет. В ExtJS предусмотрено сохранение state, но с вашим решением стандартные возможности ExtJS сохранять состояние работать не будет.

[@freeart]

Мне кажется мы не понимаем друг друга.
Я правильно вас понял что добавление одной строчки
«me.snapshot.addAll(records)»
в метод loadRecords влияет на удаление записей из хранилища?

[@kocherman]

Нет, на удаление записей из хранилища влияет me.clearData();

[@freeart]

Эта строчка присутствует в исходном коде ExtJS 4.0.2a в методе loadRecords и я ее не добавлял.

Не вижу в ней проблемы, т.к. при options.addRecords = false логика поведения предполагает как полную очистку данных, так и состояния грида.

В следующей статье я опишу как эту проблема обойти.

[@freeart]

>В следующей статье я опишу как эту проблема обойти.
Имеется в виду проблема отсутствия метода, который мог бы объединить новые данные со старыми не перерисовывая при этом весь грид.

[@freeart]

docs.sencha.com/ext-js/4-0/source/Store2.html#Ext-data-Store-method-loadRecords

[@kocherman]

Точно… Извиняюсь…

[@kwinch]

Вот лишь несколько доводов в пользу неиспользования нами Ext.Direct:
1. Использование Ext.Direct приводит к тому, что серверные функции (вернее, их имена) «видны» на клиенте
2. API нужно только для связывания, но не для переноса логики с сервера на клиент. Поэтому, на наш взгляд, подход Ext.Direct несколько странен
3. В нашей команде над серверной частью и фронтендом работают разные люди. Нет необходимости знать, какая функция на сервере обеспечивает нужный функционал. Есть документация к API и сборщик API-библиотечки на клиенте (по мотивам аналогичной от Marelle). Структура API задается JSON-ом.

[@knekrasov]

Интересная статья, хотя описанные «проблемы» справедливы и для третьей версии экста.
Особенно интересна, как мне кажется, задача реализации CRUD средствами Ext.data.Store. По крайней мере если не «допиливать» серверную сторону под экст, а допиливать клиентскую часть.
Может быть, когда-нибудь оформлю этот опыт в виде статьи.

[@putnik]

Ага! Значит, в 4-ке концепция плясок с бубном для всего, что выходит за рамки примеров, не изменилось. Ну, что же, не привыкать.

[@AmdY]

>>Cоздание прототипа социальной сети на ExtJS.
думаю, слово «прототип» здесь лишнее. для прототипа всё слишком сложно, для реального проекта тоже не айс.

[@JerryJJ]

Картинка классная! :)