Решение JS-задачи про таблицу

[s0rr0w]

Сюда можно выкладывать ссылки на решение задачи про таблицу, описанной в этой теме

Edited October 20, 2012 by s0rr0w

[mishka]

http://jsfiddle.net/tGu2Q/

Буду рад критике.

[mishka]

Не ужели идеальное решение и ни у кого не найдется ни комментариев ни критики?

s0rr0w, неужели и тебе нечего добавить?

[s0rr0w]

Я вечером напишу, хорошо? Выходные все-таки...

[mishka]

Я вечером напишу, хорошо? Выходные все-таки...

Да, конечно. Спасибо. Жду.

[lexxcode]

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

Я вот пробовал получать ячейку таблицы без первоначального обхода таблицы, а по запросу. Например если в запрашиваемой строке нету связанных ячеек по вертикали, то можно делать обход только текущей строки, а не всей таблицы, и вот эти промежуточные значения кешировать в матрицу. А вот если есть связь ячеек по вертикали, то тут вот я запнулся, реализовать, то можно, но у меня появились сомнения об оправданности такого подхода. Если есть связь по вертикали, то нужно подниматься построчно вверх, до того момента, пока не попадется строка у которой число (tr[n].cells.length + ?(colspan - 1)) == (tr[0].cells.length + ?(colspan - 1)), где n - номер строки, ? - сумма (мало ли вдруг у кого-то символ не отобразится), либо пока не дойдем до tr[0]. Далее уже из полученного массива строк строить карту ячеек и кешировать. Вроде бы тоже возможны ситуации когда обхода всей таблицы не будет, но не всегда, зависит от структуры таблицы и от того, что на момент запроса уже есть в кеше.

В общем, что-то крутил мутил)

[psywalker]

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

Имхо, а я медведя поддерживаю. Лучше изначально собрать один объект со всеми данными и потом не париться, чем собирать их по ходу пьессы и постоянно. Короче я всегда был ЗА такой же подход, как у Медведя.

[lexxcode]

А я не сказал, что подход плохой. Просто я попробовал найти лучше

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

чем собирать их по ходу пьессы и постоянно

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

[mishka]

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

Я думал об этом. Но решил проверить время построения матрицы.

Я делал табличку 100х100, правда без ровспанов и колспанов и проверял время работы метода createGrid.

Результаты:

ФФ 16.0.1 = 15-17 мс

IE8 не более 100мс

В ие8 конечно долговато, но и табличек таких на сайтах не будет.

Поэтому так вот и решил оставить.

Если есть связь по вертикали ...

Как ты связь эту вычислишь? И как ее вычислишь к конкретной ячейке?

[lexxcode]

Результаты:

ФФ 16.0.1 = 15-17 мс

IE8 не более 100мс

В ие8 конечно долговато, но и табличек таких на сайтах не будет.

Поэтому так вот и решил оставить.

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

Как ты связь эту вычислишь? И как ее вычислишь к конкретной ячейке?

А я вводил понятие физического кол-ва ячеек в строке и виртуального, то есть с учетом colspan. Я изначально получал вирт. кол-во для первой строки и сохранял, назовем ее tLen, это в свою очередь служит отправной точкой.

А дальше сравнивал:

Если (вирт. кол-во текущей строки == tLen), то значит там нет завязок с rowspan со строками выше, а ниже нас не интересуют.

А если (вирт. кол-во текущей строки < tLen), то значит строки находящиеся над текущей связаны по rowspan с текущей.

Ну, а дальше там уже поиск тогда

[psywalker]

А я не сказал, что подход плохой. Просто я попробовал найти лучше

Да нее, это я так, понты кинул по старой памяти) Куда мне ко взрослым лезть-то А ваще интересно, что Сорыч по этому поводу скажет

[lexxcode]

Куда мне ко взрослым лезть-то

не понял о чем ты?

у s0rr0w там по-любому наверное есть какое-то крутецкое решение, на которое мне мозгов не хватило

[psywalker]

Куда мне ко взрослым лезть-то

не понял о чем ты?

О том, что я полез туда, куда мне не следовало) Потому что я жс уже не знаю давно) Просто по старой памяти высказался, а ваще право не имел, потому что лошара)

у s0rr0w там по-любому наверное есть какое-то крутецкое решение, на которое мне мозгов не хватило

Нее, мне не столько решение интересно, как сам подход узнать правильный

[lexxcode]

а ваще право не имел, потому что лошара)

А, что уж мне тогда говорить вообще

[psywalker]

а ваще право не имел, потому что лошара)

А, что уж мне тогда говорить вообще

Нее, вы все молодцы, трудолюбивые) Но тем не менее всё, давай эту тему закроем, ибо уже флудом попахивает))

[mishka]

Да хватит тебе самокритиковаться. Я сам немножко только из танка вылез. Так... люк приоткрыл.

[moron]

А вот мой индусский код http://jsfiddle.net/4whnq/2/ тоже обход всей таблицы и создание матрицы.

Побольше бы таких заданий, где не приходиться шаблонить, а красота кода и мозги придут ко мне со временем

Спасибо.

[psywalker]

А вот мой индусский код http://jsfiddle.net/4whnq/2/ тоже обход всей таблицы и создание матрицы.

Побольше бы таких заданий, где не приходиться шаблонить, а красота кода и мозги придут ко мне со временем

Спасибо.

Вот такие вот штуки не люблю в коде var i4 = i2; (

[mishka]

А вот мой индусский код http://jsfiddle.net/4whnq/2/ тоже обход всей таблицы и создание матрицы.

Побольше бы таких заданий, где не приходиться шаблонить, а красота кода и мозги придут ко мне со временем

Спасибо.

Код, конечно, тяжело читать

http://learn.javascript.ru/coding-style

Но работает!

[moron]

Вот такие вот штуки не люблю в коде var i4 = i2; (

Назвав код индусским я предупредил, что код довольно ужасен i4=i2 было сделано для того, чтобы инкрементировать переменную внутри рекурсивной функции, не трогая при этом i2. that = this - передача ссылки на объект в функцию. Да и по логике там функция не правильно размещена: она внутри цикла, т.е инициализируется несколько раз, что вроде как плохо.

Edited October 21, 2012 by moron

[s0rr0w]

http://jsfiddle.net/tGu2Q/

Буду рад критике.

Мне немного не понятно, зачем нужно было городить огород с конструктором TableGrid. Профита от такого решения нет никакого, а усложнение кода налицо

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

Да нее, это я так, понты кинул по старой памяти) Куда мне ко взрослым лезть-то А ваще интересно, что Сорыч по этому поводу скажет

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

[mishka]

вот еще одно решение: http://forum.htmlbook.ru/index.php?showtopic=40101&view=findpost&p=280031

Конструктор делал чтобы структурировать код. Так же работать легче. Может в будующем добавится метод который будет возвращать все ячейки строки или колонки. Когда все структурированно то легче поддерживать.

[s0rr0w]

Конструктор делал чтобы структурировать код. Так же работать легче. Может в будующем добавится метод который будет возвращать все ячейки строки или колонки. Когда все структурированно то легче поддерживать.

Зачем именно конструктор? Почему не синглтон?

По поводу второго решения.

У меня оно не работает почему-то.

Но я посмотрел код, и, честно говоря, не понял, зачем нужна функция check()

[mishka]

чем тебе не нравится конструктор?

Что будешь делать с несколькими таблицами и синглтоном, причем юзать не один метод getCell, а несколько разных методов?

[s0rr0w]

чем тебе не нравится конструктор?

Что будешь делать с несколькими таблицами и синглтоном, причем юзать не один метод getCell, а несколько разных методов?

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

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