|
Sheryld
Было бы интересно увидеть результаты эксперимента :) |
результат на лицо http://sybe.dotgeek.org/ время генерации говорит за себя :-)
|
Sych
Время генерации, минимум 0.014, максимум 0.9 Не лучшие показатели :\ На каком сервере стоит система?.... |
Сейчас все работает на забугорном халявном хостинге так что как говорится системка показывает себя в боевых условиях тк на этом же сервере хостится еще около 5000 проектов.
Время генерации варируется в широких пределах в зависимости от загружености машинки и частоты обращения к этому проекту. На локальной машине время генерации 1 мега XML + XSLT преобразование не превышает 0.1-0.3 се,обычные странички генерятся за 0.01-0.05 сек. Хотя я сомневаюсь что в реальных условиях будут файлы такого размера. Система пока сырая - но дает представление о своей работе и потенциале. Кому интересно могут написать в приват - Я дам потестить, для работы надо php5. |
После изучения многих плюсов и минусов, я все-таки взялся писать свой класс шаблонов. Работа в самом разгаре, но простейшие конструкции уже работают. Не хочу говорить о минусах и отрицать другие подходы, но время генерации пока маленьких шаблонов составляет несколько тысячных или десятитысячных секунды. Правда особенно бенчмарков я еще не проводил, вполне возможно что с ростом и обрастанием возможностями этот показатель значительно ухудшится...
Плюс неоспоримым преимуществом является конечно то что я могу реализовать впринципе любую необходимую конструкцию в нем, а не только тем пользоваться что мне предлагают. Предвосхищая крик многих типа "а в подходе ХХХ уже все это есть и предусмотрено" хочу спросить сколькими вообще возможностями из имеющихся там Вы пользуетесь обычно, и сколько процентов из общего числа Вы использовали хоть раз?! :) А время-то на обработку и условия тратится... Да и потом как же быть с тем так и не закрытым вопросом должен ли Дизайнер (верстальщик) учить новый язык, например XML? Какая разница, почему бы ему в таком случае не выучить 20 конструкций PHP? :) Вобщем мне в любом случае оказалось приятнее своя реализация. Как говорится "своя рубашка ближе к телу". Это конечно не аргумент, но это крайне важно, когда нужно решить нестандартные задачи.... |
KTemplate. использую на 100%.
хотя есть и свои наработки. |
Шаблоны - только для больших проектов
Мой личный опыт показывает:
для разных по размерам проектов надо применять разные подходы. я бы разделил примерно так... проект страниц на 10 не больше (есть и такие, например порно сайт) - не стоит мудачиться со всякими шаблонами, пиши, лишь бы работало. проект где-то до 50 страниц (например сайт знакомств или форум): можно использовать подход header-body-booter. тобишь общие части просто загнать в отдельный файл и вставлять его на каждой странице. Коенчно, в этих двух случаях вы не увидете никакого разделения дизайна и кода, и это перекроет возможность кодеру прикрутить дизайн к программе самостоятельно, но даже если программист сам это сделает, выигрышь времени будет на лицо. Использовать шаблоны я бы рекомендовал только в больших проектах (более 50 страниц). Еще один огромный плюс шаблонов: при условии удачного соглашении об именовании переменных, методов и классов и использовании ООП вместе с шаблонами, проект выполненный с использованием шаблонов дает преимущество в поддержке. |
Цитата:
|
Цитата:
|
Я использую php_templates и chtemplate.
Оба движка работают как extension к php, поэтому скорость работы по сравнению с самим пхп (<?=$content?>) практически минимальна (т.е. почти нет вообще). По сравнению с аналогами (smarty, fasttemplate, xtemplate даже при использовании ими кэширования) генерация с помощью этих движком происходит в разы быстрее. В php-templates правда тоже встроен механизм кеширования в вирт. памяти. За то плюсы на лицо: быстрая генерация страницы, полное разделение дизайна от кода. Минусы: то что используется как библиотека, поэтому надо просить хостера чтоб установил. |
Цитата:
Ну со скоростью вроде понятно, есть более быстрые и более медленные решения. Я вообще не люблю стороннних продуктов, поэтому написал вобщем-то свой класс шаблонов, открытым остается самый главный и принципиальный вопрос - разделение и наглядность! Итак, мне все-таки пришломь разбираться со Smarty в одном из проектов (многим известный X-Cart Gold), приведу пример шаблона на смарти: Код:
{section name=cat_num loop=$categories}Итак главный вопрос: Это наглядно для дизайнера, не разбирающегося в программировании вовсе???? Это реализует концепцию разделения кода и содержания? Только не нужно говорить, типа "и не нужно использовать Смарти, вон в ХХХ все наглядно и просто", когда шаблонизатор обрастает возможностями и функциональностью, его синтаксис неизменно усложняется, с этим, надеюсь, никто спорить не будет. Тоесть, при том что я сам написал шаблонизатор для собственного использования, и мне с ним удобнее теперь работать, я никак не могу нормально разобраться во всем этом принципе: как же это все должно быть в идеале.... |
у каждого свой идеал. вместо "навороченных" шаблонов нужно использовать xslt. там это все уже есть и даже больше.
вообще верстку должен делать не дизайнер, а верстальщик, а у него должна быть некоторая подготовка. мне нравиться делать следующим образом: есть шаблон. вся его обработка идет в коде. пример: Код:
<!-- BEGIN list -->1. разделение кода. 2. простота. p.s. мне идеально подошел KTemplate. |
Цитата:
|
я не видел дизайнеров и хороших верстальщиков в одном лице. верстка это чисто технический процесс, без какого-либо творчества.
у тебя есть картинка, макет, описание и т.д. твоя задача выдать тоже самое, но в html. |
Ребята, ребята, не стоит об этом спорить :beer: , неважно кто будет делать верстку дизайнер или верстальщик, вы мне лучше ответьте на другой вопрос, что значит
Цитата:
Вы считаете что он должен в любой момент кидаться изучать как программисту в очередной раз Цитата:
И вот теперь, тут, мы возвращаемся к самому моему первому и принципиальному вопросу, заданному в самом начале этой темы, и как-то оставленном посути в стороне, отвлекаясь на всякие частности, на альтернативы и т.д.: А не проще ли Дизайнеру (пусть верстальщику) выучить десяток-два конструкций на PHP, тех что ему необходимы для верстки??? Это не универсальнее вообще? Тоесть разделение возможно и нужно, но нужно ли его делать "полным" и для этого изобретать велосипеды и новые технологии, кому какие вздумается? |
еще раз и все по-порядку.
1. я уже давно не делаю вставок php кода в html. просто считаю это не правильным подходом. отсюда и идут шаблоны(при всех остальных плюсах). более того, там где это возможно(по срокам) стараюсь всегда делать четкое разделение приложения на уровни(data layer, biz, logic, output, etc). обычно у меня так: 1.база данных. 2.класс, инкапсулирующий всю логику. 3.сборка страницы. 4.шаблон. уровни могут "общаться" только с соседними. если нету времени, 2-ой уровень убирается. 2. xslt это язык программирования. дизайнер его знать не обязан, а хорошему верстальщику - самое оно. 3. ответ на твой вопрос для меня очевиден: не проще и не правильно. |
Цитата:
Цитата:
Цитата:
Цитата:
|
2Hub
1. я совершенно не настаиваю на своем подходе. я же написал - для меня это очевидно, но это не значит, что для всех. у меня есть свои аргументы, некоторые из них я уже выссказывал на этом форуме. 2. я же написал - это именно класс. т.е. после его написания, страница вообще не знает ничего о бд, она только парсит данные(которые вытянул для нее класс и выводит их на экран). пример, рассмотрим простейший класс: Код:
class Item extends AbstractItem //base itemКод:
$item = new Item(); //default constructorв том, что страница "x" ничего не знает ни о бд, ни о запросах, вообще ни о чем, вся ее задача это вывести данные на экран. при подобной архитектуре, приложение становится очень гибким, а код можно реалньо использовать во множестве проектов, т.к. нужно будет менять только вывод(HTML, XML, ETC). если же нету времени, то я переношу логику на 3-ий этап. насчет базы. вообще это личное дело каждого, читал о том, что нету единого подхода к этой проблеме(где должна быть бизнес-логика). сам же ,по возможности, предпочитаю реализовывать ее именно через базу, но т.к. я последнее время сижу на mysql 3.23.5x - там особенно ничего не сделаешь. про дизайнера - я все написал. добавить мне нечего. p.s. в данном случа программист должен будет распарсить шаблон, а верстальщик собвственно их сделать. пример опять же: дизайнер сделал макет, эских или предвариетльную верстку: элемент "список" верстальщик сделал: Код:
<!-- BEGIN list -->Код:
$listTpl = $tpl->fetchblock("list"); |
Sheryld, ты меня конечно извини, и без обид, но все что ты написал к этому топику, и вопросу шаблонов относится очень мало :mad:
Цитата:
Итак, приведенный тобой код того что "верстальщик сделал" так красив просто и понятен только пока .... он так прост! Я же привел пример к чему приводит наращивание возможностей, на примере Смарти. А подобного не избежать никак помоему - полюбому и верстальщику нужно будет все больше возможностей и универсальности... Дак вот где здесь компромисс?? |
Здесь есть ещё неплохая статья на эту тему (но на английском).
http://www.massassi.com/php/articles/template_engines/ |
Цитата:
лови харизму ;) Цитата:
я пока тендирую к пункту 2) но писать свой... |
Только что заметил этот топик. Актуальная и наболевшая темка :yees:
Все вы говорите правильно, но кое-где ошибаетесь. PHP вставки: Недостаткии у вставок PHP кода типа <?=$var?> я вижу такие: 1. Это дыра, т.к. дизайнер или еще кто-то кто не отвечает за PHP код имеет полный доступ ко всем переменным сайта, может неакуратно проверить работает ли exec("rm -rf *.*") и т.д. 2. Ээээ... да и нет больше недостатков в принципе. Вот только что по-идиотски выглядят шаблоны сайта. Верстальщика и правда может шугать, потому-что человека шугает все что он не понимает, такова природа. А верстальщики понимающие PHP долго не живут (ну переквалифицируются в программеров). Темплейты: Темплейты типа FastTemplate, Smarty и пр. решают в принципе первую проблему. Но вторую просто вуалируют, при этом создавая каждый свой новый миниязык, который хоть и несложно понять, но непонятно зачем. Но... Не все темплейты одинаково полезны, некоторые добавляют еще и проблем верстальщикам, т.к. иногда миниязык темплейтов отнюдь не является валидный кодом или частично использует преимущества html, как например использует <!-- комментарии HTML --> для своих целей: Код:
<!-- BEGIN list -->XML/XSL: Вот тут не прозвучало ничего верного. Некоторые считают что XML должен заменить базу данных под MySQL, а кое-кто предлагает записывать данные в БД и в XML параллельно (кой нафиг толк в БД тогда? :)). Но абстрагируйтесь от XML как от формата хранения. Система темплейтов основанная на XML использует (должна использовать) этот самый XML только для отображения, причем промежуточного, данных (не совсем корректно сказать следующее -- но все же для передачи нужных данных в XSL). Как это работает (вернее как должно работать): Вся задача PHP сводится к тому чтобы создать переменную содержащую например следующий текст: Код:
<page>Итак, у нас есть уже XML (в памяти), применяем к нему файл showthread.xsl и отдаем получившийся HTML пользователю. Возникает вопрос зачем генерировать XML (чтобы потом его еще и XSLем обрабатывать) если можно сразу в HTML пропарсить? А затем что у вас в ПХП станет на десяток меньше str_replace'ов (не надо парсить никаких переменных), на пару-тройку меньше preg_match'ей (нет смысла извлекать из темплейтов блоки <!-- BEGIN block1 --> ... <!-- END block1 --> чтобы их продублировать нужное количество раз). Это задача процессора XSLT. И (гипотетически) модуль XSLT будет конвертировать XML в HTML быстрее чем ваш PHP код со всеми str_replace'ами и preg_match'ами вместе взятыми. А кроме того: Плюсы такого подхода: 1. Никакой зависимости от оформления. Т.к.: а) неважно в каком месте XML (в начале или в конце) находится какая-то переменная или блок, XSLT выведет (или не выведет) его в том месте HTML в котором надо. б) Больше никаких "двойных" блоков (или лишней переменной $bgcolor например) если надо сделать таблицу с зеброй. Зебру будет делать XSLT. в) XSLT даже может создать навигацию страниц типа: Страница 2 из 25 (на первую) [1], [2]...[25] (на последнюю). Единственно что нужно это задать в XML что-то типа <thread page="2" lastpage="25"> ну или как угодно, главное чтобы валидно. д) Верстальщик может менять XSL а программер XML одновременно, не боясь получить логических ошибок типа "нужный блок не найден" и т.п. е) а также е) ж) з)... -- PHP код сводится к минимуму, т.к. все (буквально все) задачи связанные с отображением и дизайном переключаются на XSLT ("вставьте мне сюда серое, а тут белое, через одно" - вали к верстальшику, в коде PHP этого быть не должно. "Хочу чтобы каждая первая буква параграфов была картиночкой с прикольной буквочкой" - к верстальщику, "Здесь тоже мининавигацию вставить" - туда же). Задача PHP -- вывести только необходимые _реальные_ данные. 2. Скорость вывода XML + обработка его XSL (не забываем что это практически встроенная функция) теоретически больше чем парсинга переменных и блоков в HTML (не забываем о куче str_replace, preg_match). 3. Верстальщик получает безграничные возможности по оформлению данных, и вообще меньше бегает к программеру если нужно что-то приукрасить, удалить (реже добавить) пару блоков на нужных страницах и т.д. и т.п. все что связано с оформлением больше не беспокоит программера. 4. Никаких дырок и пр. Минусы: 1. (первый и последний). Верстальщику придется знать XSLT (хоть и не шибко сложный, но энивэй) (хотя с другой стороны - если не XSL, так Smarty, который не понятно что за язык и непонятно с каким будущим). 2. (ан нет, не последний). HTML должен соответствовать XHTML, т.е.больше никаких незакрытых тэгов, никаких инвалидных закрытй типа <b><i></b></i> и т.п. Но это даже полезно будет. ЗЫ. Кроме того. Не сегодня так завтра, когда все больше браузеров смогут обрабатывать XML + XSL сами (сегодня это только мозилла последних версий и IE начиная с 6.0) весь парсинг можно вообще перекинуть на сторону клиента -- отадавать сгенерированный XML (включаем в него также ссылку на XSL). Но это все будет только лет через 5, когда старые браузеры наконец исчезнут (блин, когда ж они все исчезнут). |
denver, КРУТО, описано все четко и подробно.
Поэтому так и хочется задать множество вопросов, как профессионалу: 1) В PHP-вставках вида <?=$var?> единственное что ты нашел из недостатков это возможная кривость рук дизайнера и "по-идиотски выглядят шаблоны сайта". Первое может присутствовать в любом подходе и даже допуская именно в этом большую опасность, не хочу брать это в расчет. Второе - конечно ты прав, да и с шаблонными движками наблюдается похожее, НО, согласись, XSL, каким бы не был "встроенным", должен обрабатывать XML парсить его и превращать во что-то другое, соответственно полюбому будет медленнее чем ничего не делать а просто выводить, как в этом случае :) Да и заявления из разных частей поста: Цитата:
Цитата:
Цитата:
И еще, возможно главный вопрос, вот ты говоришь про всякие рюшечки Цитата:
|
С Hubbitus, по поводу приоритетов абсолютно согласен. А вот с предыдущими 2 страницами, совершенно не согласен.
Если брать под ваши требования, тогда скажу так: Вот под perl, есть ведь такой модуль HTML::Template, который хоть и имеет свой псевдоязык, но лихо решает многие проблемы связанные с шаблонизацией. В нём решена проблема с комментариями, путём внедрения в код "песвдо-тегов" (тем кому эта проблема не мешает, можно продолжать пользоваться комментариями). А если с точки зрения управления процессом производства: Я вообще что-то не совсем понимаю, с чего этот топик начался. Есть чёткое разделение труда, отделяющее дизайн от программирования. Не с того конца смотрите, думаю что шаблонизация, это проблема программиста в первую очередь: дизайнер ему выдаёт готовый к работе шаблон, а программист уже в свою очередь уже разбирается, как и зачем его продукт этот шаблон использует. Программисту намного проще разобраться в html коде, чем дизайнеру учить псевдоязык. Насколько я знаю, GUI пишется в последнюю очередь (в нормальных проектах), а вы тут пытаетесь телегу впереди лошади поставить. Написали систему? Давайте дизайнеру спецификацию требуемого шаблона. Получили шаблон - прикрутили к системе. Все довольны. Или я не прав? |
Вы не забывайте, что XML будет посложнее в реализации. То хостер консерватор-придурок не ставит нужные расширения, то любимая программка не понимает UTF-8, то клиент хочет сам редактировать HTML, при этом икая услышав "W3C Recommendation" или "Valid XHTML".
|
Hubbitus
Насчет противоречий двух фраз - не вижу никаких противоречий. Если верстальщик понимает XSLT то XSLT его не шугает :) А то что учить XSL придется я посчитал как раз за минус. Цитата:
str_replace не нужен. т.к. никакого шаблона самого XML не существует. В каждом php файле (ну т.е. для каждого типа страниц) будет свой, таким каким захочет его сделать программер (будем считать что программер тут имеет выбор), в идеале -- таким который отвечал бы логике страницы -- (представь например идеальную страницу топика без любого форматирования и выведи ее). В конце концов выводишь ты не для человека, еще раз напомню -- это промежуточный вывод. Насчет скорости XSLT -- надо тестировать, я не зря говорил о гипотетичной быстроте процессора XSLT, т.к. процессор процессору рознь. Есть слухи что в PHP5 он намного быстрее чем sablotron из PHP4. И дальше скорее всего он тоже будет оптимизироваться. Но не исключено что и в PHP4 скорость парсинга PHP->XML->XSLT->HTML быстрее чем парсинга Smarty->PHP->HTML, только по тому что шаг XML->XSLT->HTML делается одной функцией: echo xslt_process($xml, $xsl). Мне вот подсознательно кажется что одна функция лучше чем много других :) Уравняем шансы договорившись что результирующий HTML будет одинаковый, соответсвенно сложность Smarty кода будет примерно равна сложности XSLT. Однако это очевидо что код Smarty-"процессора" написан на PHP, а код XSLT-процессора на языке более (если не самого) низкого уровня. Надеюсь я понятно аргументировал. Цитата:
1. Отделение PHP кода от HTML кода. либо 2. Отделение бизнес логики от логики отображения. При чем, подчеркну, это не одно и то же. Первый подход это и есть путь FastTemplate, в шаблонах нет PHP кода, однако изменить логику отображения не удастся верстальщику не пнув программера чтобы тот внес изменения туда где в идеале должна быть только бизнес логика -- в коде PHP. Второй подход -- это как раз Smarty и XSLT. В их шаблонах тоже нет PHP кода, однако логика отображения может менятся вне зависимости от программера с его кодом. Конечно координация между верстальщиком и программером нужна всегда, вопрос лишь в том что во втором подходе они не координируют уже те вещи которые относятся (по крайней мере должны относится) только к одному из них. Например не будут таких запросов как "Верстальщик: мне нужно чтобы в переменную $color парсилось #FFF если ячейка четная и #000 если наоборот". Другой вопрос -- что тебе важнее разделять. Быть может с этого и надо было начинать? Иногда (а в идеальном, портируемом коде -- всегда) лучше не засорять PHP переменными содержащими цвета элементов и все такое остальное (субъективное). Вот в таком случае без знаний некого третьего языка -- языка управления отображением не обойтись, будь то Smarty или XSLT. RaZEr Цитата:
Код:
<page>PHP код:
$page->include('posts', $posts); $xml->include('page', $page); или что-то типа того. Т.е. не так уж много кода, а XML тем не менее выдается валидный. Понятно что результирующий HTML очень может даже походить на HTML страницы данного топика (чуть больше элементов добавить), но очевидно что код PHP все равно будет меньше чем если бы он был под FastTemplate (учитывая всю специфику imho.ws топика - вывод зебры, навигации, текущего раздела и т.п.). Цитата:
Цитата:
Цитата:
Если же речь идет о том что клиент (зная HTML или наняв дешевого верстальшика) хочет править шаблоны, то тогда согласен, XSLT не подходит. В любом случае (кроме последнего) все проблемы не являются боьльшими проблемами и решаются сегодня. |
Hubbitus
Да, чуть не забыл Цитата:
Из "актуальных проблем эксплорера" достаточно смирится только с тем что <script> должен иметь закрывающий элемент именно в виде </script> (да, это весьма в духе MS, но ведь не забил никто на CSS хоть и, помимо всех других, существует нехилая такая бага с боксовой моделью в IE5/IE5.5, ведь смирились как-то). |
А вы знаете, y13 высказал очень простую, но вместе с тем (как всегда) грамотную вешь: Дизайнер должен заниматься дизайном, зачем ему вообще учить что-либо, может действительно ему достаточно разработать концепцию, пример, скажем на чистом HTML и с тестовыми данными (кстати я так и получаю почти всевремя), а "прикрутить" дизайн это уже работа программера, и как он это сделает и что удобно использовать должно быть для него (и для других программеров, если есть в проекте)!!!???
Да и RaZEr прав, что касается все-таки сложности реализации... Цитата:
Цитата:
Про парсинг XML в разных версиях PHP и про разные парсеры я не могу особенно говорить - нету опыта. А вот "Но не исключено что и в PHP4 скорость парсинга PHP->XML->XSLT->HTML быстрее чем парсинга Smarty->PHP->HTML, только по тому что шаг XML->XSLT->HTML делается одной функцией: echo xslt_process($xml, $xsl)." более чем странное заявление - Во-первых, не мне Вам как программисту говорить что одна функция это совсем не показатель скорости, и сама она может работать крайне медоенно, и от реализации зависит, и вызывать она может (да и вызывает, я почти уверен) сотни других, и Во-вторых, например Smarty парсит свой шаблон один раз, переводит его в PHP и все, выполняется дальше этот кешь, при последующих запросах, тоесть ВООБЩЕ исключается задержка на нем, шаблон перекомпилируется снова только после изменения исходного... Цитата:
Цитата:
Все остальное сказанное не буду комментировать подробно, не в реализации и конкретных PHP-инструкциях дело, надеюсь сделать все приведенные тобой PHP-примеры сможет любой кто говорит по этой теме, иначе что обсуждать ;) Да и RaZEr, как мне кажется, говорил не о том немножко... Лишь вернусь опять к тому с чего начинали, нужно сформировать на PHP скажем Код:
<posts>Цитата:
|
Hubbitus
Т.к. ты не понял ничего из моего пред. поста не вижу смысла дальше спорить. Если ты хоть что-то понял, но сделал вид что не понял, то тем более неохота убивать клаву. Вот только не делай никаких выводов (если таки не понял) хотя бы чтоб доказать себе что ты свободен от стереотипов. Попробуй сам себе объяснить зачем кто-то там разрабтал Smarty, какую именно проблему он решал, почему много кто юзает Smarty, если уже давно была FastTemplate -- которая меньше и намного быстрее... |
От стереотипов мне кажется я свободен. Спорить? А разве я спорил вообще хоть с кем-то? Чтобы спорить нужно иметь свое мнение о данном вопросе, и если бы оно было у меня вполне определенное, то я бы не создавал этого топика и не спрашивал бы у людей! То что ты возможно принял за спор с моей стороны - это критика того или иного подходов (на самом деле пока получается что всех) и все продолжающиеся поиски идеала, ну или близкого к тому...
Цитата:
|
Hubbitus
Цитата:
Еще раз напомню что их пока всего то и есть 2 рода темплейт систем. |
Цитата:
Цитата:
PS: Это конечно было пару лет назад, сейчас может дописали наконец. Цитата:
|
RaZEr
Ты немного не понял принципа. Валидный XML Код:
<xml><table></tr></xml>Код:
<xsl><h1><value-of select="/xml" /></h1></xsl>Код:
<h1><table></tr></h1> |
Да нет, немного не понял ты :beer: Мы пишем в XML ...
...<hr />... далее XSLT делает нам красивую полоску например (!) так: <hr class="primary" /><hr class="secondary" /> А если клент напишет не <hr /> а <hr> ... будет грустно. Я понимаю что можно всё то, что написал клиент тихо запихать в CDATA, но тогда не сработает не одна из трансформаций, что в случае с CSM неприемлемо. |
RaZEr
Не мы друг друга не понимаем нифига :biggrin: Мы не пишем в xml'е никакого HTML. А если и пишем то не обрабатываем его, а просто выводим (ну типа как через CDATA). А то это уже будет не темплейт систем, а... аналог CSS3 скажем, которое сделать тоже можно, но это оффтоп. HTML выводящийся в XML в данном случае не часть оформления, а контент. Т.е. нет смысла в шаблоне шаблона сайта, этим не занимается и Smarty и т.п. |
Цитата:
|
Цитата:
Цитата:
|
Hubbitus
Цитата:
RaZEr Цитата:
|
Цитата:
|
Ко всем
Да, вот еще по теме. Никогда не следуйте примеру Sych Цитата:
RaZEr Так что ты хочешь сказать, что скажем Smarty наплевать на валидность/инвалидность значит он может заменить ...</p><hr><p>... на ...</p><hr class="primary" /><hr class="secondary" /><p>..., а XSLT не может? Ну если это принципиально то XSLT таки может заменить ...</p><hr><p>... на ...</p><hr class="primary" /><hr class="secondary" /><p>... о чем речь? :confused: О чем речь и нужно ли пытаться делать такие вещи даже в Smarty? Цитата:
|
| Часовой пояс GMT +4, время: 20:31. |
Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.