- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
<?php foreach ($this->adverts as $advert): ?>
<div class="advert_cover">
<h3 class="advert_header">
<div class="advert_date">Дата размещения: <?=$advert->getCreateDate()->format('d.m.Y H:i:s')?></div>
<?=$advert->getHeader()?>
</h3>
<div class="advert_content">
<div class="advert_text">
<?php
$advert_text = Helper_Format::getPreviewStr($advert->getText(), 300, '...');
echo $this->getHelper('Helper_Format')->run(strip_tags($advert_text), 'nl2br', 'bb2html');
?>
</div>
<ul class="my-adverts--ul-advert-manager">
<li class="edit_link"><a class="space_nowrap" title="Редактировать объявление" href="/my/adverts/edit/<?=$advert->getId()?>.xhtml">Редактировать</a></li>
<li class="zoom_link"><a class="space_nowrap" title="Посмотреть, как объявление выглядит на сайте" href="/advert/<?=$advert->getId()?>.xhtml">Посмотреть</a></li>
<?php if ($advert->getExpireRestrictionUpdateCreateDate()->invert): ?>
<li class="up_link"><a title="Поднять объявление в результатах поиска. Данная функция гарантирует, что Ваше объявление увидят больше посетителей сайта <?=$_SERVER['HTTP_HOST']?>. Применять данную опцию можно не чаще чем через один час." href="/my/adverts/up/<?=$advert->getId()?>.xhtml">Поднять в результатах поиска</a>
<?php else: ?>
<li class="up_link"><span class="cursor_help space_nowrap" title="Для этого объявления данная функция будет доступна через <?=$advert->getExpireRestrictionUpdateCreateDate()->i?> мин.">Поднять в результатах поиска</span>
<?php endif;?>
</li>
<?php if ($advert->getActive()): ?>
<li class="lock_link"><a class="space_nowrap" title="Приостановить показ объявления на сайте (закрыть доступ для всех)" href="/my/adverts/active/<?=$advert->getId()?>.xhtml">Приостановить показ
<?php else: ?>
<li class="lock-open_link"><a class="space_nowrap" title="Возобновить показ объявления на сайте (открыть доступ для всех)" href="/my/adverts/active/<?=$advert->getId()?>.xhtml">Возобновить показ
<?php endif;?>
</a></li>
<li class="delete_link"><a class="space_nowrap" title="Безвозвратно удалить объявление" onclick="return confirm('Вы действительно хотите удалить объявление «<?=$this->getHelper('Helper_Format')->run($advert->getHeader(), 'entDec', 'confirm')?>»?')" href="/my/adverts/delete/<?=$advert->getId()?>.xhtml">Удалить объявление</a></li>
</ul>
<div class="div-clear"></div>
</div>
</div>
<?php endforeach; ?>
Follow us!
PHP это не язык, а шаблонизатор. Потому шаблоны на PHP все же лучше, чем шаблоны на смарти.
Правда в этом коде кроется еще зашитая локализация и зашитые пути, а это говно по определению.
Вообще на свете существует только один хороший шаблонизатор: XSLT. Но им никто не умеет пользоваться, и потому никто (кроме меня) не любит:)
и не сри на PHP
Если уметь ей пользоваться и правильно реализовать кеширование -- то все будет отлично работать.
Вон, яндекс живет себе и в ус не дует.
Другой вопрос что для XSL требуются специалисты, а для PHP подойдут и обезъяны. А специалисты обычно сильно дороже обезъян, и в этом XSL конечно сильно проигрывает PHP.
>>и не сри на PHP
К счастью, я давно уже увлекся программированием, и PHP заниматься перестал))))
XML - ебанная хрень,ибо никакой наиудобнейший API не оправдывает такие требования к памяти и времени на разбор,я уж не говорю что внешний вид XML похож на жопу и идею "быть простым для редактирования" он явно провалил
XSLT - всё туда же , KISS был послан в жопу в результате даже простейший цикл записывается как нечто на 4 строки
помимо этого ему ещё и XML документ на вход нужен,а это уже полные тормоза
>>К счастью, я давно уже увлекся программированием, и PHP заниматься перестал))))
рад за вас,не секрет на какой же такой язык для риальных программистов вы пересели?
ASP ?
>>Если уметь ей пользоваться и правильно реализовать кеширование -- то все будет отлично работать.
невероятно! но это же относится и к PHP ,однако генерация новых страниц будет быстрее
Вы, видимо, не в теме. Для работы XSL совершенно не нужен DOM, а значит и требования к памяти не такие у ж большие.
>>ASP ?
Вы снова не в теме. ASP это не язык:)))
>>невероятно! но это же относится и к PHP ,однако генерация новых страниц будет быстрее
Совершенно верно. А если выодить HTML через echo -- то генерация будет еще быстрее!
Это вы не в теме
>>Вы, видимо, не в теме. Для работы XSL совершенно не нужен DOM, а значит и требования к памяти не такие у ж большие.
окь,XSL требует SAX , а документ на вход вы будете генерить...
видимо таки echo й,чисто для скорости
>>Вы снова не в теме. ASP это не язык:)))
какой ужас, ASP.NET назвали ASP
а мне то какое дело на чём из этого вы пишете,может вы VBScript в страницы пихаете?
В чем именно? echo "ы"; действительно быстрее "?> ы <? php".
Это важно, мы же боремся за производительность, для нас же XSLT тормознутое, даже с кешированием)
>>окь,XSL требует SAX ,
XSL требует доступа к документу по XPath. Этот интерфейс может предоставлять все, что угодно.
>>а документ на вход вы будете генерить...
>>видимо таки echo й,чисто для скорости
що? Я Вас не понял.
>>какой ужас, ASP.NET назвали ASP
И ASP.NET это не язык. и ASP не язык. Почитайте википедию что ли)
FAIL
>>И ASP.NET это не язык. и ASP не язык. Почитайте википедию что ли)
и какой мне хрен на каком диалекте .NET вы пишете?
я знаю что .NET это только платформа и писать вы под неё можете на том же C# , только кто сказал что на .NET пишут? вообще то в нём кнопки нажимают чтобы ИДЕ что нужно подставила
>>що? Я Вас не понял.
есть у вас допустим 20 инстансов класса описывающего ну допустим логи,вы их через XSLT как протаскивать собираетесь,не конвертируя в XML?
)) Что такое "диалект .net", причем тут ASP, и где я сказал что я на нем пишу?
Вы что, Вебкилл?
Поясняю:
"asp" это запуск на серверной стороне microsoft scripting плюс объекты для работы с http и пр. Пишут там на сркпитах, например на js или vbs, можно и на php, если он есть для scripting.
ASP.NET это фреймвор внутри .NET для написания веб-приложений. Пишут под него на чем угодно: C#, VB.NET, да хоть IronPython.
Я вообще джавист)
>> вообще то в нём кнопки нажимают чтобы ИДЕ что нужно подставила
Можно и нажимать, а можно и вполне себе писать.
Там есть и полные ламеры, а есть и вполне внятные люди, знающие что такое красивый код. В отличии от мира PHP, кстати:)
>>есть у вас допустим 20 инстансов класса описывающего ну допустим логи,вы их через XSLT как протаскивать собираетесь,не конвертируя в XML?
Ну вот например в .NET я бы реализовал интерфейс IXPathNavigable, а хранил бы логи как мне удобно (хоть массивом байт), и выводил бы их через XSL трансформацию.
с# - тоже совсем язык.
zend - совсем не язык.
ASP & ASP.NET - опять совсем не язык.
ферштейн?
тонко =)
Смысл в том, что на том же смарти примитивные шаблоны я напишу в 1000% быстрее и не буду пугать излишней сложностью верстальщиков там, где это ненужно просто. А вам знакомо sass, haml?
1) тестирование аутпута автоматическими средствами
2) разработка верстки отдельно от приложения (без поднятия оного)
3) Какие из этих функций поддерживаются в смарти: http://www.w3schools.com/Xpath/xpath_functions.asp
4) "не буду пугать излишней сложностью верстальщиков"
Ваши верстальщики далеки от техники?:)
>>А вам знакомо sass, haml?
Да. Я считаю запись HTMLя в формах, отличных от HTMLя -- крайне плохим подходом.
2) Странный аргумент, как можно сверстать не зная как это будет в дальнейшем использоваться
3) Зачем мне все эти функции?
4) Наши верстальщики умные люди, и не пихают во всё что можно XSLT, потому что знают, что оно нужно только там, где себя оправдает.
Вы считаете это плохо, потому что так считаете? Ну вот и прояснили
>> полученный html после смЕрти
Конечно может быть. Только тестирующую утилиту надо будет менять каждый раз, когда верстальшик с дизайнером слегка изменят внешний вид.
>>2) Странный аргумент, как можно сверстать не зная как это будет в дальнейшем использоваться
Причем тут "не знать"?
Знаете, бывают на свете крупные приложения, которые накладно и тяжело разворачивать у верстальщика на машине. Мир состоит не только из магазинов на php.
В это случае (повторяюсь) программист и верстальщик договариваются о формате XML, программист тестирует аутпут своего приложения ввиде XMLя, верстальшпик верстает для этого XMLя преобразовалку отдельно от приложения.
>>Зачем мне все эти функции?
Вы спросили что умеет XSL -- я привел пример того, что он умеет.
Теперь Ваша очередь сказать -- где он топорный, И что он не умеет из того, что умеет смарти.
>> Наши верстальщики умные люди, и не пихают во всё что можно XSLT, потому что знают, что оно нужно только там, где себя оправдает.
Я не предлагаю "все" пихать в XSL. Если нужно вывести три строчки без дизайна -- то наверное XSLT тут не нужен.
Я всего лишь имел ввиду, что тезис "верстальщик не может освоить XSLT" говорит о том, что верстальшик скорее всего не очень квалифицирован.
На свете действительно не много хороших верстальщиков.
Именно потому на свете не много сайтов, которым можно сменить вертикальное меню на горизонтальное не переписав пол системы.
На свете не много сайтов, для верстки которых верстальщику не надо поднимать у себя на машине Apache и MySQL.
Но это все конечно не мешает делает сайты, и получать за них деньги.
Потому что сайт может работать и приносить прибыль даже если он весь вместе с html, css, sql и семью тысячами строк на Perl запихан в один файл (я и такие приложения видел), так что спор наверное можно прекращать:) )
Смысл в том, что всё это относится именно к технической части. Занимаясь подобным вы делаете удобную вам прослойку для тестирования и чего-то там. Но само приложение при этом становится топорным, по части внесения изменений в пользовательский интерфейс. И шаблонизатор в этом играет не последнюю роль. Естественно речь идёт не о добавления функциональности.
Я вас ничего не просил приводить, и не спрашивал чего он умеет - где вы это нашли?
Спор можно действительно прекращать, вы не видите даже моих вопросов, отвечаете на какие-то другие, наверное тредом ошиблись.
Если некто не может осилить ничего, сложнее бейсика -- это же не значит что С -- говно
Об этом говорит Ваша фраза про топрность и негибкость.
Именно это и означает, что Вы не знаете XSLT
>> Именно это и означает, что Вы не знаете XSLT
говорит о том, что Вы - трололо. Чо, лучше всех xslt знаете? Ну дык милости просим, на хабре в топике 0 постов за 2 года. Поделитесь бесценным.
Приведите пример топорности XSLя. Я Вас уже третий раз прошу это сделать.
А это, извините, попахивает холиваром. В принципе на любом языке можно реализовать любой алгоритм, вопрос только в том, какими жертвами. Я не приверженец XSL, но когда копался в нем, не смог не заметить обширнейших возможностей. Хотя он МНЕ и не понравился.
Что-то я в алгоритмах редко встречаю классы :D
Лирическое отступление:
А вообще, ИМХО, сейчас все шаблонизаторы в коей-то мере являются костылями. Толкового разделения представленя данных от исполняемого кода нету. Просто этот код заменяется на другой. И это есть очень печальное явление, может быть я и идеалист, но надо искать другие решения.
Просто раньше тянуло поучаствовать в этих холиварах) потом было пофиг. потом от них ломило скулы...а теперь просто смешно. Заведомо бесполезные попытки навязать другим свое мнение...выглядит комично)
кстати, XSL тролль больно редкая разновидность. обычно php, c++ и уебкилльные тролли...этого - в красную книгу))
ну, значит Вы без работы не останитесь)
>>Не надо приравнивать сложность языка к его "крутости
Я приравниваю не сложность, а гибкость.
>>XSL - хреновый, неоправданно сложный и абсолютно топорный и не гибкий инструмент
Если Вы не в силах освоить ничего сложнее смарти -- это не значит, что инструмент топорный и не гибкий. ))
Проблема XSL в том, что он действительно сложен. И в отличии от PHP или HTML -- нельзя писать на нем "тяп-ляп" -- иначе все будет тормозить. Потому (повторюсь) наличие XSL в проекте требует наличие спецов, а это дорого и сложно.
А теперь возвращаясь к вашему комментарию выше: адекватный разработчик выбирает средство реализации исходя из ряда критериев (целей и задач) и уж точно не заявляет голословно "Вообще на свете существует только один хороший шаблонизатор: XSLT. Но им никто не умеет пользоваться, и потому никто (кроме меня) не любит:)".
Откуда такие цифры?
"адекватный разработчик выбирает средство реализации исходя из ряда критериев (целей и задач) "
Разумеется.
При определенных условиях (например отсутствие грамотного верстальщика) я выберу другой шаблоназитор. Он будет не такой хороший, но достаточный для решения задач.
О чем мы спорим-то?
Мы спорим о том, что:
1) вы нескромно объявили себя спецом (непонятно правда что под этим подразумевается) - требуются специалисты для понимания XSLT, и конечно же вы его хорошо знаете.
2) вы утверждаете что единственный хороший шаблонизатор это XSLT независимо ни от чего (например от задач им решаемых)
3) вы утверждаете, что многие не используют XSLT потому что "обезъяны", и не обладают титулом "спеца"
В этом вы неправы, вот и спорим.
Считаю программированием - только те задачи, для которых нужны инженеры и выше.
Я однажды в качестве познания мира прочёл книжку по бухучету, оно состоит из арифметики и искусственно запутанной хуйни.
Некто тут распинался очень долго на тему, что "если вы не в силах что-то понять, это ещё не значит, что это фигня"
foreach ($this->adverts as $advert):
....
$advert->getCreateDate()->format('d.m.Y H:i:s')
не вбитая в отдельную переменную
{foreach from=$adverts item=advert}
blablabla {$advert->getCreateDate()|date_format:'%d.%m.%Y %H:%M:%S'} blablabla
{/foreach}
шаблоны [php] vs [xslt|...] :
+ php интерпретируется быстрее, чем любой шаблонизатор, написанный на php. xslt медленный то ли за счет кривой реализации, то ли хз почему
- php шаблоны активны: криворукий дизайнер ненавидит php за свою некомпетентность в нем, и потенциально может сломать всю систему (fatal error при малейшей оплошности вроде забытой точки с запятой)
+ активных php шаблонов в том, что никто не мешает прозрачно прикрутить ЛЮБОЙ нравящийся шаблонизатор. Очевидно, что никакой или, возможно, почти никакой шаблонизатор этого не позволяет
- xslt шаблоны всегда интерпретируются, и без дополнительной кеш-системы медленны как возврат долга.
- php шаблонов следует из той же их активности: если конечное приложение (фреймворк,цмс) не предоставляет дополнительный функциональный слой, то такой шаблон кишит уязвимостями - дизайнер не программист, и НЕ должен задумываться о таких вещах, как экранирование вывода.
- xslt шаблоны не так легки для понимания обыкновенных дизайнеров, чья стихия html+css, и совсем не легки в написании достаточно сложных шаблонов
вывод: думайте сами, решайте сами: должен ли шаблонами заниматься программист или компетентный дизайнер, и выигрыш в скорости, или "скинование" аппликации можно отдать любому дизайнеру для самостоятельной работы
Все таки дизайнеры рисуют макеты в фотошопах. Верстой занимаются верстальщики.
>>- xslt шаблоны не так легки для понимания обыкновенных дизайнеров, чья стихия html+css, и совсем не легки в написании достаточно сложных шаблонов
все знакомые мне хорошие верстальщики обожают именно XSLT, а никакие не смарти, PHP и так далее..
XSLT ближе к XHTML (так как оба являются подмножествами XML), так что если у вас есть хороший верстальщик -- скорее всего он будет знать XSL.
Но к сожалению чаще всего версткой занимаются люди, далекие от понимания верстки) Не знающие, что такое семантика, standard complaned итд.. И конечно для них XSL неподъемене
Если Вы делаете народру (что бы каждая макака могла завести домашнюю страничку, и раскрасить ее в салатово-сиреневые цвета) -- то да.
Если Вы делаете гугл, то скорее всего дизайн должен придумывать дизайнер, а пользователи и верстальшики должны пользовать визивим, тоесть размечать текст семантически.
Опять же -- серьезные проекты имеют выделенного верстальщика. Но если Вы делаете CMS что бы любая кухарка могла собрать свой сайт -- то конечно там не будет верстальщика, а будет визивиг.
А если он там заюзает таг "marquee" -- не стыдно потом свое имя под этим проектом ставить?
> А если он там заюзает таг "marquee"
клиент всегда прав, и заказывает музыку.
Реальный случай: мы предлагали сделать сайт вместе с каталогом товаров, плюс свой дизайн. На что клиент сказал, что бы дизайн был точь-в-точь как на его старом сайте. Пожали плечами, сделали, но в свое портфолио включать не стали
зависит от подхода студии. Лебедев например так не думает:)
но не у всех есть возможности выпенлриваться, я это понимаю...
Как хорошо не работать на клиента)
1. "Я лучше нанял бы человека с энтузиазмом, чем человека, который все знает. " - Джон Дэвисон Рокфеллер
2. Если подчиненный всегда соглашается со своим начальником, то он - бесполезная часть организации. - Хайман Джордж РиковерHyman George Rickover (27.01.1900 — 08.07.1986), адмирал США, известен как отец американского атомного флота.
Хоть это про подчиненных - но в приципе по найму ты ттоже подчиненный. И я бы опасался с тобой работать. Потому что если человек соглашается со всем что ты говоришь, либо он туп, либо хочет ободрать до ниточки.
Но это ИМХО, так что прошу не развивать холивар.
1. вначале впариваешь начальнику какой ты крутой - что б взяли на работу и именно за желаемую зарплату (конечно врать нельзя, ибо еще выгонят с позором)
2. а потом за сколько ты себя продал, начальник начинает закручивать гайки: работать приходится за троих, а не за свою з\п, сверхурочные всякие, и приходится из кожи вон лезть, что бы не было придирок
3. начальник, как правило нихера не понимает, какая это сложная работа и не сходит с мнения, что здесь делать нечего, а ты такой непрофессиональный, что не сразу делаешь "идеально",и не так быстро справляешься с задачей, как ему кажется, можно справиться. попытки доказать терпят провал в силу нежелания понять специфику работы
4. в итоге получается неблагодарный труд, и поставить себя можешь только заявлением об уходе - тогда начинают думать, а так ли ты плох, как они тебе говорят
плюсы работы на себя:
1. ты берешь проекты, которые ты можешь оценить, во сколько они тебе обойдутся, и называешь цену
2. ты контролируешь весь жизненный цикл проекта - от проектирования до реализации и поддержки
3. ты можешь договориться с клиентом, как лучше сделать, и чего делать точно не стоит
во избежание холиваров - ставлю точку. Это лично мое мнение, и если кто-то думает иначе - флаг в руки. Ваш путь - не мой путь.
Или Вам имена что ли?:)
А наличие только одного товарища, пускай и в известной компании, не даёт вам логического права говорить о "всех", тем более и без контекста использования XSLT. Тобишь решаемых задач.
Я лишь сказал что он имеет следующие плюсы:
1) Мощность и гибкость (особенно в XSLT 2)
2) Промышленный стандарт: известен всем хорошим верстальщикам и никак не зависит от бекенда
3) Позволяет разрабатывать клентскую часть отдельно (без установки веб-приложения на компьютер верстальшика)
При этом имеет минусы:
1) Требователен к ресурсам (надо кешировать)
2) Требователен к специалистам (XSLT это функциональный язык программирования, а не шаблонизатор -- нужен хороший спец).
Как следствие -- XSLT плохо подходит к сайтам для прачечных, например.
Но хорошо подходит к крупным приложениям, где и так есть кеширование и хорошие верстальщики.
80% нареканий на XSLT связано с тем, что люди его или не знают (и как следствие -- пишут тяжелые и медленные приложения) или не имеют хороших верстальшиков (которых вообще очень мало) или считают нормальным ситуацию, когда изменение меню с горизонтального на вертикальное требует работы программиста.
Голуби хорошие птицы:
1) Быстрые и наглые (особенно московские)
2) Стандартные городские птицы - все о них знают
3) ...
Вообщем этим я хотел сказать, что ваши аргументы - вовсе не аргументы. Они абсолютно разношёрстны, натянуты, либо сложно доказуемы, кроме разве что "используются в яндексе".
Я вообще за принцип "best tool" -- иногда и вордовый документ можно сохранить как HTML, и это будет наилучшим решенеим.
Для каждой задачи есть N инструментов. Сложность инструмента прямо пропорциональна его мощности и гибкости.
И что не так с моими аргументами? Вы не согласны, что промышленный стандарт лучше самопального?
Что верстать лучше не разворачивая у себя на компе веб-приложение?
Мне кажется я привел достаточно аргументов, а Вы так и не смогли сказать в чем XSLT "не гибкий" и "топорный"
Чем проще интерфейс инструмента - тем он эффективнее. Если вы используете инструмент не по назначению - тогда вы испытываете проблемы с эффективностью. Если что-то слишком сложно, значит это что-то вы делаете не так как надо. А ваше утверждение заблуждение.
Стандарт всегда лучше, но XSLT им не является из-за излишней сложности.
Очень хорошо, что вам кажется, но выше я написал о том, что это не аргументы. Аргументы - это конкретные примеры кода в сравнении, числа, например затраченное время, чёткие задачи ими решаемые, опять же в контексте эффективности, примеры масштабируемости.
>>Стандарт всегда лучше, но XSLT им не является из-за излишней сложности.
:)))))) XSLT именно что стандарт (в отличии от всего остального)
Вы бы просветились на тему того, что такое стандарт. Почитайте в википедии про W3C например, прежде чем рассуждать о верстке.
Или Вы думаете что стандарт это то, что популярно на пхпклубе?
С какого тогда, пардон, рожна Вы утверждаете, что хороший верстальщик скорее всего будет знать функциональный язык программирования? А если не знает - то он плохой верстальщик.
Если Вы мне не верите -- поговорите с верстальщиками.
Только с хорошими, которые понимают что такое "семантическая верстка" и чем валидный код отличается от велл-форменного.
Скажите, а Ваши визивиг уважают?
+ xslt позволяет, в отличие от php, html и почти любого шаблонизатора, делать семантические шаблоны, то бишь форматировать содержание не физически, а логически. Это основа идеологии xslt
Верстун и программер договариваются о формате XML, и верстун для него пишет XSLT, запуская преобразование прямо в альтове, а программер генерит XML и проверяет его тестовой утилитой.
Так что и программист может тестить свой аутпут автоматически (кто еще так умеет?!) и верстуну не надо запускать у себя на компе веб-приложение
А так, именно для того xslt и создавался.
Быть может, пройдет время, и кеширование потеряет свою актуальность в связи с убыстрением серверов...
но в крупных приложениях кеш есть все равно, причем реализован он за пределами приложения, где нить в nginx.
Конечно, если аутпут приложения меняется каждые полторы секунды -- много тут не накешируешь, и XSLT там не нужен, но это редко так бывает
такая ситуация встречается даже чаще. Например, наш любимый govnokod.ru )
Для современных i7 это не серьзные нагрузки
разве что юзать какой нить cronь
Я глупость ляпнул)
endforeach;
стандарт де-факто в симфони, до того как Фабьен занялся Twig. Имхо, более соответствует *шаблонизаторскому* синтаксису
но как только попробовал apache tapestry 5, просто влюбился в этот фреймворк в целом и в его шаблонизатор в частности: там шаблоны должны быть xml, все теги html-совместимые, за исключением тегов со своим неймспейсом, их фреймворк прозрачно обрабатывает на сервере, и такой шаблон вполне можно отдать макаковерстальщику, который должен сверх html+css знать строгие правила xml.
>>Если так, то вам следует почитать специалистов по интерфейсу, например Алана Купе
Причем интерфейс пользователя и средства разработки?
И тем более -- причем тут прототипы интерфейсов?
Если Вы считаете что верстать надо в визивиг редакторах то действительно XSLT Вам не нужен, как и почти любой другой шаблонизатор:)
хороший шаблонизатор, по моему, должен иметь теги хмл со своим неймспейсом
Да и суть смарти не в простом выводе переменных, здесь конечно лучше использовать <?=?>, а во всех этих foreach, section, модификаторах и прочих приятностях. Так мне видится.
Требует наличия IE. Выяснил, что эта штука генерирует xml+xsl, то есть сборка содержимого производится на стороне клиента браузером, причём все браузеры, кроме IE такой код выплёвывают. Не знаете, для чего это было сделано?
видимо, собственный xsl-stylesheet это не веб-стандарт. Но идея интересная - если бы это был стандарт хотя бы де-факто
заебали линками постить всякую хуету
на самом деле IE тоже понимает XSL, причем он начал делать это еще в версии 5, тоесть до стандартизации XSLя W3C, и понимал он только микрософтовский диалект
Зачем делать на нем сайты -- ума не прилоджу
А сайты на нём делают, вероятно, чтобы разгрузить сервер. Пускай процессоры клиентов напрягаются, обрабатывая страницу.
так же были обьявлены "вредными" теги marquee и blink. До сих пор думаю, а стоило ли с ними так жестоко?
а пускай. не такая уж сильная нагрузка, ну задержка перед показом юзверю даже не так заметна. Что уже конечно лучше падения сервака
Админ «города снов» считает, что это единственно верный способ вёрстки и при этом люто, бешено опускает Оперу, хотя в ней сайт тоже работает.
Принципиально новый способ верстки? семантический
хотя мне в общем подход нравится. Пишем хмл, а к нему свой хсл, где указываем, какие элементы как форматировать. Код несказанно читаемей, чем хтмл4