Pull to refresh
Comments 31
Сложнее учитывать ширину столбцов. Например, когда ширина столбцов стоит «Автоматически по всей ширине текста». В этом случае, чтобы подсчитать ширину столбца приходится отрисовать все элементы и подсчитать длину самого наибольшего. А это ну очень долго. Вот тут был бы очень интересен алгоритм, как бы все это сделать без заметного падений производительности? Можно конечно изменять ширину по мере необходимости, но не очень красиво получается у меня это сделать.
Да, для этого нужно рендерить все элементы. Для своего грида я делал очень просто — брал диапазон -100 и +100 от видимой области и брал максимум от ширины, а остальные элементы отбрасывал.

Но, к примеру, Excel, поступает иначе — мне кажется, что он сначала сортирует весь список и отбрасывает повторяющиеся значения и потом собственно рендерит все строки, хотя это тоже долго. У меня ещё есть предположение, что на самом деле можно замерить ширину каждой буквы и довольно точно оценить тем самым полученную ширину без полного рендеринга — скорее всего эту оптимизацию Excel тоже использует.
Зачем менять ширину по очереди у всех, если можно сначала выбрать самое большое значение (копейки времени и ресурсов), а потом посчитать ему ширину?
Если ширина колонки зависит от нескольких внутренних элементов (скажем, слов), то выходит, что ячейка, в которой 100 слов по 1 букве будет меньше, чем ячейка с одним словом из 100 букв (перенос по словам). Отсюда вывод: проходимся по всем ячейкам и выбираем наибольший минимальный элемент. Не вижу проблемы, друзья мои. Хотя я уже сонный, вернусь к дискуссии завтра :)
Ну, это совсем некорректно, потому что ширина, например «lll» явно меньше, чем у «ww», хотя длина при этом будет в полтора раза больше. Это происходит из-за того, что шрифты у нас пропорциональные, а не моноширинные :). Собственно, в этом и проблема
при этом еще и нужно учитывать форматирование, картинки и т.п.
Декомпилируйте Excel :)
А если серьезно, то не изобретайте велосипед, а идите в сорцы Gecko и WebKit и смотрите как они обрабатывают ширину столбцов.
Окей, я не прав, но в чем? Поясните. Ведь там же есть рендеринг таблиц.
Ну дело в том, что в принципе довольно понятно, как рендерятся таблицы в любом браузере, вопрос ведь в том, чтобы это как-нибудь оптимизировать — всё равно Firefox и WebKit относительно честно будут рендрить всё содержимое, а это занимает довольно много времени.
Скажите честно, вы смотрели их алгоритмы? Почему они вам кажется. что они медленно работают? Уж не потому ли, что приходится обрабатывать кучу динамических стилей?
Нет, я не смотрел детально, как они работают, я просто проводил эксперименты с различными количествами элементов. В любом случае, даже если я посмотрю на реализацию, как это поможет в решении задачи выше? Ведь интересно именно решение на HTML/CSS/JS, а не на чем-то другом
UFO landed and left these words here
Однако, я считаю что фальшивый скролл — менее удобно, чем кнопки «вверх» и «вниз», «вперед» и «назад» или пагинация.

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

Например, меня сильно удивило в своё время то, что на маке в областях с горизонтальным и вертикальным скролом двупальцевый жест прокрутки по точпадке по вертикали крутит, а по горизонтали — нет %(
Ну, в своей реализации я учитывал горизонтальный скролл для браузеров, для которых нашел, как это сделать, а именно — для фаерфокса и для webkit
Упс, ща перчитал — и заметил, что как-то умудрился пропустить в предложении про скролл самое важное — что это в java-программах так, а в нативных маковых — всё прекрасно.
Например у меня в NetBeans работает горизонтальный скролл. Хотя там тоже не везде всё так очевидно, каким образом некоторые вещи отрисовываются :)
UFO landed and left these words here
Я долго думал, куда засунуть эту статью, сначала засунул в «Разработку», но, вообще говоря, эта статья описывает алгоритм рендеринга гридов, причём не совсем тривиальный, поэтому это в алгоритмах.
разработал два грида
Один — генерация PDF документа с таблицей в несколько тыс. столбцов и десятки-сотни тыс строк с вложенными таблицами, шрифтами, стилями, с разбиением на страницы на C#. Заказчик за несколько лет не смог найти коммерческую или любую дргую библиотку которая смогла бы переварить такие объемы за адекватное время и сгенерить документ адекватного размера. Первая компания которой заказали такую библиотеку просто не справилась.
Второй на HTML/JS с пейджингом или лайвскролингом на выбор, автоматическая динамическая высота строк, с заморозкой левых столбцов, драг-энд-дроп столбцов таблицы, и куча других плюшек (работает под IE >=6, FF, Webkit, Opera).
Но кому это надо? Все эти проекты фактически под разовые, хоть и дорогие заказы. И каждый раз у каждого заказчика свои тараканы. И эти гриды так и будут делаться каждый раз фактически с нуля.
Не понял вопроса, если честно. Вы предлагаете кому могут понадобиться такие таблицы или пытаетесь угадать, кто заказывал?
Сомневаюсь, что их можно переиспользовать в том виде как они есть. Они основаны/или используют другие продукты. Так что я могу только «переиспользовать» свой опыт в написании таких таблиц.
Я к тому, что такие штуки легко генерятся ТеХом. Вот давеча генерили кучу всякой лабуды скриптом, который выдаёт ТеХ, а потом собирается в PDF.
Это все хорошо пока речь идет о десятке столбцов и сотнях-тысяче строк. Попробуйте сделать своим скриптом «маленькую» тестовую табличку — пару тысяч столбцов и два десятка тыс строк со случайными числами и разбейте на страницы скажем слева направо сверху вниз. Я молчу, что там еще надо было генерить промежуточные итоги и вставлять в таблицу. Сделайте просто табличку и поделитесь результатами — время/память/размер PDF документа.
Страшного как раз то, о чем тут говориться — надо сверстать огромную таблицу с неизвестной шириной/высотой столбцов, которая, считай, не помещается в памяти целиком. С многоуровневым вложением, с расчетом промежуточных данных, вставка которых в таблицу поменяет опять же верстку. Если ТеХ справляется было бы интересно посмотреть. Чисто для спортивного интереса :) так как это пройденный в жизни этап уже N лет назад, когда 1Ггц было вполне неплохой частотой для компьютера.
А вообще я о другом. Данные можно генерить чем угодно, а вёрстку их оставить ТеХу, благо он это делает замечательно.
Ситуация корая очень часто встречается при разработке на extjs. Гриды мощные но buffered view возможен не для всех видов гридов. Также буфферизированный вариант полагается на фиксированную высоту строки. Я уже полгода с перерывами пишу свой плагин который непривязан к определенному типу view для грида. Уже успешно работает на строках с динамической высотой, а также на смеси когда строка в рекордсете есть но невидима (закрытые ноды дерева или группированный грид с закрытой группой). Осталось допилить всякие неизбежные визуальные глюки и я буду счастлив. Код для общественности увы выложить не смогу — уже слишком сильно кастомный вариант второго extjs у меня + купленная коммерческая лицензия.
Не стыдитесь писать по русски. Термин «датагрид» вместо «табличное представление» — выглядит эффектнее и символов в нем меньше, но понять сразу о чем идет речь только по заголовку получится не у каждого.
заголовок «Как работают и зачем нужны табличные представления» я бы не сразу и понял :)
а датагрид — он и в Африке датагрид :)

как компромис можно писать «Как работают и зачем нужны табличные представления (datagrid)»
Only those users with full accounts are able to leave comments. Log in, please.