Smarty - код в переменной

[t3[0one]]

Smarty - код в переменной

В переменной загружен смарту код.
Когда я вствлю эту переменную в шаблон то этот код просто отображается а не работает как смарту код . Есть решение этой проблемы?

 

[tony2001]

да.
решение - не делать так.

теперь объясни какую задачу ты решаешь таким образом и тебе подскажут как решить её проще.

 

[t3[0one]]

я сначало собераю все нужные маленькие шаблоны в нужном порядке в эту переменную в итоге у меня получается один большой шаблон каторый мне нужно вставить в осной шаблон

 

[tony2001]

а почему нельзя инклудить в шаблон другие подшаблоны?

 

[t3[0one]]

потому что эти шаблоны всегда меняются ... не всегда загружается один и тот же )
Допустим блок логина пользователя ! для него загружается один шаблон .когда вы залогенились вместо него загружается уже другой шаблон ! и что бы не засорять основной шаблон смарту кодом и что бы шаблон был максимально пахож на чистый HTML я делаю вот так . Но я первый раз работаю со Смарту может я упускаю какие то возможности смарту класса )

 

[tony2001]

делаешь один шаблон, в который инклудишь более мелкие в зависимости от установленных переменных в шаблоне.
и никаких динамических шаблонов не надо.

 

[t3[0one]]

спасибо !!

 

[Demiurg]

и кстати, smarty читается как смарти

 

[Altex]

Я написал плагин к смарти (в соответствии с мануалом) чтобы переменная с шаблоном (кодом) смарти работал как обычный файл с шаблоном. Если надо - поделюсь.

tony2001
Мне немного не понятно почему ты так категорично говоришь, чтобы так не делали. Я понимаю что есть прямой ответ, а есть правильный, и возможно ты как старожил даёшь именно правильный ответ, но лично в моей практике встречался случай когда все(!) шаблоны были в переменных и проще было написать плагин для их подключения в смарти. В частности переделывать всю CMS былобы затратнее (и в конечном итоге не выгодно экономически), несмотря на то, что это возможно было бы правильнее.

Спасибо.

 

[tony2001]

>лично в моей практике встречался случай когда все(!) шаблоны были в переменных
>и проще было написать плагин для их подключения в смарти. В частности
>переделывать всю CMS былобы затратнее (и в конечном итоге не выгодно
>экономически), несмотря на то, что это возможно было бы правильнее.

не надо путать человека.
по всей видимости из-за недостатков в архитектуре твоей CMS тебе пришлось делать это так.
у него таких недостатков (скорее всего) нет, как и самой CMS, поэтому я не вижу причин решать задачу ректальным способом.

 

[Frol]

Altex
а разве смарти не имеет уже встроенных возможностей?

 

[Altex]

Frol
Встроенные возможности смарти имеет

tony2001
Я не хочу никого запутать, а хочу сам разобраться. Это был вопрос лично от меня лично тебе. Спасибо за ответ.

 

[Demiurg]

Altex
объясни, как шаблоны оказались в переменных, и почему это оказалось лучшим выбором.

 

[tony2001]

Altex
разговор о том, что из всяких правил есть исключения.
но они подтверждают правила, а не опровергают.
не за что, собственно.

 

[Altex]

Demiurg
Дело всё в том, что изначально система не поддерживала столь развитую систему шаблонов и применялись приметивные замены вот таких вставок [param], поэтому никто не задумывался где хранить шаблоны. Это явная ошибка проектирования так как понятное дело шаблоны нужно хранитьв файлах, так их и редактровать проще.

Но на той стадии ещё не было введено в систему такого понятия как смарти шаблон, а был приметивный шаблон с включениями тех самых вставок, и хранились они в свойствах объектов (которые в свою очередь были экземплярами классов плагинов, на которых посроена CMS / а может её можно назвать и CMF, но не об этом речь) и затем в сериализованном виде попадали в базу данных.

Когда страница загружалась, то соответствующий объект (ну который и должен на этой конкретной странице показываться) доставался из БД и разсерализовывался и запускался метод этого плагина, возвращаемый результат которого и попадал на выдаваемую затем в виде HTML-кода страницу.

В этом методе и происходили все необходимые операции с шаблоном, другими входными данными и так далее, тоесть обычная работа бизнес-функций. И в конечном итоге когда был сделан переход на Смарти, то было написано много всего, и нужно было быстро перевести систему к единому стандарту шаблонов, используемых в плагинах, но у нас были лишь переменные с шаблонами в них. Соответственно переделывать систему отлодили на более свободное время и, воспользовавшись мануалом по смарти, легко написал плагин для него, который парсит шаблон из переменной. Вполне логично и корректно работает до сих пор.

Один из следующих этапов неменуемо будет перенос шаблонов в файл. Опять же замечу, что на тот момент этот шаблон по сути не был шаблоном а лишь "опцией", коих были кучи, тоесть часть входных параметров плагина были выполнены на одной странице, где одним из полей был и шаблон. Лишь через несколько месяцев было переделано и разделены параметры и настройки от шаблонов (что позволило разделить и права доступа, но это к слову).

 

[nw]

К слову сказать. Насколько плохим будет вариант, если не в шаблоне делать условия показа того или иного блока (посредством инклудов), а с помощью fetch() из PHP-скрипта. Понятно что это разные вещи, но в некоторых случаях с их помощью можно решить одну задачу. Пример:

if ($a == "b") 
{ 
    $tpl_source = $smarty->fetch('one.tpl') 
}
else 
{
    $tpl_source = $smarty->fetch('two.tpl') 

}
$smarty->assign("TEXT",$tpl_source);

Под вопросом "насколько плохим..." я подразумеваю, "могут ли быть подводные камни"?

 

[Мутник]

nw

насколько я заметил, твой показанный пример будет работать быстрее, т.к. смарти-код то еще должен быть обработан в пхп, а пхп должен быть и сам обработан.

Т.е. при больших объемах инфы, наверное, будет заметнее...

да и удобнее ведь не в шаблоне такое условие с кучей ифов писать,а подгружать уже нужное, не так ли?