Pull to refresh

Comments 23

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

P. S. И все-же ExtJS — очень крутая штука. В javascript, она для меня как Qt для С++.
Проблему с afterrender я обошел немного по другому — отказался от событий ExtJS, а привязывал свои через делегат jQuery.

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

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

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

Про удаление данных не совсем понял о чем вы, этот участок я не менял — этот участок я привел чтобы было понятно в каком месте происходит правка, данные удаляются, грид перерисовывается — не вижу проблемы
Да, второпях набрал комментарий. Когда мы удаляем записи из Ext.data.Store, информация, отображаемая в Grid, обновляется (а в нашем случае удаляется). Представим себе ситуацию, когда человек работает с этим гридом. Курсор с грида пропадет. В ExtJS предусмотрено сохранение state, но с вашим решением стандартные возможности ExtJS сохранять состояние работать не будет.
Мне кажется мы не понимаем друг друга.
Я правильно вас понял что добавление одной строчки
«me.snapshot.addAll(records)»
в метод loadRecords влияет на удаление записей из хранилища?

Нет, на удаление записей из хранилища влияет me.clearData();
Эта строчка присутствует в исходном коде ExtJS 4.0.2a в методе loadRecords и я ее не добавлял.

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

В следующей статье я опишу как эту проблема обойти.
>В следующей статье я опишу как эту проблема обойти.
Имеется в виду проблема отсутствия метода, который мог бы объединить новые данные со старыми не перерисовывая при этом весь грид.
Вот лишь несколько доводов в пользу неиспользования нами Ext.Direct:
1. Использование Ext.Direct приводит к тому, что серверные функции (вернее, их имена) «видны» на клиенте
2. API нужно только для связывания, но не для переноса логики с сервера на клиент. Поэтому, на наш взгляд, подход Ext.Direct несколько странен
3. В нашей команде над серверной частью и фронтендом работают разные люди. Нет необходимости знать, какая функция на сервере обеспечивает нужный функционал. Есть документация к API и сборщик API-библиотечки на клиенте (по мотивам аналогичной от Marelle). Структура API задается JSON-ом.
Интересная статья, хотя описанные «проблемы» справедливы и для третьей версии экста.
Особенно интересна, как мне кажется, задача реализации CRUD средствами Ext.data.Store. По крайней мере если не «допиливать» серверную сторону под экст, а допиливать клиентскую часть.
Может быть, когда-нибудь оформлю этот опыт в виде статьи.
Ага! Значит, в 4-ке концепция плясок с бубном для всего, что выходит за рамки примеров, не изменилось. Ну, что же, не привыкать.
>>Cоздание прототипа социальной сети на ExtJS.
думаю, слово «прототип» здесь лишнее. для прототипа всё слишком сложно, для реального проекта тоже не айс.
UFO just landed and posted this here
Sign up to leave a comment.

Articles

Change theme settings