-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Развертывание данных в ввиде таблицы
- Автор темы Фанат
- Дата начала
Максим Деркачев
Guest
Попробую разложить все по полочкам.
XSLT - это язык преобразований, причем - преобразований их XML. Соответственно, он нам нужен только тогда, когда нам надо преобразовывать XML. Где мы его взяли? Тут могут быть варианты.
1. Мы получаем XML из внешнего источника. Например, RSS или какой другой XML с другого сайта. Хотим все это выдать в нашем дизайне. Полезен тут XSLT? Несомненно. Хотя его применение может быть затруднено из-за недостатка знания этого языка, но если этот недостаток опустить, то имеем схему XML->XSLT(пусть с прослойкой PHP, но только для вызова процессора)->HTML. Если это делать средствами PHP SAX/DOM, то схема будет такая: XML->PHP-разбор->PHP-вывод (шаблон или еще как)->HTML. Т.е. в этом случае лишнее звено разбора XML, которое интегрировано в XSLT-процессор.
2. Мы рожаем XML сами из источника, который мы полностью контролируем - база или еще чего там. Вот тут опять же варианты: зачем?
a. Потому что это прикольно. Вот тут уважаемый Раздолбай прав, и говорит он, собственно, в-основном про этот вариант. Получается N-ное количество лишних звеньев, а выхлоп непонятен. Нарисовать табличку из базы или других данных, которые более удобны для действий с ними (XML - это стандарт обмена данными, достаточно универсальный и из-за этого не являющийся очень уж удобным для доступа к этим данным, что бы тут ни говорили про DOM, Xpath и т.п.) гораздо проще и экономически более оправдано.
b. Потому что нам все равно надо отдавать данные куда-то налево, и раз мы уж этим занялись, то можно и унифицировать интерфейсы на базе XML, а XSLT позволит разделить доступ к данным и презентационную логику. Выигрыш такого подхода будет в том, что мы сможем сделать сайт таким же внешним сервисом, как в случае 1, не зависящим от расположения наших "сырых" данных. Но опять же, если это нам действительно надо и мы готовы пожертвовать какой-то долей производительности системы. Критериев может быть масса, и тут нужно смотреть конкретные случаи.
с. Мы делаем систему не для себя (коробочный продукт, например). Это можно рассматривать как вариант пункта b. Тут, конечно, XML и XSLT будут весьма полезны, именно из-за стандартности. Мы не можем предсказать все варианты применения нашей системы, и нам желательно, чтобы она более-менее легко могла быть встроена в чужое окружение, как программное, так и людское (если, конечно, мы не закрываем наши интерфейсы намеренно, чтобы за любой чих нам платили деньги).
XSLT - это язык преобразований, причем - преобразований их XML. Соответственно, он нам нужен только тогда, когда нам надо преобразовывать XML. Где мы его взяли? Тут могут быть варианты.
1. Мы получаем XML из внешнего источника. Например, RSS или какой другой XML с другого сайта. Хотим все это выдать в нашем дизайне. Полезен тут XSLT? Несомненно. Хотя его применение может быть затруднено из-за недостатка знания этого языка, но если этот недостаток опустить, то имеем схему XML->XSLT(пусть с прослойкой PHP, но только для вызова процессора)->HTML. Если это делать средствами PHP SAX/DOM, то схема будет такая: XML->PHP-разбор->PHP-вывод (шаблон или еще как)->HTML. Т.е. в этом случае лишнее звено разбора XML, которое интегрировано в XSLT-процессор.
2. Мы рожаем XML сами из источника, который мы полностью контролируем - база или еще чего там. Вот тут опять же варианты: зачем?
a. Потому что это прикольно. Вот тут уважаемый Раздолбай прав, и говорит он, собственно, в-основном про этот вариант. Получается N-ное количество лишних звеньев, а выхлоп непонятен. Нарисовать табличку из базы или других данных, которые более удобны для действий с ними (XML - это стандарт обмена данными, достаточно универсальный и из-за этого не являющийся очень уж удобным для доступа к этим данным, что бы тут ни говорили про DOM, Xpath и т.п.) гораздо проще и экономически более оправдано.
b. Потому что нам все равно надо отдавать данные куда-то налево, и раз мы уж этим занялись, то можно и унифицировать интерфейсы на базе XML, а XSLT позволит разделить доступ к данным и презентационную логику. Выигрыш такого подхода будет в том, что мы сможем сделать сайт таким же внешним сервисом, как в случае 1, не зависящим от расположения наших "сырых" данных. Но опять же, если это нам действительно надо и мы готовы пожертвовать какой-то долей производительности системы. Критериев может быть масса, и тут нужно смотреть конкретные случаи.
с. Мы делаем систему не для себя (коробочный продукт, например). Это можно рассматривать как вариант пункта b. Тут, конечно, XML и XSLT будут весьма полезны, именно из-за стандартности. Мы не можем предсказать все варианты применения нашей системы, и нам желательно, чтобы она более-менее легко могла быть встроена в чужое окружение, как программное, так и людское (если, конечно, мы не закрываем наши интерфейсы намеренно, чтобы за любой чих нам платили деньги).