| |
|
|
| | Доброго времени суток вам.
Столкнулся с необходимостью организации шаблонов на сайте.
В инете я видел несколько примеров:
<html>
<head>{TITLE}</head>
<body bgcolor={BGCOLOR}>
{SOMETPLTAGS}
</body>
</html>
|
и
<html>
<head><?=$TITLE?></head>
<body bgcolor=<?=$BGCOLOR?>>
<?=$SOMETPLTAGS?>
</body>
</html>
|
Суть, я надеюсь, понятна. Но меня заинтересовала реализация шаблонов в joomla. Там для вставки в шаблон используется такой код:
<jdoc:include type="modules" name="breadcrumb" style="rounded"/>
|
т.е. там можно передавать параметры, как я понял. Но как это реализуется не могу понять. Помогите разобраться или посоветуйте как лучше сделать похожий механизм? | |
| |
|
|
| |
|
|
| |
для: angelcorpc
(06.01.2010 в 14:46)
| | | лучше не делать как в Джумле. | |
| |
|
|
| |
|
|
| |
для: angelcorpc
(06.01.2010 в 14:46)
| | | Зависит от того, какая перед вами задача - просто вставить кусок текста, или он должен иметь определённые параметры. Простой шаблонизатор (как первый вариант) могу дать. Джумловский шаблонизатор похож на бред - зачем Вам в нём разбираться? Долгий REGEX-парсинг. | |
| |
|
|
| |
|
|
| |
для: ~AquaZ~
(06.01.2010 в 16:59)
| | | На бред похож любой шаблонизатор. Тр Целоваться в пре противогазе... Есть в этом наверное что то приятное... | |
| |
|
|
| |
|
|
| |
для: Николай2357
(06.01.2010 в 23:50)
| | | Незнаю, не пробовал!.. | |
| |
|
|
| |
|
|
| |
для: angelcorpc
(06.01.2010 в 14:46)
| | | любой вариант имеет право на жизнь. дело привычки.
а по поводу бредовости третьего варианта - я бы не стал голословить... | |
| |
|
|
| |
|
|
| |
для: ride
(07.01.2010 в 00:04)
| | | Тогда посоветуйте, как лучше реализовать данную функцию.
Я делаю свою маленькую cms (те, которые существуют не подходят под нужды заказчика) и там необходимо отделить дизайн от логики. | |
| |
|
|
| |
|
|
| |
для: angelcorpc
(07.01.2010 в 00:18)
| | | настоятельно советую не пользоваться этим, вы логику включите и подумайте - зачем такие сложности?? такой шаблонизатор будет работать раз в 10 медленнее чем нормальный, без излишеств... | |
| |
|
|
| |
|
|
| |
для: nikita2206
(07.01.2010 в 00:23)
| | | такой - это какой?
а кеширование? | |
| |
|
|
| |
|
|
| |
для: ride
(07.01.2010 в 00:34)
| | | такой это вы сами поняли какой...
причем тут кеширование? если уж выигрывать скорость - то во всем. | |
| |
|
|
| |
|
|
| |
для: nikita2206
(07.01.2010 в 00:56)
| | | при том, что с цифрой 10 вы явно перестарались | |
| |
|
|
| |
|
|
| |
для: angelcorpc
(07.01.2010 в 00:18)
| | | ============ tpl.php ============
<?
class tpl
{
var $values = array();
var $html;
function get_tpl($tpl_name)
{
if(empty($tpl_name) || !file_exists($tpl_name))
{
return false;
}
else
{
$this->html = join('',file($tpl_name));
}
}
function set_value($key,$var)
{
$key = '{' . $key . '}';
$this->values[$key] = $var;
}
function tpl_parse()
{
foreach($this->values as $find => $replace)
{
$this->html = str_replace($find, $replace, $this->html);
}
}
}
|
======== КАКОЙТА файл ========
<?
require "tpl.php";
$tpl = new tpl();
$tpl->get_tpl('welcome.tpl');
$tpl->set_value('USER',$USER);
$tpl->set_value('LAST',$LAST);
$tpl->set_value('REG_DATE',$REG_DATE);
$tpl->set_value('MESSAGES',$MESSAGES);
$tpl->set_value('PERSONAL',$PERSONAL);
$tpl->tpl_parse();
echo $tpl->html;
|
А вот с цифрой 10 ошибки по-моему нет... | |
| |
|
|
| |
|
|
| |
для: ~AquaZ~
(07.01.2010 в 01:05)
| | | зато в ввашем шаблонизаторе есть очень серьезная ошибка:
что если $MESSAGES = 'блаблабла {PERSONAL} блаблабла'; | |
| |
|
|
| |
|
|
| |
для: nikita2206
(07.01.2010 в 01:23)
| | | предлагаю свой вариант простого, но пожалуй самого быстрого шаблонизатора, самого потому что он работает не на функциях str_xxx, а на парсере самого ПХП чтото вроде этого...:
<?php
class Templator {
public $replace = array(),
$replaceForAll = array();
private $tpls = array(),
$tplDir;
public function __construct($tplDir){
$this->tplDir = $tplDir;
}
public function add_tpl($name, $template){
$this->tpls[$name] = $template;
}
public function fetchTpl($tplName, $print = FALSE){
$this->replace[$tplName] = isset($this->replace[$tplName]) ? $this->replace[$tplName] : array();
$replacing = array_merge($this->replace[$tplName], $this->replaceForAll);
$tpl = !isset($this->tpls[$tplName]) ? $this->tpls[$tplName] = file_get_contents($this->tplDir.$tplName.'.tpl') : $this->tpls[$tplName];
foreach($replacing as $olnbctjhd => $asegfbrg)
$$olnbctjhd = $asegfbrg;
@eval('
unset($tpl, $replacing);
$tpl = "'.addcslashes($tpl, '"\\').'";
');
if($print) echo $tpl;
return $tpl;
}
public function set($tplName, $varName, $value = NULL){
if(func_num_args() == 2){
if(is_array($varName)) foreach($varName as $k => $v) $this->replace[$tplName][$k] = $v;
else $this->replaceForAll[$tplName] = $varName;
}
else $this->replace[$tplName][$varName] = $value;
return $this;
}
}
?>
|
| |
| |
|
|
| |
|
|
| |
для: nikita2206
(07.01.2010 в 01:23)
| | | Ок, исправляюсь
<?
function set_value($key,$var)
{
$key = '{' . $key . '}';
$this->values[$key] = str_replace('{','{',$var);
}
|
| |
| |
|
|
| |
|
|
| |
для: ~AquaZ~
(07.01.2010 в 01:33)
| | | вобще тут лучше использовать strtr($tpl, array( 'keyToReplace' => 'ReplacingText' ) );
как-бы нужно учитывать, что шаблонизаттор не должен трогать инфу из шаблна... по вашему последнему исправлению все вроде ок. пока дело не дойдет до того, когда в "welcome.php" будут жабаскрипты, в котрых "{" и "}" используется... | |
| |
|
|
| |
|
|
| |
для: nikita2206
(07.01.2010 в 01:35)
| | | Извините,
1) шаблонизатор не мой
2) такой функции не знаю, щас посмотрю. | |
| |
|
|
| |
|
|
| |
для: nikita2206
(07.01.2010 в 01:35)
| | | Ребят, вот при всей моей неприязни к шаблонизаторам, как к явлению, посмотрите сюда. Там очень много интересного. Если уж хочется извращений, то это лучше делать аккуратно и грамотно. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(07.01.2010 в 01:41)
| | | Переписываю другую ф-цию:
<?
function tpl_parse()
{
foreach($this->values as $find => $replace)
{
$this->html = str_replace($find, $replace, $this->html);
}
$this->html = str_replace('{', '{', $this->html);
}
|
И ещё: Шаблонизатор - не извращение, иногда нужно чёткое разделение. Разделение вёрстки и динамики, всё равно, что разделение вёрстки и таблицы стилей. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(07.01.2010 в 01:41)
| | | Пассивные шаблоны логичны и просты для понимания но, к сожалению, потенциал их довольно скромен. Для серьезных проектов они не подходят. | |
| |
|
|
| |
|
|
| |
для: Loki
(11.01.2010 в 13:52)
| | | Да что за такое абстрактное понятие "серьёзные проекты" интересно мне все таки узнать. Почему всегда это приводится как аргумент, причем последний и незыблемый.
Я не встречал таких проектов и не могу себе их представить. Назовите пожалуйста парочку.
PS Я сейчас работаю в команде, у нас в системе больше 30 доменов и естественно столько же движков. На всех разный дизайн, шаблонов огромная куча. И совсем недавно убили последний, который работал на СМАРТИ (наследство). Все вздохнули с облегчением, начиная от сервера, заканчивая разработчиками. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 15:53)
| | | Под этим проектом обычно понимают высоко нагруженные проекты в которых качество реализации является очень важным элементом, о таких на этом форуме речь идти вряд-ли может тк. компетентных лиц тут можно по пальцам сосчитать.
PS. Убили - перевели на нативный PHP? Если да, то зря, очень зря. В крайнем случае посмотрите на blitz templates. | |
| |
|
|
| |
|
|
| |
для: @ndry
(11.01.2010 в 15:57)
| | | Вот именно из за высокой нагруженности и убили смарти.
На счет компетентных лиц... может быть и по пальцам, но те специалисты, которые тратят тут личное время стоят нескольких тысяч обычных программистов каждый. А то и больше.
Что касается нативных шаблонов, это гораздо оптимальнее чем любой парсер. Даже тот же хваленый СМАРТИ кэширует темплейты в натив. Не работал с blitz templates, спасибо за наводку. Посмотрю ради любопытства. Но меня лично не устраивает сама постановка вопроса - менять шило на мыло (псевдотеги на команды php).
Нативные шаблоны, если их лишить логической составляющей, на поверку гораздо эффективнее и прозрачнее любого классического шаблонизатора.
PS. Тут на эту тему мной уже было спровоцировано два огромных холивара, не хотелось бы третьего. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 16:11)
| | | > Даже тот же хваленый СМАРТИ кэширует темплейты в натив.
Не кеширует, а транслирует. Хвалёный он за простоту своего синтаксиса.
> Но меня лично не устраивает сама постановка вопроса - менять шило
> на мыло (псевдотеги на команды php).
Чего уж там, пишите сайты на си! Зачем использовать псевдо-язык программирования — РНР? Всё равно интерпретатор PHP написан на си! | |
| |
|
|
| |
|
|
| |
для: Саня
(11.01.2010 в 16:26)
| | | Не кеширует, а транслирует. Хвалёный он за простоту своего синтаксиса.
Сути это не меняет. И простотой синтаксиса там пахнет не особо, если конечно не использовать его для "Привет, мир!"
Чего уж там, пишите сайты на си! Зачем использовать псевдо-язык программирования — РНР? Всё равно интерпретатор PHP написан на си!
Ну вот, началось. А я радовался, что ни кто не попрекает асмом... А чувство меры Вам не знакомо? Слово "оптимально" тоже нет? Все хорошо на своем месте. PHP как язык очень хорош, пусть он интерпретируемый. Только зачем делать еще один интерпретатор, так можно дойти до абсурда - начать писать интерпретатор для шаблонизатора.
Хотя по большому счету иногда стоит некоторые модули и на си написать. Имеется кстати и такой опыт. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 16:39)
| | | Smarty не интерпретатор. Шаблон один раз транслируется, а дальше исполняется нативный код. | |
| |
|
|
| |
|
|
| |
для: Саня
(11.01.2010 в 17:14)
| | | Smarty не интерпретатор. Шаблон один раз транслируется, а дальше исполняется нативный код.
Сначала он все таки интерпретирует птичий язык в нормальный php (назовите это извращение хоть трансляцией, хоть кэшированием, хоть интерпретацией, суть не изменится). То есть на выходе все тот же натив. Только что бы его получить, в классическом шаблонизаторе нужно сначала все вывернуть на изнанку, извратить до неузнаваемости и заставить сервер пыхтеть, чтоб перевести этот бардак в нормальные команды. Пусть даже единожды.
Для чего?
Кроме того, он должен каждый раз проверять, не внесли ли в шаблон изменений. А это тоже никак не назвать оптимальной работой приложения.
Я собственно ни за что не агитирую, каждый пишет как может и как умеет. У каждого свои предпочтения. Нравится Вам шаблонизатор - ни чего не могу сказать против.
Я только за то, что бы это не преподавалось как единственно правильное и безальтернативное решение. Я вот допустим с каждым разом все больше убеждаюсь в своей правоте, не смотря на моду и повальное увлечение. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 17:36)
| | | Вот в соседней теме @ndry считает что $num_ip = ip2long($ip); умопомрачительно быстрее чем $num_ip = sprintf('%u', ip2long($ip));
Кажется вы нашли друг друга.
> Я только за то, что бы это не преподавалось
> как единственно правильное и безальтернативное
А кто подаёт-то? Я просто пытаюсь развенчать ваши заблуждения. | |
| |
|
|
| |
|
|
| |
для: Саня
(11.01.2010 в 17:43)
| | | В соседней теме все просто - можно измерить и все встанет на свои места.
А на счет моих заблуждений, послушайте совета Loki, бисер пригодится. Еще стразики могут понадобится и другие аксесуары, без них в гламурныую тусовку крутых программистов вход заказан.
А мне туда не надо, я и без светских вечеринок нормально живу. У меня все на своем месте, никаких излишеств и понтов. Все оптимально.
И еще. Если я имею свою, неоднократно проверенную точку зрения, но она отличается от общепринятой (хоть и недоказанной абсолютно), то это не значит, что у меня заблуждение.
А как же тогда быть с огромной кучей приверженцев натива, они тоже все заблуждаются и "серьёзных проектов" не видели?
Я как то просил в прошлом холиваре господина Loki показать хоть одну ссылку на такой проект, куда, как он выразился, не подходят нативные шаблоны. Прошлый раз какое то невнятное бурчание про котенка, теперь про бисер...
Я расту однако, уже до поросенка дорос))) Только ссылки я так и не увидел. | |
| |
|
|
| |
|
|
| |
для: Саня
(11.01.2010 в 17:43)
| | | >Вот в соседней теме @ndry считает что $num_ip = ip2long($ip); умопомрачительно быстрее чем $num_ip = sprintf('%u', ip2long($ip));
>Кажется вы нашли друг друга
Там это весьма доказуемо на синтетических тестах, проверьте если будет желание. Вы просто пытаетесь навязать своё мнение как единое верное, а я дал альтернативу, более быструю, но более сложную в реализации и это вам не понравилось.
Тут же дело больше в архитектуре и недопонимании друг друга. | |
| |
|
|
| |
автор: [0] (11.01.2010 в 19:33) |
|
| |
для: @ndry
(11.01.2010 в 18:46)
| | | > Там это весьма доказуемо на синтетических тестах, проверьте если будет желание
Товарищ, и без тестов понятно, что операция A выполнится быстрее, чем A + B. Другое дело, что Вы не поняли зачем нужно sprintf('%u', ip2long($ip)) | |
| |
|
|
| |
|
|
| |
для: [0]
(11.01.2010 в 19:33)
| | | Я понял зачем, вы сначала преобразовываете айпи адрес в signed int, а потом sig int преобразовываете в строчку, которая содержит в себе unsigned int. Я просто более склонен учить людей сразу правильным подходам с разными вариантами, а не сначала показывать все функции, а они (в будущем) пусть уже сами разбираются с производительностью, архитектурой и т.д. | |
| |
|
|
| |
автор: [0] (11.01.2010 в 19:51) |
|
| |
для: @ndry
(11.01.2010 в 19:47)
| | | Ну и что же Вы видите неправильного sprintf('%u', ip2long($ip))? | |
| |
|
|
| |
|
|
| |
для: [0]
(11.01.2010 в 19:51)
| | | Это правильно, но не оптимально.
Просто в моей идеологии программист должен писать минимум лишнего кода, если мы заранее можем перестроить источник информации как нам удобно, то почему бы это не сделать... Это же одноразовая операция, которая очень просто реализуется. | |
| |
|
|
| |
|
|
| |
для: Саня
(11.01.2010 в 17:14)
| | | Поберегите бисер - не та аудитория;) | |
| |
|
|
| |
|
|
| |
для: Николай2357
(07.01.2010 в 01:41)
| | | Данные в любом случае должны быть отделены от бизнес логики, не зря же создавали паттерн MVC. | |
| |
|
|
| |
|
|
| |
для: @ndry
(11.01.2010 в 14:40)
| | | А я разве сказал что не нужно? Только причем тут MVC? Паттерн кстати сам по себе тоже далеко не идеальный, особенно в условиях жесткой конкуренции. При DDOS атаках это жуткое зло. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 15:54)
| | | Ни один из существующих паттернов проектирования не решает задачу защиты от DDOS. | |
| |
|
|
| |
|
|
| |
для: Саня
(11.01.2010 в 16:27)
| | | Ни один из существующих паттернов проектирования не решает задачу защиты от DDOS.
Не решает. Но система с одним входным шлюзом еще больше усложняет работу по борьбе с этой напастью. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 16:40)
| | | И как же? | |
| |
|
|
| |
|
|
| |
для: Саня
(11.01.2010 в 17:14)
| | | Очень просто. Если нет единой точки входа, то в тот модуль, на который атака, ложится html заглушка. И все уже легче, хотя бы php и бд не насилуются. А остальные модули работают в штатном режиме.
При MVC это сделать нереально, там коммутация в любом случае в php осуществляется. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 17:40)
| | | В большинстве случаев сайт обслуживает один веб-сервер. Так что не важно сколько точек входа в сайт. Канал всё равно будет забит, а веб-сервер перегружен запросами. | |
| |
|
|
| |
|
|
| |
для: Саня
(11.01.2010 в 17:45)
| | | В большинстве случаев сайт обслуживает один веб-сервер.
У меня четыре.
Кроме канала есть еще возможности серверов. Того же мускула к примеру. Если атака такая, что забивает канал, то это одно. А если канал справляется, а мускул нет - другое. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 18:00)
| | | При чём тут БД к MVC? Давайте на пальцах чему вам не нравятся шаблонизаторы и паттерн MVC как таковой? | |
| |
|
|
| |
|
|
| |
для: @ndry
(11.01.2010 в 18:21)
| | | Я не сказал что MVC мне не нравится. Я сказал, что это не идеальная схема. И кстати, к шаблонизаторам не имеет ни малейшего отношения.
А шаблонизаторы не нравятся по трем основным причинам:
1. Сложность в разработке (дополнительный птичий язык)
2. Ресурсоемкость.
3. Скорость обработки. (см п.2)
Нативный синтаксис я кстати сказать использую не в чистом виде, как обычно принято, а с минимумом логики в шаблоне.
Есть у этого подхода и свои недостатки, идеально разделить бизнес-логику и представление не удасться никому по определению. Именно по тому, что сам язык PHP призван объеденить их, а не разделить. Такова была изначальная идея.
Если хочется четкого разделения, нужно использовать другие инструменты, менее удобные для веб-разработки.
А рассуждать на тему - "шаблонизатор, как вершина человеческой мысли" несостоятельно. Идея провальна сама по себе. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 18:33)
| | | 1. Шаблонизаторы. Они не обязательно будут медленнее, чем нативный код PHP. Я уже говорил - посмотрите на blitz (он выполнен в качестве расширения к PHP). В том же смарти код сначала преобразовывается в нативный PHP, а потом уже используется и это преобразование происходит всего 1 раз (если шаблоны не обновляются). Возникающие задержки минимальные, верстать становится удобнее, шаблон отделён от бизнес логики.
- Доп. язык (птичий, как вы говорите) нужно выучить лишь 1 раз или вы его сами разработаете и уж вам он точно будет абсолютно понятен.
- Ресурсоёмкость вопрос сомнителен, зависит от подхода в архитектуре. Кто мешал кешировать страницы целяком и т.д.?
Шаблонизатор - не панацея, но это очень удобный инструмент, который нужно понимать и использовать.
2. > Именно по тому, что сам язык PHP призван объеденить их, а не разделить.
В данный момент это совсем не так, PHP развивается и этот стереотип давно в прошлом. Посмотрите на все популярные разработки - в них всех код стараются отделить от шаблонов. | |
| |
|
|
| |
|
|
| |
для: @ndry
(11.01.2010 в 18:44)
| | | 1. Шаблонизаторы. Они не обязательно будут медленнее, чем нативный код PHP.
Обязательно. Не знаю, повторюсь, как работает blitz, может это что то прорывное. Но вряд ли.
В том же смарти код сначала преобразовывается в нативный PHP, а потом уже используется и это преобразование происходит всего 1 раз (если шаблоны не обновляются).
Даже из за того, что это решает шаблонизатор - уже плохо. Он в любом случае должен проверить, обновлялись шаблоны или нет.
Возникающие задержки минимальные, верстать становится удобнее, шаблон отделён от бизнес логики.
Задержки иногда совсем не минимальны. А верстать становится не удобнее, а намного сложнее. И даже не столько из за того, что верстальщик должен изучить логический язык шаблонизатора, а из за того, что результат нельзя проверить помимо шаблонизатора.
Отделить бизнесс-логику от представления можно гораздо проще и эффективнее.
Шаблонизатор - не панацея, но это очень удобный инструмент, который нужно понимать и использовать.
Кому как, очень многие верстальщики боятся его как черт ладана. Понимать - конечно, использовать - увольте.
В данный момент это совсем не так, PHP развивается и этот стереотип давно в прошлом. Посмотрите на все популярные разработки - в них всех код стараются отделить от шаблонов.
Это не стереотип, а суровая реальность. Дескриптор <? служит для того, что бы перевести разбор кода из гипертекста в интерпретируемые команды. То есть вставить логику в разметку. А теперь на том же самом языке, который должен вставляться в текст, делается попытка этот самый текст всунуть в интерпретатор. То есть на лицо удаление гланд не через то отверстие.
Вот если бы было наоборот, гипертекст вставлялся бы в программу - вопросов нет. А так, какими бы не обладал возможностями язык - суть у него одна - объеденить исполняемый код и гипертекст. А не разделить вовсе.
По этому писать следующий виток (шаблонизатор) - значит заставить инструмент выполнять несвойственные ему функции.
Забитый молотком шуруп будет держаться лучше, чем закрученный отверткой гвоздь. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 19:09)
| | | > Обязательно. Не знаю, повторюсь, как работает blitz, может это что то прорывное. Но вряд ли.
Снова вы за своё. Тест Blitz: http://alexeyrybak.com/blitz/lebowski-bench-small.gif посмотрите разницу между PHP Includes и Blitz. Кроме того компилируемые шаблонизаторы уж никак не могут работать дольше нативного кода, они и есть чистый нативный код. Экономия в миллисекунды, которая важна разве-что для фейсбука и пр.
> Забитый молотком шуруп будет держаться лучше, чем закрученный отверткой гвоздь.
Я уже устал это доказывать. PHP создавался давно, для других целей, а теперь это не слабый ООП язык программирования или ООП тоже нельзя использовать если его сразу не было. Всё это - прогресс, а дескриптор и ваш взгляд скорее лишь дань истории. | |
| |
|
|
| |
|
|
| |
для: @ndry
(11.01.2010 в 19:14)
| | | а теперь это не слабый ООП язык программирования или ООП тоже нельзя использовать если его сразу не было. Всё это - прогресс, а дескриптор и ваш взгляд скорее лишь дань истории.
Совсем недавно обсуждалось.
Я не считаю это прогрессом, я считаю это совершенно другим направлением. Точно так же, как и php в свое время отпочковался от перла. Я не считаю это эволюцией, никогда в PHP ООП не заменит процедурное программирование.
ООП для одних целей, процедура для других. Писать код из трех строчек, используя классы - это не прогресс. Это глупость по меньшей мере.
Собственно и большинство веб-приложений не нуждаются в объектной архитектуре. Именно потому, что это обычно набор самодостаточных маленьких программ, используемых единожды. Что противоречит идее и духу ООП.
И кстати MVC прекрасно реализуется на процедуре.
А вот сам язык, основа, ядро, по сути осталось прежним. И выполняет в массе своей те же функции - соединяет логику и вывод.
Вы можете писать как угодно, но говорить, что писать можно только так и никак иначе - это явный перегиб.
Оглянитесь просто, вдумайтесь немного. Ведь Вы все усложняете неимоверно своими шаблонизаторами, парадигмами и прочими "высокими" технологиями. Пытаясь упростить наверно. Но в этой гонке просто забываете, что не всегда выгодно ездить на КаМАЗе, только потому, что он очень мощный и Вы умеете им управлять. Иногда и на легковой машине интереснее проехать, а часто вообще на велосипеде. Как японцы допустим.
Очень часто намного оптимальнее использовать простые схемы, не гоняясь за модой на ООП, PDO, фреймворки, шаблонизаторы и иже с ними.
Я уже устал это доказывать.
А я устал слушать подобные "доказательства", базирующиеся в основном не на здравой логике, а на повально-поголовной моде на унификацию, полиформизм, стремление решить все проблемы одним махом. Плюс налет самолюбования - без этих выкрутасов мол пишут исключительно нубы.
Ведь истина стара, как экскримент плезиозавра, ныне покойного. Чем сложнее механизм - тем больше вероятность его сбоя.
И "красоту" индусского кода на три гектара вместо трех строк оставьте для заказчиков, красота программы - оптимальность. Без излишеств, таких как шаблонизаторы в частности. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 20:17)
| | | > Очень часто намного оптимальнее использовать простые схемы, не гоняясь за модой на ООП, PDO, фреймворки, шаблонизаторы и иже с ними.
Разница будет такой-же, как от оптимизации одного SQL запроса, а стоимость поддержки (и её удобство) сильно страдают. Мне например абсолютно не нравится разбираться в каше кода и HTML разметки, как и большинству программистов, а железо (серверное) сейчас стоит намного дешевле труда самих девелоперов.
Что касается ООП: когда ваш проект разрастётся и накопит много функционала писать его процедурным методом - изврат.
Для мена красота программы - это в первую очередь элегантность решений внутри её, а потом уже производительность, функциональность и безопасность. Красивый ООП код с использованием шаблонов даже приятно читать. | |
| |
|
|
| |
|
|
| |
для: @ndry
(11.01.2010 в 23:19)
| | | Ну во первых, ни кто и не предлагал кашу из кода и разметки. Как раз наоборот, я всегда придерживался мнения, что шаблон максимально должен быть похож на html. А вот это действительно каша из разметки и суррогата:
{if $cont.kurs>0}
<div class="sites">
: <b>{$cont.procent}%</b><span class="sep">|</span> : <b>{$cont.kurs}.</b><span class="sep">|</span>
{if $cont.balance>0}
{math equation=x/y x=$cont.balance y=$cont.kurs assign=bal_usd}
{else}
{assign var=bal_usd value=0}
{/if}
{if $cont.kvyp>0}
{math equation=x/y x=$cont.kvyp y=$cont.kurs assign=kvyp_usd}
{else}
{assign var=kvyp_usd value=0}
{/if}
: <b>{$cont.balance|string_format:"%.2f"} . (${$bal_usd|string_format:"%.2f"})</b><span class="sep">|</span> : <b>{$cont.kvyp|string_format:"%.2f"} . (${$kvyp_usd|string_format:"%.2f"})</b>
</div>
{/if}
|
Куда проще и прозрачнее так:
<div class="sites">
: <b><?php echo $procent ?></b><span class="sep">|</span> : <b><?php echo $kurs ?></b><span class="sep">|</span>
<?php echo $balance ?>
<?php echo $kvyp ?>
: <b><?php echo $balance_format ?> . (<?php echo $kvyp_format ?>)</b><span class="sep">|</span> : <b>
<?php echo $kvv_format ?> . (<?php echo $kvp_format ?>)</b>
</div>
|
хотя это одно и тоже.
И давайте спросим у верстальщиков, в чем им будет проще разобраться.
Что касается ООП: когда ваш проект разрастётся и накопит много функционала писать его процедурным методом - изврат.
Опять 25. Я же не говорил, что ООП это зло. Я говорил о повальном увлечении. Когда мои проекты разрастаются и код начинает повторяться, я с удовольствием использую классы. Кроме того, у меня давно наработана библиотека своих классов (почта, аплоадеры, постраничка, формы и так далее), которые я использую в разработке.
Но проектировать всё приложение, используя ООП парадигму считаю не просто избыточным, но и крайне усложняющим разработку и дальнейшее обслуживание действием. Мало того, как показала практика, это совсем не сокращает время разработки. И усложняет дальнейшую поддержку.
Всё хорошо на своих местах. Класс - там, где код повторяется и часто используется. Процедура там, где можно свободно обойтись функциями. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 23:42)
| | | Ваш пример с кодом шаблона, мягко говоря, не самый лучший) В PHP вы перенесли форматирование и все функции в другое место, что можно было сделать и в шаблонизаторе и код бы выглядел аналогично, даже красивее. | |
| |
|
|
| |
|
|
| |
для: @ndry
(11.01.2010 в 23:52)
| | | А вот на вкус и цвет товарища нет.
Не Вы ли говорили, что нужно разделять бизнесс-логику и представление? И тут же говорите, что логика в шаблоне - красивее. Как то последовательнее надо быть.
Если это логика - ей место в логической состовляющей. Именно там, где удобно работать программисту.
А если это разметка, то нечего там делать ифам и форечам. На то оно и разделение.
А Вы подменяете понятия и считаете это красотой... Я этого никогда не пойму. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 23:57)
| | | Ну вот как бы он выглядел.
<div class="sites">
: <b>{$procent}</b><span class="sep">|</span> : <b>{$kurs}</b><span class="sep">|</span>
{$balance}
{$kvyp}
: <b>{$balance_format} . ({$kvyp_format})</b><span class="sep">|</span> : <b>
{$kvv_format} . ({$kvp_format})</b>
</div>
|
Но только не нужно мне рассказывать про производительность, я уже объяснял почему это не так и как убрать все проблемы в данном вопросе. Что касается изначального шаблона - он хорош, в нём верстальщик не копаясь в коде и не зная PHP может использовать элементарный API приложения чтобы оформить страницу как он пожелает. Вот зачем это всё делается. Вы работаете только на себя, потому и не понимаете.
> Не Вы ли говорили, что нужно разделять бизнесс-логику и представление?
Прошу различать бизнес логику от логики представления информации, как что отформатировать в шаблоне - логика представления. | |
| |
|
|
| |
|
|
| |
для: @ndry
(12.01.2010 в 00:04)
| | | Секундочку. А в чем принципиальная разница между
и коль на то пошло? Чем это фигурные скобки красивее дескрипторов? И ради чего делать шаблонизатор, ради того, что бы поменять одно на другое? Не вижу логики... Я согласен с тем, что перенести часть логики в шаблон - какая то польза. Не дробить его на составные части. Но Ваш пример - это верх нелепости. Он сочетает в себе недостатки обоих подходов и не несет никакой пользы.
Вы работаете только на себя, потому и не понимаете.
Отнюдь. У нас много работников, которые трудятся на удаленке. А это означает большую текучку кадров. Что как раз заставляет задумываться о том, что бы максимально быстро и малой кровью можно было внедрить нового человека в разработку. Изучение дополнительного синтаксиса шаблонов этому никак не способствует. А дескриптор php худо бедно любой верстальщик пару раз видел. Так что Вы тут в корне не правы.
Прошу различать бизнес логику от логики представления информации, как что отформатировать в шаблоне - логика представления.
А я прошу читать внимательнее мои высказывания. Я вообще против какой либо логики в шаблонах. Как её не называйте. Логика она и в африке логика. А шаблон - дело статичное. И логики там быть не должно по определению. Все остальное - подмена понятий. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(12.01.2010 в 00:33)
| | | > коль на то пошло? Чем это фигурные скобки красивее дескрипторов?
Абсолютно никакой, кроме краткости. Просто я показал как ваш шаблон бы выглядел. Но обрезать логику представления всё-равно не уместно, я объяснил почему - API для верстальщиков, которым нахрен ваш PHP не сдался. Они должны иметь возможность изменять логику представления в шаблоне. Любой средний верстальщик знает синтаксис того-же Smarty, в отличии от PHP. | |
| |
|
|
| |
|
|
| |
для: @ndry
(12.01.2010 в 00:38)
| | | Да не нужен никакой API и не нужно знать никакого PHP верстальщику для работы с моим шаблономм. Достаточно блокнота и браузера. Откройте его напрямую - он просто проигнорирует PHP вставки, посчитав неизвестным тегом. А краткость записи чревата излишним функционалом и дополнительным синтаксисом.
Любой средний верстальщик знает синтаксис того-же Smarty, в отличии от PHP.
Большое заблуждение. Далеко не любой и даже не средний. Лично я знаю достаточно много талантливых верстальщиков, которых тошнит от одного упоминания СМАРТИ. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(12.01.2010 в 00:46)
| | | > верстальщиков, которых тошнит от одного упоминания СМАРТИ
пока работал в фрилансе не встречал толковых верстальщиков, которых тошнит от смарти. Некоторые его не использовали - да, но они не отказываются от такой работы и учатся на ходу (работа со смарти очень проста).
> Да не нужен никакой API и не нужно знать никакого PHP верстальщику для работы с моим шаблономм.
В вашем подходе да, но вы фактически даёте лишь доступ к переменным, но не методам их обработки (методы PHP означают необходимость в знании хотя-бы основ PHP). | |
| |
|
|
| |
|
|
| |
для: @ndry
(12.01.2010 в 00:50)
| | | пока работал в фрилансе не встречал толковых верстальщиков, которых тошнит от смарти. Некоторые его не использовали - да, но они не отказываются от такой работы и учатся на ходу (работа со смарти очень проста).
Ой ли... Так уж и проста. А что касаемо отказываться от работы на фрилансе - дык конечно. Там не только тошнить будет, блевать начнешь. А делать все равно надо. Только удовольствия от этого разве что мазохисты получают. А делать работу без удовольствия и без души - нафиг надо такая работа.
вы фактически даёте лишь доступ к переменным, но не методам их обработки (методы PHP означают необходимость в знании хотя-бы основ PHP).
Именно так. Верстальщик должен работать своими инструментами - HTML и CSS. Не нужно ему трогать никаких переменных. И тем более не нужна ему никакая логика. Сверстал страницу по макету, очень хорошо. Останется разделить шаблон и вставить переменные. Никаких СМАРТЕЙ и прочего, что верстальщику не свойственно. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(12.01.2010 в 01:07)
| | | > Только удовольствия от этого разве что мазохисты получают.
Я не сотрудничаю с людьми которые делают работу не в своё удовольствие, когда человек относится к заданию как к творчеству, которое должно быть уникально и гениально он не станет только ради денег верстать что-либо.
Вы вообще спорите со мной о том, о чём не знаете. Давайте не будете, а? Я тех людей знал получше вашего.
> Именно так. Верстальщик должен работать своими инструментами - HTML и CSS. Не нужно ему трогать никаких переменных. И тем более не нужна ему никакая логика. Сверстал страницу по макету, очень хорошо. Останется разделить шаблон и вставить переменные. Никаких СМАРТЕЙ и прочего, что верстальщику не свойственно.
Кардинально не согласен, но устал от холивара потому думайте как хотите, со временем это к вам само придёт, надеюсь скоро. | |
| |
|
|
| |
|
|
| |
для: @ndry
(12.01.2010 в 01:10)
| | | И не надейтесь. Я не просто так к этому пришел, это естественный отбор, если хотите.
Просто я ни разу не слышал ни одного более менее разумного довода в пользу шаблонизаторов. Все сводится к тому, что я сам скоро это пойму. А что пойму, не ясно. Все что нужно понятно давно, нового ни кто добавить не может.
Повторяю - ни одного толкового довода в пользу шаблонизации я ни разу не слышал. А вот недостатков я на себе испытал массу.
Так что мне остается пожелать Вам того же - когда нибудь розовая пелена спадет с Ваших глаз и Вы увидите вещи такими, какие они есть на самом деле. А не завуалированными модными понятиями. Надеюсь скоро. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(12.01.2010 в 01:19)
| | | Я давал массу разумных доводов, которые разумны для многих, но не для вас, потому никаких "разумных доводов" вы и не слышали. Это всё-равно, что спорить со стенкой.
Я раньше тоже смешивал код и представление и думал как вы, так что пелена уже спала, за это не волнуйтесь. | |
| |
|
|
| |
|
|
| |
для: @ndry
(12.01.2010 в 01:24)
| | | Вы давали массу расплывчатых, не выдерживающих критики рекомендаций. Доводов, таких, которые могли бы действительно выгодно отличить классические шаблоны от нативных не было ни одного. Пустое все - плавал мол, знаю. В прошлый раз я представил свои доводы, ответа не последовало. Потому что его нет по определению. Единственный, притянутый за уши довод - безопасность шаблонов. Ради этого терпеть кучу недостатков - увольте.
Я раньше тоже смешивал код и представление и думал как вы, так что пелена уже спала, за это не волнуйтесь.
Комичность ситуации в том, что смешивать Вы ничего не перестали. Даже наоборот - примешали сюда дополнительное зелье. Мало было двух языков, наболтаем третий и будем радоваться, что все поделилось. Ой ли... | |
| |
|
|
| |
|
|
| |
для: Николай2357
(12.01.2010 в 01:34)
| | | Вопрос о том что лучше PHP или шаблонизатор не самый главный, гораздо важнее (вы его суть просто искажаете) это использовать шаблоны или нет. Шаблоны — и выделение представления — необходимы. А в каком виде оно представлено, не так уж важно, главное, чтобы людям, которые работают с шаблоном, было максимально удобно это делать. Сам метод шаблонизации должен найти золотую средину между производительностью и функциональностью.
И если, например, вы в своей практике не сталкивались с необходимостью выпускать коммерческий продукт, в котором API для верстальщиков должно быть обязательно, то это значит лишь что у вас "такая практика" и естественно вы будете закрывать на все доводы глазами со словами "да зачем это".
Подводя итог про аргументы: я уже говорил про производительность Blitz (что выше PHP includes), об присутствии API, об безопасности, об удобстве в поддержке - это для вас не доводы, уж извольте использование PHP тогда тоже недопустимо (PHP в итоге он не быстрее, не удобнее для конечного разработчика [всех, кроме вас, конечно], не безопаснее [дада, за уши], на работу с ним нужно платить программисту больше денег)... Идти против логики ужасно...
Больше комментировать не собираюсь. Давным давно стало понятно что вы своей стороны будете придерживаться с пеной у рта даже если поймёте, что не правы. Это особенность психологии некоторых людей - придерживаться чёткой определённой позиции даже против здравого смысла. | |
| |
|
|
| |
|
|
| |
для: @ndry
(12.01.2010 в 03:50)
| | | Вот Вы говорили, что пелена спала, а я вижу что нет. Вы же не поняли сути, совсем не поняли. Уцепились за то, что это PHP, а значит (по вашему рассуждению) вовсе не шаблон.
Вся беда таких как Вы ярых фанатиков шаблонизаторов в том, что вы попутали понятие
"разделить бизнесс-логику и представление" с понятием "разделить PHP И HTML"
Я ни разу ни где не написал, что логику и вывод делить не нужно. Разумеется нужно. Более того, нужно делить как можно тщательнее, по возможности исключив из шаблонов логическую состовляющую. Ведь верстальщик по сути своей - дизайнер. Художник, если хотите. (Конечно, если вы работаете с верстальщиками-программистами, остается посочуствовать). А у художника мышление абстрактное и алогичное, на то он и худождник. Всяческие логические рамки, в которые его кто нибудь попытается загнать, вредять процессу творчества. Ему должно быть комфортно.
И так, пункт первый - удобство разработки.
Что же называете удобным и комфортным Вы. А вот это:
<ul class="list">
{foreach from=$sites item=site}
<li>{$site.URL}/?id={$site.id}</li>
{/foreach}
</ul>
|
То есть по сути тот же логический язык. Ведь это тоже самое, что и это:
<ul class="list">
<?php foreach( $sites as $site){ ?>
<li><?php echo $site['URL']; ?>/?id=<?php echo $site['id']; ?></li>
<?php } ?>
</ul>
|
только написанное на птичьем языке. Та же самая логика, то же самое смешение коней и людей. Просто завуалированно, мол это не PHP, а значит не логика.
Она, родимая, она. И никуда Вам от неё не деться.
Так что заявления плана
"Шаблонизатор делит бизнесс-логику и представление" несостоятельно.
Справедливости ради нужно отметить, что Вы применяете другие термины:
"Разделить бизнесс-логику с логикой представления." Ну и с чем боролись, на то и напопролись (См код выше) Подменили понятия (один логический язык другим) и считаем, что произошло разделение. А верстальщику ни кисло ни холодно от того, что там вместо дескрипторов фигурные скобки. Да, короче запись, но:
Ему логика в шаблоне вообще не нужна.
Так что первый пункт о удобстве разработки сильно надуман. Это привычнее для Вас, но это не значит удобнее. Вот у господина Loki другое видение удобства, у kosta_in_net третье... Сколько людей. столько шаблонизаторов мнений. У меня и моих соратников тоже свое мнение. И мы считаем удобным натив. По возможности без логической составляющей.
По крайней мере у такого подхода есть простор для маневра - можно писать в шаблон циклы, а можно вынести в отдельные файлы. Чего никак не позволяет костный шаблонизатор. Там померла, так померла. Будь добр придерживаться суррогатного синтаксиса.
Пункт 2. Удобство поддержки.
Ну и кому, позвольте полюбопытствовать это удобно?
Вам. И только Вам. Потому что это Вами разработанные шаблоны, с применением шаблонизатора Blitz . Или господину Loki , потому что это его шаблонизатор. Или господину kosta_in_net, потому что это его схема.
А мне не удобно. И уверен - большенству тех, кто видит этот код впервые, неудобно так же. Потому что прежде чем разобраться в логике шаблона, придется разбираться в логике шаблонизатора. И в его синтаксисе.
Вот Вы сейчас скажите - выучить язык шаблонизатора нужно всего один раз. Ан нет. Если бы. Все дело в том, что этих шаблонизаторов пруд пруди, начиная от хваленой СМАРТИ заканчивая самописными шедеврами. Вот про Ваш Blitz я впервые слышу допустим. А совсем недавно так же точно другой апонент охал и ахал по поводу PHPTAL и говорил, что круче только яйца. И так у всех - куча шаблонизаторов, куча языков, куча синтаксисов, куча мнений.
Так что об удобстве поддержки говорить не приходится. Это было бы удобным, если был бы стандарт. А так это удобно узкому кругу лиц, которые выбрали одну схему и фанатеют от неё.
Так что не убедительно.
3. Производительность. Ничего не скажу про Blitz, но одно знаю точно. Никогда дополнительный функционал не даст прироста в производительности. Если это не акселератор конечно. Это акселератор? Нет. Так что вряд ли.
Ну и даже пусть разница незначительна. Во первых, не Вы ли несколькими постами выше позволили себе это высказывание:
Просто в моей идеологии программист должен писать минимум лишнего кода,
и тут же предлагаете целое приложение ради того, что бы поменять дескрипторы на фигурные скобки... Тут уж доктор, определитесь. Либо туда, либо обратно. Даже из за того, что шаблонизатор займет часть оперативной памяти, это уже не оптимально. И о ресурсобережливости говорить смешно.
4. Безопасность. Тут да, шаблон по Вашей схеме пассивен, исполняемый код туда не сунуть. Но.
Так ли страшен черт, как его малютки? Какой глобальный катаклизм может вызвать злобный верстальщик и тать, засунувший под покровом ночи исполняемый код в шаблон. Дропнуть базу? Снести весь сайт с хоста? Вирус запустить?
Ну право смешно. На то есть бэкапы. А он тут же будет пойман и бит. Ни один человек в здравом уме и рассудке такого не совершит. А уж если Вам приходится оглядываться на таких сослуживцев и всячески страховать свою спину от предательских плевков, то во первых я Вам сочуствую, а во вторых это не поможет. Если человек решил напакостить - он найдет способ. Допустим вместо красивой логики шаблона напишет огромными буквами: НАЧАЛЬНИК КАЗЕЛ, Эфект даже круче, чем пара часов остановленного сайта.
Надумано это и притянуто за уши.
Пункт про то, что программисту нужно платить больше денег недогнал. С какого перепуга программисту нужно платить больше за то, что он не знает суррогатных языков, а работает в привычном для него PHP. Или имелось ввиду что то другое?
Впрочем хватит. Этот трактат больше для истории, чем для Вас. Вас уже ничего не исправит. Это как наркотик - раз попробовал - все доводы кажутся несостоятельными.
Это тоже особенность психологии. А в Вашем случае уже и анатомии.
Я вот сумел спрыгнуть с иглы, хотя мне было проще. Я идеологию шаблонизаторов никогда не разделял. Приходилось работать с ними, но, как в анекдоте про водку и партбилет - без удовольствия. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(12.01.2010 в 09:35)
| | | да ну за что ты меня к шаблонизаторам? Мне однажды потребовалось сделать форму для отправки писем, где чел мог произвольно указыват, куда вставлять вывод программ. Не буду же я его просить выучить пхп. Я сделал ему десяток переменных и маленький хелп, что они означают. И все. В остальном я избегаю подобного бреда, так как псевдоязыков много. Мне проще выучить один ПХП, чем кучу псевдоязыков, призванных отнять его у меня.
Но я предложил вариант шаблонизатора на тот случай, если он нужен (мало ли?). И я вовсе не агитирую за подмену языка псевдоязыками. | |
| |
|
|
| |
|
|
| |
для: kosta_in_net
(12.01.2010 в 10:08)
| | | Ну прошу простить великодушно.)) Просто Вы оказались в нужном месте в нужное время. ;)
У каждой попытки разделить бизнесс-логику и представление есть свои недостатки. И у классических шаблонов, и у нативных, и у Вашей схемы тоже.
С этим нужно смириться, се ля ви.
Рассуждения вышеозначенного товарища на тему "шаблонизатор - это круто, остальное шлак" вызывает как минимум умиление))). | |
| |
|
|
| |
|
|
| |
для: Николай2357
(12.01.2010 в 12:55)
| | | читал бегло, поэтому переспрошу.
то есть, вы всегда пишите так:
<table>
<?php
$q = mysql_query($sql);
while($r = mysql_fetch_assoc($q)){?>
<tr><td><?php echo$r[$field]?></td></tr>
<?php}?>
</table>
|
? | |
| |
|
|
| |
|
|
| |
для: ride
(12.01.2010 в 13:10)
| | | Нет. Я делаю иначе. В шаблоне я вывожу только переменные, логика остается в файлах php. Это не очень красиво с точки зрения целостности шаблона, его приходится делить. Но у всех схем есть недостатки, нужно просто что то выбрать для себя. Выглядет это примерно так (упрощенно):
<?
function parseTpl($cont, $data)
{
extract($data);
ob_start();
eval('?>'. $cont .'<?php');
$code = ob_get_contents();
ob_end_clean();
return $code;
}
$rows = '';
$cont = file_get_contents('rows.html');
$q = mysql_query($sql);
while($r = mysql_fetch_assoc($q))
{
$rows .= parseTpl($cont, $r)
}
|
template.html
<table>
<?php echo $rows; ?>
</table>
|
rows.html
<tr>
<td><?php echo $field ?></td>
</tr>
|
Для меня преимущества очевидны -
1. отсутствие суррогатного синтаксиса
2. минимальный дополнительный функционал (функция используется только в необходимых местах, циклах и пр)
3. простор для маневра. Можно свободно использовать и чистый натив, как у Вас в примере.
4. Шаблон верстается без оглядки на интерфейсы, простым и чистым HTML, который потом делится на состовляющие. Кроме того, вывод переменных в дескрипторах не вредит верстке, так как браузер их просто игнорирует.
Из недостатков - шаблон приходится дробить на состовляющие.
Кому то это не понравится - и слава Богу. Кто то необоснованно испугается функции eval()... Кто то скажет, что лишние обращения к ФС...
Каждый волен выбирать сам. Вот только считать, что шаблонизатор - единственны и самый лучший выход из положения не стоит. Сколько людей, столько и мнений. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(12.01.2010 в 16:06)
| | | имхо, с инклудом проще, к тому же, насколько я знаю, с акселератором инклуд побыстрее будет.
и я за логику в представлении. | |
| |
|
|
| |
|
|
| |
для: ride
(12.01.2010 в 18:45)
| | | С инклюдом проще, но это обращение к файловой системе при каждой интерации цикла. А функция эта по сути эмулятор инклюда. То есть файл шаблона считывается единожды, а потом берется из оперативки, не насилуя диск. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(12.01.2010 в 19:24)
| | | >>но это обращение к файловой системе при каждой интерации цикла.
если файл один и тотже, при каждой ли?
upd
к тому же, если цикл перенести в шаблон, инклуд будет только один раз. | |
| |
|
|
| |
|
|
| |
для: @ndry
(12.01.2010 в 00:50)
| | | >>
>В вашем подходе да, но вы фактически даёте лишь доступ к переменным, но не методам их обработки (методы PHP означают необходимость в знании хотя-бы основ PHP).
А нафига верстальщику способы обработки? Это его забота? Наобрабатывал уже один так, что вообще всё работать перестало... | |
| |
|
|
| |
|
|
| |
для: Николай2357
(12.01.2010 в 00:46)
| | | я называю шаблоны СМАРТИ шаблонами смЕрти ;) | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 17:40)
| | | Звучит как бред. MVC-то тут вообще при чем? | |
| |
|
|
| |
|
|
| |
для: Loki
(11.01.2010 в 17:48)
| | | Ну как причем... Очень даже причем. При том что одна точка входа, один коммутатор, который переключает контроллеры. То есть если напали на этот индекс, хоть тресни - ничего не сделаешь.
А если схема модульная и адреса до директорий (модулей) не виртуальные, а реальные, то и не бред вовсе, а проверенная практика. Очень даже помогает. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 18:03)
| | | Всё-равно звучит как бред, отсутствие MVC к нагрузкам вообще не имеет никакого отношения. У вас в любом случае будет одна точка входа, если вы не используете несколько серверов. Лучше позаботьтесь о защите на уровне веб сервера (nginx может фильтровать флуд) и о толковом кешировании.
В крайнем случае обратитесь в highload lab они бесплатно предоставят вам защиту. | |
| |
|
|
| |
|
|
| |
для: @ndry
(11.01.2010 в 18:20)
| | | Да ёпрст...
и о толковом кешировании.
Вот с этого места поподробнее пожалуйста. Разве я не о том?
Почему меня никто не понимает, может я действительно что то упустил... | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 18:25)
| | | Может вы нас не поняли, смотрите MVC - паттерн разделения всего кода проекта на 3 части: Model (обработка данных), Viev (их вывод) и Controller (контроль процессов). Грубо говоря это лишь значит, что вы используете определённое архитектурное решение те. структуру проекта. Как структура код может повлиять на производительность? В MVC есть масса способов очень красиво всё обставить не прибавляя нагрузки. Никто, например, не запрещает закешировать вывод целиком и пропускать вызов модель когда это возможно. | |
| |
|
|
| |
|
|
| |
для: @ndry
(11.01.2010 в 18:31)
| | | Да не на столько я дуб, чтоб объяснять мне принципы MVC. )))
Да, модель можно обойти, подсунуть кэш. Но делать это будет все равно PHP. А это нагрузка. Кроме того, есть моменты, которые не кэшируются по определению - счетчик посетителей к примеру. И базу тоже дергать придется. Пусть частично.
Все равно, как не крути, придется запускать препроцессор, что бы отработал механизм кэширования.
А по другой схеме проще все - есть к примеру три раздела сайта. Каждый формируется своим модулем. При MVC нужно обратиться на главный индекс, что бы он подключил нужные контроллеры, которые уже решат, что делать дальше. А если каждый раздел представлен отдельным модулем, со своим индексом, то можно просто в модуле заменить index.php на index.html на время атаки. Динамика вся пропадет конечно, но зато все остальные разделы будут работать в штатном режиме. И нагрузка будет минимальна. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 18:44)
| | | > счетчик посетителей
Запросто может работать на кеше с переодическим переносом в базу.
> Да, модель можно обойти, подсунуть кэш. Но делать это будет все равно PHP. А это нагрузка.
В любом случае это одно и то-же, просто код в моём варианте более удобен для поддержки. PHP будет работать в обоих случаях одинаково, уж поверьте.
>А по другой схеме проще все - есть к примеру три раздела сайта. Каждый формируется своим модулем. При MVC нужно обратиться на главный индекс, что бы он подключил нужные контроллеры, которые уже решат, что делать дальше. А если каждый раздел представлен отдельным модулем, со своим индексом, то можно просто заменить index.php на index.html на время атаки. Динамика вся пропадет конечно, но зато все остальные разделы будут работать в штатном режиме. И нагрузка будет минимальна.
Используйте nginx, он сам это сделает встроенным механизмом кеша что выйдет намного быстрее (не будет обращения к диску, страница будет в оперативной памяти).
А что касается именно вашей методики, то это в раной степени реализуется и при работе с паттерном MVC. Его всё-равно никто в чистом виде не использует.
Делается это просто (как я вижу, сходу, решение одно с многих):
1. Вы в конфиге апача указываете, что HTML файлы будут иметь больший приоритет в чпу (те если файл существует, то бросаем клиент на него, если нет - переадресовываем в основной скрипт).
2. Скрипт отслеживает нагрузку, как только фиксируется увеличенный поток запросов он тут же генерирует HTML страницы сайта (на них по пр. 1 будут попадать пользователи).
3. При любом изменении данных POST запрос может слаться основному скрипту и он будет ребилдить кеш, соответственно динамика не теряется. Нужно только защититься от HTTP флуда на добавление данных, это просто.
С подвязанным nginx в такой схеме сайт будет просто летать, уж поверьте. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(11.01.2010 в 18:03)
| | | Балансировка нагрузки вебсерверов не имеет отношения ни к шаблонизаторам ни к программированию вообще. Это чисто серверная задача и зачем Вы ее сюда приплели я не понимаю. | |
| |
|
|
| |
|
|
| |
для: Loki
(11.01.2010 в 20:29)
| | | Вообще то я к шаблонам её и не приплетал. Вопрос был про паттерн MVC. А то, что нагрузкой занимаются админы мне очень даже известно. Именно с их подачи у нас и был реализован модульный механизм.
Я кстати не стал продолжать обсуждение, хотя имею что сказать. Именно потому, что это оффтоп. | |
| |
|
|
| |
|
|
| |
для: nikita2206
(07.01.2010 в 01:23)
| | | Ок, исправляюсь
<?
function set_value($key,$var)
{
$key = '{' . $key . '}';
$this->values[$key] = str_replace('{','{',$var);
}
|
| |
| |
|
|
| |
|
|
| |
для: angelcorpc
(06.01.2010 в 14:46)
| | | 1) спор о том, делать шаблонизатор или писать код напрямую, считаю глупым: каждый др...ет как захочет.
2) вставки типа {TITLE} могут вызывать проблемы, если на странице присутствует яваскрипт с if(){} и т. д.
3) Мне кажется более разумным делать вставки как <!--var--> тогда даже при открытии страницы просто с диска, она не искажается никакими кодами.
4) реализацию переменных в итоговой странице считаю лучше всего делать таким образом:
$search=array(
'<!--var1-->',
'<!--var2-->',
'<!--var3-->',
'<!--var4-->',
'<!--var5-->',
'<!--var6-->'
);
$replace=array(
$var1,
$var2,
$var3,
$var4,
$var5,
$var6,
);
$text=str_replace ($search,$replace,$text);
При этом, вместо $var1 может быть "что-то", или function1(), или что угодно.
При таком подходе интерпритироваться будут только заранее предопределенные метки и, например <!--Rating@Mail.ru counter--> не будет пытаться разименоваться как специальная переменная шаблона. | |
| |
|
|
|
