Совместимость с IE7
 

Доброе утро всем.
Я продолжаю улучшать парсер логов SHOUTcast сервера. На этот раз я написал на JavaScript четыре функции, первые две из которых совсем примитивны (меняют ширину столбцов определённого класса в таблицах), а вторые две чуть похитрее. Вот исходный код:

function groupSucc() {
    var tables = document.getElementsByTagName('table')
    for (var i = 0; i < tables.length; i++) {
        var ip = ''
        var from = 0
        var merged = 1
        var rows = tables[i].rows
        for (var j = 1; j < rows.length; j++) {
            if (rows[j].cells[0].innerHTML != ip) {
                ip = rows[j].cells[0].innerHTML
                from += merged
                merged = 1
            } else {
                merged++
                rows[from].cells[0].setAttribute('rowspan', merged)
                rows[from].cells[4].setAttribute('rowspan', merged)
                rows[j].deleteCell(0)
                rows[j].deleteCell(3)
            }
        }
    }
}

function ungroupSucc() {
    var tables = document.getElementsByTagName('table')
    for (var i = 0; i < tables.length; i++) {
        var from = 0
        var merged = 1
        var rows = tables[i].rows
        for (var j = 1; j < rows.length; j++) {
            if (merged > 1) {
                rows[j].insertCell(0)
                rows[j].insertCell(-1)
                rows[j].cells[0].innerHTML = rows[from].cells[0].innerHTML
                rows[j].cells[4].innerHTML = rows[from].cells[4].innerHTML
                rows[j].cells[4].setAttribute('align', 'right')
                merged--
                if (merged == 1) {
                    rows[from].cells[0].removeAttribute('rowspan')
                    rows[from].cells[4].removeAttribute('rowspan')
                }
                continue;
            }
            if (rows[j].cells[0].hasAttribute('rowspan')) {
                from = j
                merged = parseInt(rows[j].cells[0].getAttribute('rowspan'))
            }
        }
    }

При этом в Firefox и Opera всё работает на ура. Проблема в том, что в IE7, в отличие от Восьмого, не встроено нормальных средств отладки, и я, честно говоря, не понимаю, что он мне хочет сказать. Все использованные мной методы поддерживаются стандартами W3C, смотрел в сети. Он что, не соблюдает эти стандарты? Можно ли как-то "обхитрить" его?

Вот ссылка на парсер: http://popov654.pp.ru/parser3

Лог-файл для анализа в аттаче (ZIP-архив)

Я поясню немного, что делает этот код, чтобы Вам было легче его читать. Он объединяет в группу все строки, идущие подряд и при этом имеющие одинаковый IP в первой колонке. Он сливает их с помощью атрибута rowspan и удаления лишних ячеек.
Обратный процесс аналогичен: берём из rowspan размер группы, добавляем нужное количество ячеек (содержимое копируем из первой), и затем, когда счётчик станет равен единице, удаляем атрибут rowspan у первой. Что тут ему не нравится... :-/

Не только не соблюдает ,но ещё использует не JS а JScript

Что не работает то? Запустилось без ошибок http://img854.imageshack.us/img854/3929/29335642.jpg правда с файлом меньшего объема.

Octane, а Вы разве не видите, что у Вас на скрине всё поехало на фиг после второго нажатия на флажок? :) Вот и у меня так же)

Ну они вроде мало чем отличаются... насколько я слышал. А как выкрутиться? Он, как я понял, не знает некоторых методов (к сожалению, каких именно - не очевидно). Надо видимо найти аналог для IE :)

Кстати, там Notice вылез, т.к. была небольшая ошибка в PHP коде в оптимизационной части - исправил только что. Но сдвиг не из-за этого совсем происходит :)

Так что, никто не знает? Там похоже проблема не в том, что IE не поддерживает hasAttribute() и removeAttribute() (если верить таблице, поддерживал ещё с пятой версии). У меня таблица разваливается ещё на этапе ГРУППИРОВКИ (первая функция), там этих методов нет ещё! Правда, ошибка про неподдерживаемый метод вылазит при нажатии флажка уже во второй раз - но это и немудрено, потому что там уже DOM неправильный и во второй функции происходит чёрт-те что. Почему в FF и Opera всё группируется нормально? Где я налажал?

Добавлено спустя две минуты:
Судя по внешнему виду руин таблицы, создаётся такое ощущение, что ячейки удалились, а атрибут rowspan проигнорирован... С чего бы вдруг

лень разбираться :)

hasAttribute нет в IE<9

Сорри, всё оказалось элементарно. Надо было просто отказаться от атрибутов и воспользоваться свойсвом rowSpan. Вот исправленный кроссбраузерный код:

function groupSucc() {
    var tables = document.getElementsByTagName('table')
    for (var i = 0; i < tables.length; i++) {
        var ip = ''
        var from = 0
        var merged = 1
        var rows = tables[i].rows
        for (var j = 1; j < rows.length; j++) {
            if (rows[j].cells[0].innerHTML != ip) {
                ip = rows[j].cells[0].innerHTML
                from += merged
                merged = 1
            } else {
                merged++
                rows[from].cells[0].rowSpan = merged
                rows[from].cells[4].rowSpan = merged
                rows[j].deleteCell(0)
                rows[j].deleteCell(3)
            }
        }
    }
}

function ungroupSucc() {
    var tables = document.getElementsByTagName('table')
    for (var i = 0; i < tables.length; i++) {
        var from = 0
        var merged = 1
        var rows = tables[i].rows
        for (var j = 1; j < rows.length; j++) {
            if (merged > 1) {
                rows[j].insertCell(0)
                rows[j].insertCell(-1)
                rows[j].cells[0].innerHTML = rows[from].cells[0].innerHTML
                rows[j].cells[4].innerHTML = rows[from].cells[4].innerHTML
                rows[j].cells[4].setAttribute('align', 'right')
                rows[j].cells[0].firstChild.href = '#'   // Внимание! Если эту строку закомментировать
                merged--
                if (merged == 1) {
                    rows[from].cells[0].rowSpan = 1
                    rows[from].cells[4].rowSpan = 1
                }
                continue;
            }
            if (rows[j].cells[0].rowSpan > 1) {
                from = j
                merged = parseInt(rows[j].cells[0].getAttribute('rowspan'))
            }
        }
        alert(tables[0].rows[2].cells[0].innerHTML);   // то здесь выведет <a href="#" onclick="...">
        alert(tables[0].rows[3].cells[0].innerHTML);   // а здесь - <a href="http://popov654.pp.ru/parser/parser.php#" onclick="...">  В общем случае это не опасно, однако поскольку данный сценарий опирается на идентичность innerHTML ячеек первой колонки, это может привести к неприятным последствиям (а именно, при следующей группировке сгруппируется всё, кроме первых строчек, и получится дублирование первой строки)

    }

Просьба обратить внимание на то, что, как отмечено в коде, IE изменяет атрибут ref ссылок при копировании. Для остальных браузеров эта строка не нужна.

****************

Мдааа... слов нет)
А ещё к этому добавим, что под XP нет IE9 (многие на ней сидят)

По делу (ну надо же как-то подытожить). В общем, как я понял, дело было в том, что атрибут rowspan существовал, выводился (равным 1), но... не изменялся. Вероятно, в IE он только для чтения (если такое вообще возможно). Потому что других объяснений я не вижу, он так и оставался равен 1 после всех манипуляций. Ну отсюда и лаги. В первой функции ячейки удалялись, а верхняя не растягивалась вниз. Во второй функции ячейки должны бы вставляться, но количество вставок бралось из rowspan, и только при условии что оно больше 1, а rowspan везде был 1. Так что вторая функция и вовсе ничего не делала, плюс ругалась при попытке обратиться к свойствам якобы вставленных ячеек :)

да ничего страшного в этом нет, getAttribute(name) вернет null для несуществующего атрибута.

Вообще я бы не пытался изменить существующую таблицу, а создавал бы каждый раз новую с помощью JavaScript, на основе данных, пришедших с сервера в JSON-формате.

А, и правда. Главное чтобы осталные методы работали)

Насчёт JSON формата - я к сожалению не умею им пользоваться. Я вообще о нём к сожалению только слышал. У меня вся HTML-разметка таблицы генерируется PHP-скриптом. Зато ресурсы локального компьютера сильно не расходуются, всю работу берёт на себя сервер

Насчёт IE я похоже был не прав, всё с ним в порядке. Ну разве что поддержка атрибутов не полная, но это не смертельно :)
Что же до Седьмой его версии, один недостаток - ужасная тормозятина, особенно на не очень мощных машинах. Из всех установленных у меня браузеров он самый медленный, причём разница любых операций, особенно с JS, этак раза в 3-4, что весьма заметно. Даже на огромных страницах статического HTML он начинает подвисать.

И я бы разумеется давно поставил IE8, но одно останавливает: вернуться назад уже нельзя (в смысле даунгрейд невозможен, некорректная деинсталляция Восьмёрки имеет место), а мне крайне хотелось бы тестить свои проекты и в IE7 тоже. Поэтому IE8 стоит пока на запасной машине :)

Текстовое описание JS-объекта, ничего сложного http://json.org/ , в PHP вместо HTML-разметки собираешь массив и возвращаешь jscon_encode($data), в JavaScript выполняешь JSON.parse(jsonString), получишь к примеру такой объект данных:

data = {
    clients: [
        {ip: "192.168.0.1", listenTime: "00:10", when: "00:00-00:30", player: "NSPlayer", connections: 3},
        {ip: "192.168.0.2", listenTime: "00:20", when: "00:10-01:00", player: "BSPlayer", connections: 2},
        {ip: "192.168.0.3", listenTime: "00:30", when: "00:20-01:10", player: "Opera", connections: 8},
        {ip: "192.168.0.4", listenTime: "00:40", when: "00:30-01:20", player: "Firefox", connections: 5},
        {ip: "192.168.0.5", listenTime: "00:50", when: "00:40-01:30", player: "Chrome", connections: 1}
    ]
}

И уже на основе основе этих данных в зависимости какую там кнопку нажали, создаешь новую таблицу и удаляешь старую.
Таким образом знать о HTML-разметке надо будет только в одном месте, не придется выполнять медленные операции преобразования DOM-элементов таблицы, можно отрисовывать таблицу частями, данные с сервера можно будет отдавать не только этому скрипту.

Да тут не сверх большие вычисления. В новых браузерах, наверное, вообще без сервера можно обойтись, открыв файл через FileAPI и сделав все на клиенте.

Можно попробовать извлекать таблицу из дерева, перед изменением, должно ускорить работу.

Виртуальные машины в помощь.

Ссылку посмотрел, удобно)
Но вопросы остались

Разве всю таблицу удалять рациональнее/быстрее чем то, что я делаю сейчас (двигая n-ное количество строк)?
Ведь большая часть данных вообще может в итоге остаться на месте.

Это как? Путём, опять же, динамического изменения DOM? Но мне это не нужно, у меня данные весьма статические, меняться в процессе выполнения они уж точно не будут. Поэтому и перезагружать какие-то куски данных необходимости нет.

Опять же, пока это не нужно) Я этим скриптом и ограничусь, ну маскимум сделаю в 4-ой версии импорт в базу данных, чтобы затем в другом скрипте можно было рисовать месячные диаграммы с помощью GDlib2.

Да мне бы желательно чтобы во всех работало... Кстати, FileAPI поддерживатеся IE9?

ОК, как мне это сделать?)

Знаю, даже иногда пользуюсь для проверки Java десктоп-приложений. Но HDD у меня небольшой и почти полностью уже забит (в т.ч. и виртуальными машинами, коих уже 3-4), так что я не могу позволить себе ещё 2 машины с XP поставить с IE6 и IE7. Вот и юзаю для этого нетбук и второй ноут соответственно)

Куча модификаций innerHTML для каждой ячейки сильно тормозит работу, добавление целой таблицы должно быть быстрее, да и в виде строки её можно сгенерировать, а потом 1 раз обновить: container.innerHTML = tableHTML;

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

Вроде нет, по крайней мере нет объекта FileReader

removeChild

Мне кажется, или я потом замучаюсь всё это дело вставлять обратно insert-ом? У меня там 3 таблицы, да ещё кроме них есть ещё кой-чего :)

Очень интересный подход, здорово. То есть браузер кодированные данные получает, но не интерпретирует их -> прирост скорости (если я правильно понял)

Не вижу смысла... Только если она бы как-нибудь догружалась сама, как Обсуждения ВКонтакте, по ходу прокрутки. Юзера и так может в случае беглого анализа напрячь уже то, что надо между блоками по 3 дня переключаться) А Вы предлагаете ещё мельче дробить :)
Меня по скорости в FF5+ и Opera 11 всё устраивает совершенно. На других браузерах просто не тестил ещё, но наверняка тоже виснуть не будет (взять хоть Chrome или Safari). Это только в IE тормоза, и то с оговоркой что это Седьмая версия (в Восьмой всё шустрее на порядок, насколько я знаю по опыту с другими интернет-ресурсами).

Не, но на будущее я обязательно учту)
Кстати, может быть Вы что-нибудь и по другому моему проекту посоветуете (общая суть там похожа)?
Это школьный классный журнал, там редактируются оценки учителями по разным предметам. Он ещё сильно недоработан: нет разграничений прав доступа для разных учителей, нет диаграмм статистики красивых... Но он уже вполне себе функционирует (текущая версия 3.2, сборка 28/07/2009).
Вопрос: как ускорить сохранение и загрузку данных (идеи есть, но хотелось бы услышать предложения от кого-то ещё) и заодно снять лимит в 50 колонок (оценок)? Сейчас схема ужасно тупая и неграмотная: ВСЕ данные берутся из базы, выводятся в гигантскую форму... потом форма редактируется, юзер (педагог) нажимает кнопку... и вся эта куча данных уходит на сервер. Старая таблица предмета очищается и всё вносится по новой. Я конечно понимаю, что это не PHP форум... и всё же, здесь ведь работа на стыке)

Есть мысль во-первых грузить не всё... И сохранять видимо тоже не всё, а только то, что поменялось.
Далее, для этого видимо стоит как-то привязать id записей в базе к текстовым полям. Не, ну то есть понятно, как привязать, но сейчас там немножко другая схема... при нажатии на кнопку "вставить столбец" пустой столбец вставляется в произвольное место таблицы, но (!) посредством PHP при перезагрузке. То есть скрипт читает данные из базы, генерирует разметку HTML и в нужном месте вставляет пустые ячейки в каждой строке. Но все id ячеек-инпутов идут последовательно и с id записей в базе никак не связаны (если удалить столбец из середины, то скрипт просто его в разметку формы не выведет, и при сохранении эти данные на сервер не пойдут, так как в форме ввода их уже нет). И id при перезаписи базы уже будут другие (так как id определяются тем инпутом, куда попали данные при выводе).

Проблема там ещё и в том, что id местами используется скриптом для сортировки данных вместо других параметров. Кроме того, id инпутов задают ещё и порядок сбора данных из глобального массива $_POST[] при записи в базу. Если я привяжу как сказал, то при вставке столбца в таблицу нумерация вся при таком подходе нарушится, то есть запись должна производиться слева направо, а будет производиться (скрипт идёт по возрастанию id инпутов) вообще хаотично (мы ведь вставку колонок делали), то есть порядок записи непредсказуем. Значит надо и запись перестраивать заодно...

Вот и думаю: может, когда фокус уходит с поля с оценкой, сразу и данные отправлять в базу (в случае успешной валидации разумеется, валидация уже есть)? Тогда и скрипт записи проще станет. Правда, с сортировкой при выводе надо будет поработать, чтобы она id нигде не использовала :)

Кстати, я сделал ещё одну группировку, на этот раз полную. Долго думал на чём делать - на PHP или на JavaScript, в итоге выбрал последнее. На PHP конечно вышло бы проще и быстрее в плане отладки, но... там потом было бы заморочно интегрировать это дело, разбираться со строкой запроса в трекере, продумывать как осуществить отключение левого флажка группировки смежных сессий... Иначе при первом нажатии ничего не произойдёт, а при втором функция попытается заведомо сгруппированную разметку разгруппировать, и выйдет... ну ничего страшного не выйдет, но общей хронологии не будет после такого действия. В отличие от штатного режима группировки подряд идущих сессий с одного IP, оно совершенно обратимо, и после разгруппировки общая хронология сохраняется... Ведь она в сущности и не нарушалась (в отличие от того, что я сделал сейчас).

Выкрутился так: обработка через JavaScript по аналогии с первой функцией, и оба флажка блокируются до загрузки нового блока данных (по нажатию на третий флажок), однако поскольку тут вычислительная сложность куда больше, то браузер на небольшое время всё-таки виснет. Mozilla Firefox выполняет операцию примерно за 3/4 секунды с небольшим, IE - за 2 секунды. Для сравнения - простая группировка в Firefox происходит почти мгновенно (около 1/4 секунды), в IE - за 1 секунду с небольшим (замерял только что). Но Опера всех превзошла, я просто в ауте. Она ОБЕ группировки моментально делает, за доли секунды. КАК им это удалось? :blink: :dance:
В принципе для анализатора логов лёгкие тормоза не критичны... Однако мне всё-таки жутко интересно, как ВКонтакте делают такой быстрый код (да и не только они, взять хоть формочку редактирования сообщения, в которую я сейчас пишу, она вообще вылетает мгновенно практически по нажатию на кнопку) :)

Итоговый код третьей функции:

function groupByIP() {
    var tables = document.getElementsByTagName('table')
    for (var i = 0; i < tables.length; i++) {   //для каждой таблицы в документе
        var map = new Array()           //здесь будем хранить объекты (небольшие ассоциативные массивы)
                                                 //с информацией о группах
        var rows = tables[i].rows
        for (var j = 1; j < rows.length; j++) {   //для каждой строки в таблице
            var found = false      //этот флаг сигнализирует о том, что группа уже существует, т.е. её объект найден
            for (var k = 0; k < map.length; k++) {    //обходим массив map
                if (map[k]['ip'] == rows[j].cells[0].innerHTML) {   //группа найдена!
                    found = true
                    var index = map[k]['from'] + map[k]['entries']        //вычисляем позицию для вставки новой строки
                                                                                        //(вставляем снизу)
                    if (index == j) {      //если первая строка группы прямо над нами, удалять текущую строку незачем
                        rows[j].deleteCell(0)         //вместо этого удаляем в ней первую и последнюю ячейки
                        rows[j].deleteCell(-1)
                    } else {
                        tables[i].insertRow(index)      //вставляем новую строчку в таблицу
                        if (index <= j) j++;           //если вставка произошла выше, корректируем текущий индекс j (!)
                        for (var m = 3; m >= 1; m--) {     //добавляем в новую строку ячейки и копируем содержимое
                            rows[index].insertCell(0)
                            rows[index].cells[0].innerHTML = rows[j].cells[m].innerHTML
                        }
                        rows[index].cells[0].align = 'center'     //копируем атрибуты
                        tables[i].deleteRow(j)    //удаляем старую строку
                        if (index <= j) j--;      //и корректируем индекс в обратную сторону (!!)
                    }
                    rows[map[k]['from']].cells[0].rowSpan += 1      //расширяем первую и последнюю ячейки
                    rows[map[k]['from']].cells[4].rowSpan += 1      //ещё на одну строчку вниз
                    rows[map[k]['from']].cells[0].style.verticalAlign = 'top'      //Ставим выравнивание так, чтобы текст в
                    rows[map[k]['from']].cells[4].style.verticalAlign = 'top'      //огромных ячейках выводился сверху, а не
                                                                                          //посередине
                    map[k]['entries']++  //увеличиваем размер группы на единицу
                    for (var l = 0; l < map.length; l++) {   //(важно!) проходим по всему массиву объектов и у тех групп,
                                                             //которые расположены ниже по таблице, корректируем
                                                             //начальные индексы
                        if (map[l]['from'] > map[k]['from']) {
                            map[l]['from']++
                        }
                    }
                    break;  //дальше по массиву можно не идти
                }
            }
            if (!found) {     //если же группа не найдена, создаём для неё новый объект...
                var entry = {
                    from: j,
                    ip: rows[j].cells[0].innerHTML,
                    entries: 1
                }
                map.push(entry)   //и помещаем его в массив map
            }
        }
    }
}

Сорри, не осилил многабукф :)

дауж... аж глаза разбежались... Сложно воспринять такое количество букв.. Не надо описывать все свои действия и то как оно и почему оно у тебя так сработало. Просто опиши проблему и все.

P.S. Читаю форум и вижу:
Итог: человек описал проблему, как написал книгу, рассказывая совершенно ненужный материал и выдал куча кода, но не описал простого, или не описал по простому: Все, вот и простое объяснение.

Не, я извиняюсь)
Вы не так поняли)
Проблема решена уже давно, я этот код так выложил... для истории. Ну вдруг кого-то заинтересует когда-нибудь. А всё что я пишу начиная с середины второй страницы - оффтоп, не имеющий ничего общего с темой треда. Так что можно тему закрывать :D

Единственное, что немного волнует - тормознутость этого кода в IE7, причём виноват в этом скорее код чем браузер...

Третья функция работает совершенно исправно. Единственное, я думал кто-нибудь предложит какую-нибудь оптимизацию, что-нибудь порациональнее сделать, чтобы быстрее всё это исполнялось. Впрочем, я думаю это вряд ли возможно в этой ситуации

один пример :

for (var i = 0; i < tables.length; i++) {

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

т.е. надо так.. примерно

for (var i = 0, tablesLength = tables.length; i < tablesLength; i++) {

т.е. стоит поработать над оптимизацией, если скорость кода видима невооруженным глазом

и еще : попробуйте сжать код, это тоже ускорит его