судя по коментам, ещё один подросток с завышенным ЧСВ ну, такое у всех было, с возрастом это проходит =)
tenshi ну я в гугл за всякой хренью не хожу... а тебе еще раз скажу, делай как хочешь, чё мне то доказывать, зря время тратить...
Сделал для себя вывод - XSLT лучше не использовать в связке с PHP. Хотя бы потому, что потом никому показать нельзя будет - все сразу же бросятся делать из тебя отбивную за нерациональное решение, что на пыхе, что на хабре > А вообще, Psih очень хорошо все объяснил, респект.
и это говорит человек, который шаблоны хранит в базе х) вот ты можешь перенести шаблонизацию на клиента тем самым разгрузив сервер и гоняя между клиентом и сервером меньше данных? ты можешь сделать так, чтобы обычный и аяксовый запросы обрабатывались совершенно одикаково и чтобы не требовалось дублировать ручки? ты можешь позволить себе шаблонизировать пользотальский контент (например, вставить после каждого заголовка пермалинк на него) при выводе?
tenshi *чешет затылок* Я с дуба упал, что ли? В шаблонах полно такого, чего ни при каких условиях нельзя отдавать клиенту - детали реализации, комментарии разработчиков, PHP-вставки, наконец (для pull-шаблонов). То же самое и с данными, которые в эти шаблоны уходят, например, список зарегенных участников я выбираю запросом типа [sql]SELECT * FROM users WHERE ...[/sql] Клиенту с готовым HTML уходит только часть полей - имя пользователя, группа, дата регистрации итд, но из базы записи выбираются целиком, в том числе пароль, email, IP итд... вы предлагаете мне все это тоже отдавать клиенту и уповать на его порядочность? Если все это отдавать клиенту на растерзание - то тогда уж проще отдать ему все исходники сайта и дамп базы - пусть сам у себя ставит Апач, поднимает сайт и пользуется им, тогда нагрузка на мой сервер будет вообще нулевой. Как я понимаю, XSLT стремится именно к этому идеалу. У меня несколько иное отношение к шаблонам, нежели у вас - чтобы они были удобными, они должны быть мощными, а не быть просто "мутаторами" для переделки одного XML в другой XML. А мощные шаблоны надо держать на сервере и никому не показывать, иначе их мощь против вас же и использует кто-нибудь. Ну не знаю, по-моему, кардинальной разницы между этими двумя типами запросов нет. Не обязательно применять XSLT, чтобы успешно решить такую задачу. Обработка пользовательского контента в общем случае - нечто более сложное, чем замена одного HTML-тега другим, пусть даже и на лету. Например, типичная задача - это распарсить и заменить "безопасные" BB-теги в тексте "опасными" HTML-ными. Не уверен, справится ли здесь XSLT.
бесспорно, это всё круто. Но это делается при нестандартном окружении, но PHP должен тут выполнять не ту роль которую ты ему даёшь. В конце концов, многое можно сделать и PHP средствами...
чего там быть не должно. особенно пхп-вставок. коменты можно вырезать при минификации и слиянии в один файл, как это происходит с яваскриптом и цсс. ты полагаешься на то, что шаблонами будет заниматься программист? за частую же ими занимаются люди с менее высокой квалификацией и вообще люди со стороны. ради пары полей запрашиваешь вообще все данные только для того, чтобы решение получать или не получать какие-то данные вынести из контроллера в шаблон? шило на мыло.. нет. потому что всем кроме тебя от них становится дурно х) редактировать шаблоны через веб-интерфейс без подсветки синтаксиса - на это мало кто решится. как ты будешь её решать? Код (Text): Например, типичная задача - это распарсить и заменить "безопасные" BB-теги в тексте "опасными" HTML-ными. Не уверен, справится ли здесь XSLT. [ url=javascript:alert('hello world') ]click me[ /url ] это безопасный тэг? <b>hello world</b> а это опасный? bb - всего-лишь другой синтаксис для html. не самый удачный. почему его используют вместо маркдауна - ума не приложу. ну да ладно, после того как ты распарсишь свой язык, какой бы он ни был, в дерево - его можно скормить в xslt и быть уверенным, что весь текст будет заэкранирован, а результат валидным.
по сабжу - в libxml обнаружился серьёзный баг - вместо прописывания пространств имён в корневом тэге он старается прописывать их в максимально вложенном - это приводит к фейлу при матчинге шаблонов полученных из xs. =(
tenshi В тепличных приложениях - возможно, но в реальных, увы, все не так просто... Простейший пример задачи, при которой без pull- технологии не обойтись - это генерирование (и кеширование) превьюшек к изображениям на лету. Добавлять такую ерунду в бизнес-логику неверно, а в шаблонах все просто и понятно - тег <thumbnail image="..." width="..." height="..."> и все работает как надо Разумеется, для этого шаблонная подсистема должна уметь работать, а не просто перегонять XML в XML. То есть вы предлагаете все шаблоны обрабатывать дважды - сначала на стороне сервера, а потом еще и на стороне клиента. Извините, а что в шаблонах забыли люди "со стороны"? Для безруких заказчиков и блондинок-операторш есть визуальные редакторы типа FCK или TinyMCE. Но допускать их, по сути, к программному коду? Ведь шаблоны - это тот же программный код, просто в ином представлении, более близком к конечному отображению (HTML). Поэтому заниматься ими должен человек знающий. Разумеется. А вы что предлагаете? Выбирать только то, что нужно для данного конкретного отображения, тем самым насмерть связывая логику и представление? Представьте, у вас чуть изменился дизайн и вам нужно вывести в списке пользователей еще одно поле - например, дату рождения. Мне достаточно лишь поправить шаблон. А вам придется и шаблон править, и вносить изменения в бизнес-логику (добавлять еще одно поле к выборке данных из базы), что гораздо, гораздо кривее. То есть вся загвоздка в отсутствии подсветки синтаксиса? Без нее работа не идет? Смотря какая задача, смотря что за AJAX запрос и что он должен возвращать. На сервере точно никакой разницы нет, что за запрос пришел. А на стороне клиента - уже зависит от ситуации. Аджакс может возвращать простую строку (результат превалидации), может возвращать структуру (дернутые данные) либо целый фрагмент HTML. Все случаи жизни увязывать в один общий обработчик, имхо, неверно. Абсолютно безопасный. Это же еще не HTML, а просто скобочки Нет, но в HTML встречаются не только <b>. Бывают <script>, бывают <iframe>... Вы ж не будете все тупо сливать клиенту, верно? Нужна какая-то защита? Вот мне и интересно, как XSLT обеспечивает такую защиту, если в "пользовательском контенте" посетитель сайта напишет всякую ерунду. Аминь. Еще бы примеров
приходит менеджер и говорит: "хочу слайдер для изменения размеров превьюшек, как на яндекс.фотках". что будешь делать? Код (Text): То есть вы предлагаете все шаблоны обрабатывать дважды - сначала на стороне сервера, а потом еще и на стороне клиента. ;) что значит обрабатывать? Код (Text): Ведь шаблоны - это тот же программный код, просто в ином представлении, более близком к конечному отображению (HTML). если бы они ещё не маячили в админке.. или у тебя клиенты не имеют доступ к шаблонам? нет, мне шаблон править не придётся. я добавлю получение нужного поля и шаблон для даты, если его ещё нет. а "вывод даты рождения" - это и есть бизнесс-логика. большая часть бизнесс-логики любого веб-приложения заключается в том, чтобы основываясь на параметрах запроса вывести соответствующие ему данные. да. попробуй поработать стоя перед столом на коленях. задача - выдать хтмл без шапки, футера, и прочих причендал, которые и так уже есть на странице. это какая-то дискриминация скобочек? специальными шаблонами можно заменять все опасные конструкции на что душе угодно
tenshi К счастью, я работаю на себя, и никакие менеджеры мной не командуют но если возникнет необходимость сделать на сайте слайдер - сделаю слайдер. На PHP и со своими шаблонами. Или слайдеры - это проприетарная собственность XSLT технологии и без нее ничего не получается? Я привел вам реальный рабочий пример того, как в шаблонах необходима pull-технология. Вы его проигнорировали и вместо этого придумали свой собственный другой пример. Это не разговор. В реальной жизни вы тоже отмахиваетесь от всего, что не покрывают возможности XSLT и делаете вид, что таких задач вовсе нет? Обрабатывать - значит, обрабатывать. Вы выше писали, что XML "парсится только однажды". Я говорю, что если XML надо обрабатывать как минимум дважды - на стороне сервера перед его отправкой клиенту и на стороне клиента, перед сборкой конечного HTML - то ваше утверждение об однократном парсинге и связанной с этим экономии неверно. Разумеется. Админка с полным доступом ко всем модулям - это доступ для разработчика (программиста). Клиент имеет доступ только к тому, что ему нужно для работы с сайтом. Перелопачивание дизайна с бодуна в этот список не входит. Нет, вывод одного лишнего поля - это не бизнес-логика. Ведь от появления одного поля на экране логика работы приложения никак не изменяется. Хорошо, допустим, что по каждой мелочи вам приходится снова и снова лезть в программный код (править выборку из базы), но зато - "шаблон править не придётся". Вопрос: если вы не трогаете шаблон, в каком месте шаблона будет выведено новое поле? Где оно появится на экране? В чем проблема-то? В базовый шаблон проекта добавляется пара условий типа <if not ajax>...</if>. Либо контент рендерится другим базовым шаблоном, облегченного формата. Либо, в случае PHPC, есть более элегантное решение - создается новый стиль, "ajax", который наследуется от основного стиля, и в нем модифицируется один-единственный шаблон htmlDesign - вместо вывода хедера, контента и футера в нем просто выводится контент. И все. Стиль будет выбираться автоматически, в зависимости от того, какой запрос пришел - обычный или ajax. Как раз для таких ситуаций я в движок поддержку стилей и добавлял. Вот оно - прозвучали магические слова "специальные шаблоны". Теперь скажите мне, будут ли эти "специальные шаблоны" работать на стороне клиента, особенно если набор BB-правил хранится на сервере, в таблице.
ну клиенты, один фиг это был пример, когда идея с прописыванием размеров превьюшек в шаблоне приводит к геморрою. это плохой архитектурный паттерн. генерация картинок при запросе страницы приводит к долгому её формированию. прописывание конкретных размеров во всех местах использования превьюшек не даёт централизованно менять их размер. поощряет использовать разные размеры на каждый чих. захламляет диск ставшими ненужными размерами, ибо выяснить какие из них нужны не представляется возможным. и тд и тп Код (Text): Вы выше писали, что XML "парсится только однажды". в каком контексте я это писал? ясно х) специально делаешь систему которой никто кроме тебя не сможет пользоваться? меняется. раньше она на запрос отдавала одни данные, теперь другие. это решает вьюха я уже не помню к чему я это вёл ._. в общем, суть в том, что xslt шаблоны для обоих случаев используются одинаковые. при чём тут бб-правила? нафи нужен бб, если можно использовать напрямую хтмл? а бб, если очень надо, можно привести к хтмл простейшими регулярками.
Я извиняюсь, что за бред? При чем тут "кроме меня" и "клиент"? Клиенту, всяким его манагерам, ни в коем случае не нужно давать доступ к коду. Только через админку, и то с ограниченными правами. Ты как будто никогда не сдавал сайты клиентам; как будто не знаешь, что может сделать укуренный менеджер по приказу не менее укуренного начальника. А если клиенту нужно будет доработать, то его программист разберется прекрасно и без шаблонов в админке. Нет, дискриминация html \ js в сторону bbcode как потенциальной уязвимости сайта.
tenshi Гугл в своих "картинках" прописывает фиксированные размеры для превьюшек - что он делает неправильно? Это плохой архитектурный паттерн? Он генерирует превьюшки на своей стороне и отправляет их потом клиенту (как часть контента, через data:image/jpg, либо как ссылку на сформированный файл) - где здесь, по-вашему, геморрой? Разговоры о "плохом паттерне" абсолютно безосновательны. У вас есть задание. Вы ему следуете. Если в задании написано "делаются превьюшки такого-то размера" - делаются превьюшки такого-то размера. Если в задании написано "используется слайдер" - используется слайдер. Если в задании окажется, что делать надо файлы-превьюшки, то вы со своим XSLT сядете в лужу, ибо ни одного внятного способа решить эту задачу вы так и не предложили, вместо этого вы придумывали решения других задач. Причем, практически все решения звучали как "это надо свалить на клиента, пусть сам все у себя делает". Пожалейте клиента, он на ваш сайт не вкалывать пришел Вы слышали про такую вещь, как кеширование? Ну так не прописывайте во всех местах. Подразумевалось, что значениями параметров width и height в шаблоне <thumbnail> выше могут быть не только константы. Это ужасно, да. На одном проекте сейчас порядка 2000 изображений общим объемом около 1,5 Гб. Каталог, в котором хранятся все превьюшки, во всех размерах, занимает около 60 Мб. Это составляет 0,04 от объема исходных файлов. О, какое жуткое захламление
будет выть крокодильими слезами %-) Код (Text): Нет, дискриминация html \ js в сторону bbcode как потенциальной уязвимости сайта. имя пользователя "drop table" запрещено настройками безопасности, выберите пожалуйста себе другое имя
в шаблонах? х) а если задание поменялось? будешь перелопачивать все шаблоны и чистить стораджи? сделали редизайн - поменяли размеры превьюшек - выкатили на продакшен - пользователи ломанулись создавать превьюшки - сайт упал. пользователь загрузил несколько сотен фоток - толпа юзеров смотрит ленту последних загруженных фоток - весь сайт начинает жутко тормозить и в особенности лента. таких весёлых сценариев можно придумать гору. а переменные? и где задаётся их значение? маленькие проекты на больших серверах, конечно расслабляют..