Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Сложнее учитывать ширину столбцов. Например, когда ширина столбцов стоит «Автоматически по всей ширине текста». В этом случае, чтобы подсчитать ширину столбца приходится отрисовать все элементы и подсчитать длину самого наибольшего. А это ну очень долго. Вот тут был бы очень интересен алгоритм, как бы все это сделать без заметного падений производительности? Можно конечно изменять ширину по мере необходимости, но не очень красиво получается у меня это сделать.
Да, для этого нужно рендерить все элементы. Для своего грида я делал очень просто — брал диапазон -100 и +100 от видимой области и брал максимум от ширины, а остальные элементы отбрасывал.
Но, к примеру, Excel, поступает иначе — мне кажется, что он сначала сортирует весь список и отбрасывает повторяющиеся значения и потом собственно рендерит все строки, хотя это тоже долго. У меня ещё есть предположение, что на самом деле можно замерить ширину каждой буквы и довольно точно оценить тем самым полученную ширину без полного рендеринга — скорее всего эту оптимизацию Excel тоже использует.
Но, к примеру, Excel, поступает иначе — мне кажется, что он сначала сортирует весь список и отбрасывает повторяющиеся значения и потом собственно рендерит все строки, хотя это тоже долго. У меня ещё есть предположение, что на самом деле можно замерить ширину каждой буквы и довольно точно оценить тем самым полученную ширину без полного рендеринга — скорее всего эту оптимизацию Excel тоже использует.
Ну, это совсем некорректно, потому что ширина, например «lll» явно меньше, чем у «ww», хотя длина при этом будет в полтора раза больше. Это происходит из-за того, что шрифты у нас пропорциональные, а не моноширинные :). Собственно, в этом и проблема
при этом еще и нужно учитывать форматирование, картинки и т.п.
Ну дело в том, что в принципе довольно понятно, как рендерятся таблицы в любом браузере, вопрос ведь в том, чтобы это как-нибудь оптимизировать — всё равно Firefox и WebKit относительно честно будут рендрить всё содержимое, а это занимает довольно много времени.
Однако, я считаю что фальшивый скролл — менее удобно, чем кнопки «вверх» и «вниз», «вперед» и «назад» или пагинация.
Почему?
Фальшивый скрол фальшив, ибо зачастую разработчики своих фишечек очень часто не учитывают того, что на разных платформах для родных скролов есть разные особенности, полюбившиеся пользователям этих платформ.
Например, меня сильно удивило в своё время то, что на маке в областях с горизонтальным и вертикальным скролом двупальцевый жест прокрутки по точпадке по вертикали крутит, а по горизонтали — нет %(
Например, меня сильно удивило в своё время то, что на маке в областях с горизонтальным и вертикальным скролом двупальцевый жест прокрутки по точпадке по вертикали крутит, а по горизонтали — нет %(
Ну, в своей реализации я учитывал горизонтальный скролл для браузеров, для которых нашел, как это сделать, а именно — для фаерфокса и для webkit
разработал два грида
Один — генерация PDF документа с таблицей в несколько тыс. столбцов и десятки-сотни тыс строк с вложенными таблицами, шрифтами, стилями, с разбиением на страницы на C#. Заказчик за несколько лет не смог найти коммерческую или любую дргую библиотку которая смогла бы переварить такие объемы за адекватное время и сгенерить документ адекватного размера. Первая компания которой заказали такую библиотеку просто не справилась.
Второй на HTML/JS с пейджингом или лайвскролингом на выбор, автоматическая динамическая высота строк, с заморозкой левых столбцов, драг-энд-дроп столбцов таблицы, и куча других плюшек (работает под IE >=6, FF, Webkit, Opera).
Но кому это надо? Все эти проекты фактически под разовые, хоть и дорогие заказы. И каждый раз у каждого заказчика свои тараканы. И эти гриды так и будут делаться каждый раз фактически с нуля.
Один — генерация PDF документа с таблицей в несколько тыс. столбцов и десятки-сотни тыс строк с вложенными таблицами, шрифтами, стилями, с разбиением на страницы на C#. Заказчик за несколько лет не смог найти коммерческую или любую дргую библиотку которая смогла бы переварить такие объемы за адекватное время и сгенерить документ адекватного размера. Первая компания которой заказали такую библиотеку просто не справилась.
Второй на HTML/JS с пейджингом или лайвскролингом на выбор, автоматическая динамическая высота строк, с заморозкой левых столбцов, драг-энд-дроп столбцов таблицы, и куча других плюшек (работает под IE >=6, FF, Webkit, Opera).
Но кому это надо? Все эти проекты фактически под разовые, хоть и дорогие заказы. И каждый раз у каждого заказчика свои тараканы. И эти гриды так и будут делаться каждый раз фактически с нуля.
TeX?
Не понял вопроса, если честно. Вы предлагаете кому могут понадобиться такие таблицы или пытаетесь угадать, кто заказывал?
Сомневаюсь, что их можно переиспользовать в том виде как они есть. Они основаны/или используют другие продукты. Так что я могу только «переиспользовать» свой опыт в написании таких таблиц.
Сомневаюсь, что их можно переиспользовать в том виде как они есть. Они основаны/или используют другие продукты. Так что я могу только «переиспользовать» свой опыт в написании таких таблиц.
Я к тому, что такие штуки легко генерятся ТеХом. Вот давеча генерили кучу всякой лабуды скриптом, который выдаёт ТеХ, а потом собирается в PDF.
Это все хорошо пока речь идет о десятке столбцов и сотнях-тысяче строк. Попробуйте сделать своим скриптом «маленькую» тестовую табличку — пару тысяч столбцов и два десятка тыс строк со случайными числами и разбейте на страницы скажем слева направо сверху вниз. Я молчу, что там еще надо было генерить промежуточные итоги и вставлять в таблицу. Сделайте просто табличку и поделитесь результатами — время/память/размер PDF документа.
ну и что страшного?
Страшного как раз то, о чем тут говориться — надо сверстать огромную таблицу с неизвестной шириной/высотой столбцов, которая, считай, не помещается в памяти целиком. С многоуровневым вложением, с расчетом промежуточных данных, вставка которых в таблицу поменяет опять же верстку. Если ТеХ справляется было бы интересно посмотреть. Чисто для спортивного интереса :) так как это пройденный в жизни этап уже N лет назад, когда 1Ггц было вполне неплохой частотой для компьютера.
А вообще я о другом. Данные можно генерить чем угодно, а вёрстку их оставить ТеХу, благо он это делает замечательно.
Ситуация корая очень часто встречается при разработке на extjs. Гриды мощные но buffered view возможен не для всех видов гридов. Также буфферизированный вариант полагается на фиксированную высоту строки. Я уже полгода с перерывами пишу свой плагин который непривязан к определенному типу view для грида. Уже успешно работает на строках с динамической высотой, а также на смеси когда строка в рекордсете есть но невидима (закрытые ноды дерева или группированный грид с закрытой группой). Осталось допилить всякие неизбежные визуальные глюки и я буду счастлив. Код для общественности увы выложить не смогу — уже слишком сильно кастомный вариант второго extjs у меня + купленная коммерческая лицензия.
Не стыдитесь писать по русски. Термин «датагрид» вместо «табличное представление» — выглядит эффектнее и символов в нем меньше, но понять сразу о чем идет речь только по заголовку получится не у каждого.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как работают и зачем нужны датагриды