Pull to refresh

Comments 21

Спасибо за статью. В апстрим не пробовали концепции/патчи пропихнуть?
и, кстати, вроде публикация на эту тему с этим решением уже была. Или я ошибаюсь?
вспомнил, там и файлик есть и я его пробовал. Ну и память... забывать стал ;)
да, моё :) но там были только оптимизации, связанные с колонками и динамическим обновлением правил css при загрузке страници. в итоге я вообще избавился от обновления стилей.
ой, сорри. да, на самом деле, нужно вставить линк на оригинальный грид. а своего пока я не выкладывал.
Актуальная информация, спасибо — та же проблема с 20+ колонками и 50+ строками…
[quote]Операции по удалению/вставке/редактированию работали очень медленно, если количество строк было больше 20 (при количестве колонок больше 15ти). Оно и понятно, таблица – это не просто массив, а целый объект, которые нужно пересчитать/перерисовать. [/quote]

Мда, верно тут было недавно сказано, про тормознутость современных систем: на 486 с DOS, такая операция бы летала.
>> Данная статья содержит технические сведения. Если вы не понимаете о чем здесь написано, пожалуйста, не минусуйте.

Докатились... :(
внимание! при чтении данной заметки придется задействовать головной мозг! при отсутствии головного мозга разрешается поставить посту минус.
для чтения данной статьи требуется не быть мудаком. если вы все таки мудак, то, пожалуйста, не минусуйте. :)
>> я все еще остаюсь поклонником EXT JS. Другой библиотеки, которая была бы такой же логичной и предлагала такие возможности я не знаю.

А на чём написан проект? Если на java, то GWT даёт максимальные возможности использовать ООП при написании аяксовой клиентской части (в том числе и полноценное unit-тестирование). А некоторые из многочисленных библиотек виджетов для JSF (например, IceFaces) вполне покрывают возможности EXT JS.

Это не исключает, впрочем, проблем с большими гридами у них у всех :) Но, имхо, проще и приятнее делать ревизию java-кода, чем javascript.
мы используем java. но GWT решено было не использовать из-за рисков: нет реальных сделанных проектов на GWT в компании, кроме того, GWT генерит странные странички и мы немножно испугались :) , что не всегда сможем нарисовать то, что уже есть отверстанное на прототипе.
Принимаю участие в разработке интерфейса пользователя платежной системы ОДНО.КАСАНИЕ который выполнен на как 100% HTA под IE6, работает в режиме самообслуживание более чем на 500 терминалах. Проекту 2 года.

Более 5000 строк JSCript кода. Используется технологии ActiveX (для работы с оборудованием), AJAX (для взаимодействия с сервером), DOM (для визуального интерфейса пользователя) и ряд других менее значимых.

На протяжении проекта решали массы задач, начиная с каскадных стилей и скорости работы HTA в IE, заканчивая Memory leak в IE при активном использовании DOM-модели.

Выбранная технология при встрече с определенными проблемами, типа Memory leak разочаровывала, но в целом, HTML позволяет сделать более красочный и удобный интерфейс-пользователя, интерпретирующий язык позволяет производить более оперативную разработку кода.

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

HTA - отличная технология, но не всегда, например, сейчас мы ее, наверное отклоним, при выборе технологии для нового проекта, т.к. интерпретирующая форма с открытым кодом хороша, но если HTA установлен у пользователя-человека, то он может внести изменения в код, которые могут быть злонамерянными. Конечно, можно предупредить эти возможности, вот например, использовав технологию "Asynchronous Pluggable Protocol".
Когда мы реализовывали редактируемый датагрид в одном проекте — мы не использовали таблицы вообще. В IE таблицы работают ужасно медленно.


<div class="row">
<div class="col col-price"><span>$13.68</span><input value="$13.68"/><i/></div>
</div>


Как-то так :) Последний тэг i используется для плавного фэйда в конце ячейки :)
Only those users with full accounts are able to leave comments. Log in, please.