Видимо, хочется понять механику; по теории в подзапросе при where… in в select может быть не более одного поля, если мне память не изменяет, а тут надо одновременно взять полезное поле и поле для сравнения со вторым подзапросом.
Лучшие варианты с применением другого способа — эт тоже очень хорошо.
заполнение пустых мест решается через td отдельного класса с вычисленным значением colspan.
Juniorro — вот тут-то и дело всё. Во-первых, ради дополнительной ноды серверный код должен для каждой записи из таблицы проверять некое условие — накладные расходы накапливаются. Во-вторых, в иксэмэле (полная версия) дополнительные ноды не будут нести функциональную нагрузку, в то время как все остальные имеют обрабатываемые атрибуты или значение. Но, видимо, разделением данных и представления придётся жертвовать, хотя это имеет смысл только для данного случая, а при трансформации в версии для мобильных устройств дополнительные ноды не требуются никак, иксэсэльтэ для такого вывода их обсчитывать не будет.
Картинка, иллюстрирующая вывод.
То есть таки лучше задать дополнительные оборачивающие узлы, чтобы спокойно на обработку каждой такой ноды повесить tr — /tr с гарантией корректности xsl.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Лучшие варианты с применением другого способа — эт тоже очень хорошо.