Профит от использования XSLT заключается, как ни странно, в синтаксической равномерности. Тэги всегда с тэгами (окей, это html и xsl, но все же это лучше, чем html и php). Кроме того, в архитектуре работы с XSLT специально проводится довольно отчетливая граница между кодом и интерфейсом (танцы с вызовами php методов из шаблона считаю глубоко некошерными), что положительно сказывается на общей надежности и предсказуемости приложения.
А то, что кому-то синтаксис не нравится — слабый аргумент при обсуждении той или иной технологии.
JSON компактней и нативно обрабатывается JS, который становится все популярней и в клиентских приложениях, и на серверах. При этом он менее функционален по мелочи: нельзя указывать кодировку текста, нельзя указать версию стандарта, нельзя пользоваться атрибутами.
Нет никакой гарантии, что сгенерированный где-то html будет содержать валидную xml-структуру. Мало того, он еще и не обязан быть таковым (meta, link и т.п.).
Поэтому разумно включать непроверенный html в исходное XML-дерево только как CDATA, и, соответственно, выводить в шаблоне через xsl:value-of с disable-output-escaping=«yes».
Доступ к структуре произведенного где-то html в шаблоне уже не нужен, поэтому не вижу выгоды (кроме вреда) в том, чтобы встраивать html в формате xml, а не в виде неструктурированных строк cdata.
При доставке в безналоговый Орегон увеличивается стоимость доставки по миру. В целом, это может оказаться выгоднее, но выигрыш может быть не так заметен.
МакБук с сайта Эппл (куплен через их магазин на айди в домене .com), в айтюнсе айди российский, с .ru, никаких бубнов, все сработало как надо, за исключением неработающих кодов (многие жаловались), которые эппл исправил и прислал повторно.
https с валидными сертификатами. центры авторизации сертификатов имеют свою подпись, которая «зашита» в браузер и подделать ее нельзя. если центр подтверждает валидность https-сайта, значит mitm нет. что не означает, конечно, что пользователь не лопух и не пропустил каких-то очевидных признаков взлома типа замены https на http или предложения принять как доверенный какой-то новый левый сертификат.
Применять смысл есть, так как алгоритм эффективно защищает Элис и Боба от Евы, хотя понятно, что без третьей стороны (https) не защитит от Мэллори. (http://en.wikipedia.org/wiki/Alice_and_Bob)
filter_* по-моему полезен не столько для проверки входных параметров на соответствие определенному RFC или узкому типу данных, сколько для отрезания html-тэгов (с потенциальным XSS) в тривиальном тексте. То есть, это такой шаг в сторону мысли «фильтровать данные из браузера — это хороший тон и все такое», а вовсе не про регулярные выражения. Хотя даже тут могут быть проблемы, конечно.
Если речь идет о фреймворках, которые позволяют вызывать методы кода в зависимости от браузерного запроса, то как раз там важно, чтобы аргументы методов фильтровались самим фреймворком, а разработчик был вынужден указывать по какому типу фильтра, что какбе намекнет ему, что без фильтров теперь не принято.
А то, что кому-то синтаксис не нравится — слабый аргумент при обсуждении той или иной технологии.
Поэтому разумно включать непроверенный html в исходное XML-дерево только как CDATA, и, соответственно, выводить в шаблоне через xsl:value-of с disable-output-escaping=«yes».
Доступ к структуре произведенного где-то html в шаблоне уже не нужен, поэтому не вижу выгоды (кроме вреда) в том, чтобы встраивать html в формате xml, а не в виде неструктурированных строк cdata.
Если речь идет о фреймворках, которые позволяют вызывать методы кода в зависимости от браузерного запроса, то как раз там важно, чтобы аргументы методов фильтровались самим фреймворком, а разработчик был вынужден указывать по какому типу фильтра, что какбе намекнет ему, что без фильтров теперь не принято.