PHP в деталях



         

XML + XSLT: ещё раз о специализации программных средств - часть 5


3. Не факт, что применение XML+XSLT замедляет отладку. Во-первых, в отличие от смеси HTML+PHP, на программисте не висит, например, вывод нумерованных списков, подсветка строк и множество прочей мелочёвки. По своему опыту могу сказать, что на эту мелочёвку тратится существенная доля времени. Кстати, XML+XSLT позволяет программисту и верстальщику отлаживать свои части проекта параллельно.

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

В-третьих, если XSLT лежит в файле, а XML формируется "на лету", то сделать возможность посмотреть XML-код несложно. Если новая версия сайта делается по адресу test.site.ru, можно сделать виртуальный хост xml-test.site.ru, и пусть php-скрипт смотрит, через какой виртуальный хост его вызывают. Если через "test", то вызывает обработчик XML+XSLT, если "xml-test", тогда выдаёт просто XML.

4. Настройка русского Саблотрона ? это, конечно, шаманство, но не настолько ужасная, как кажется.

5. Кто спорит, что это ресурсоёмко. Наименее ресурсоёмкая для сервера технология ? это Фронтпейдж и заливка готовых html-страниц на сервер. Скпритовые языки, модули Apache (например, mod_rewrite) ? это всё увеличивает ресурсоёмкость, но зато упрощает разработку.

6. Этот пункт вызывает особое удивление. Никто не предлагает заменять скриптовые языки на XSLT.

7. Ну, да, с   там надо возиться отдельно (честно говоря, мне не приходилось, надо смотреть документацию). Но, по-моему, под "структурированными документами" ты имеешь в виду сложно структурированные.

8. Будут новые версии баз, будет и возможность работать с иерархическим документом. Пока что доступных технических средств достаточно, чтобы переводить данные из "линейных" таблиц в древовидные документы.




Содержание  Назад  Вперед