@Grundy чтобы скрипт знал, на какие блоки новый класс вешать. Как вариант, можно пройтись JS-циклом по общему родителю, конечно, но я же структуры HTML-кода у ТСа не знаю.

@Grundy ТС и вешает, А потом у него БД квакнется, когда десять человек одновременно эту страницу откроют. Или Рельсы научились рерайтить шаблоны?

@MaximCherevatov значит где-то синтаксическая ошибка, например - вы не стёрли из кода мои комментарии) Потому как блок if-else не может выдать оба варианта.

@MaximCherevatov значит, вы выводите блок где-то вне ifа.

@D-side а мой код синтаксически верен? А то я давно под Рельсы не писал, мог и накосячить.

Откуда N*M запросов, кстати? Я там вижу всего один. И локальная session не используется нигде. Синтаксически вроде правильно.

@D-side чёрт, туплю. Запрос один, интераций N*M. Но всё едино, лучше так не делать, время генерации страницы это точно не уменьшит. Тем более, что её даже закешировать нельзя, пока она в таком виде. Ща ответ подправлю.

@D-side так лучше? Неиспользуемую переменную видел, но чёрт её знает, зачем она ТСу.

Так если он хочет такую таблицу, там меньше N*M всё равно не сделать просто из-за объёма вывода, одна итерация на единицу вывода уже ок. А кэш?.. Норм, можно, главное грохать кэш, когда данные под таблицей изменяются.

@D-side А вот тут вы не правы: Объём вывода там N (число мест в зале). При этом, вывод можно кешировать, ибо места бегать не умеют.

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

Итого, получаем N+M, для новой страницы и M для кешированной.

Смотрите

Создаём во вьюхе сто "мест" - 100 интераций.

Запрашиваем список броней (например, их 20)

Формируем массив с номерами броней - 20 интераций

Отправляем его клиенту

Дальше, JS, на стороне клиента, раскрашивает нужные места, пробегаясь по массиву (фактически, ещё 20 интераций, но серверная часть и Рельсы к этому уже отношения не имеют).

Итого: 120(+20) интераций, вместо 2000.

А после кеширования первый пункт заменяется загрузкой из кеша.

С кэшем да, может быть меньше.

что-то я не пойму как вы 2000 насчитали, там же один проход всего? и проверка поля (забронировано или нет) и максимальное количество итерация равно максимальному числу мест

я где-то ошибаюсь?

@Grundy Не-а, там так выходит: создаются места (100 интераций) и внутри каждой интерации идёт сверка со списком броней (20 интераций). Итого: 100*20 = 2000

@Risto значит плохая организация сервера:)

@D-side Да, можно. @Grundy тоже об этом говорил, но я не врубился. Но тогда придётся забить на кеш и автообновление броней на странице.

Можно помнить "на каком номере остановились" и в каждой итерации по броням добавлять недостающие пустые места, а после них добавлять текущее.

Ну и не забыть свободные места в конце.

@Risto автообновление тут никаким боком. можно так же только при первой загрузке получать страницу а потом скриптом обновлять

Кэш при этом не особо и нужен, а если уж делать автообновление, то во всей этой затее нет смысла и надо сразу делать JS-rich-решение.

Хотя! Серверный рендер ускорит начальный показ.

@D-side об чем и речь

@D-side Да просто поменять циклы местами. Ставить пустые места во внутреннем, пока не наткнёмся на занятое. тогда ставить занятое и запускать следующую интерацию внешнего цикла (получать следующее занятое) и запускать внутренний от занятое+1.

@D-side Ну и да.

Короче, разобрались) Но правильную реализацию я за ТСа писать не буду, лень. @D-side Может вы?

@Risto мне тоже лень %)

@Risto, @D-side, вот так вот :-) собрались тут ленивые помогаторы :-D

@Grundy может, вы? %)

@Grundy можно просто правильную логику описать, благо часть вопроса про это.

@D-side :-D не, я с руби вообще никак :)

:-D ну и мне тоже лень

@Grundy @D-side а не посносить ли нам лишние комментарии, как просит Мета? Ссылку на чат оставить, естественно.

@Risto можно повесить это на модераторов. им все равно делать нечего:)

@Grundy злой вы, и шутки у вас дурацкие... хнык