Переменные, которые являются членами класса, называются "свойства". Также их называют, используя другие термины, такие как "аттрибуты" или "поля", но в рамках этой документации, мы будем называть их свойствами. Они определяются с помощью ключевых слов public, protected, или private, следуя правилам правильного описания переменных. Это описание может содержать инициализацию, но инициализация должна применяться для константных значений - то есть, переменные должны быть вычислены во время компиляции и не должны зависеть от информации программы во время выполнения для их вычисления.
Короче говоря, так делать нельзя, массив сессии не удовлетворяют этому требованию.
_Dark_ при этом ты выводишь все все в браузер
а у меня формируется строка и выводится последним действием в точке входа
Да, но у меня принято выводить все в браузер последним действием, после того, как все отработало, да и буферизацию никто не отменял.
LIME пишет:
ну что за чушь
LIME пишет:
есть что-то сказать кроме пустых слов?
В общем, мне надоело, да и занят я, поэтому от этой темы я отхожу.
За диалог спасибо, но лучше str_replace в while не делать, не говоря уже о написании своего шаблонизатора на языке, который изначально разрабатывался шаблонизатором (хотя это вообще никакой аргумент, но для вида сойдет)
Я не думаю, что есть разница в читаемости, а современные IDE отлично дополняют PHP код, при этом мы избавились от не нужного str_replace, тем самым сэкономив память и время.
а я думал очевидно что код ужасен
почему ужасен????
есть что-то сказать кроме пустых слов?
Да, этот код ужасен, мне он не нравится, хотя бы потому что замена тегов в цикле вывода не самая лучшая идея (Добавление)
LIME пишет:
каких??? прям одни загадки)))
Это моя ошибка, общаюсь с тремя разными людьми на разные темы, немного не переключился с одного контекста на другой. (Добавление)
И вообще, эта тема чревата очередным бессмысленным спором, в котором каждый останется при своем мнении.
Шаблонизатор как гарант того, что во вьюху не переползёт бизнес-логика.
Т.е. если шаблонизатор не даёт никаких средств, кроме логики вывода данных и строг в этом плане - это гарантирует, что разработчики не станут пихать в шаблон лишнюю логику или вовсе SQL.
Это очень сомнительное преимущество, т.к. это искусственное ограничение.
При грамотной архитектуре этого не произойдет, а плохо построенное приложение шаблонизатор не спасет.
И да, тот код в вашем сообщении ("модуль использующий шаблон") как минимум ужасен и сравнивать его с кодом выше, а так же с приведенным вами после кодом странно, я даже не буду объяснять почему, очевидно. (Добавление)
esterio пишет:
у меня знакомый верстальщик не знающый ни ПХП ни шаблонизаторы. И когда я ему показал два синтаксиса с шаблонизатором и без, то ему удобней было именно с шаблонизатором
Современная реалия такова, что в профессиональных студиях все верстальщики, которые выполняют непосредственную подготовку дизайна под CMS, знают PHP хотя бы поверхностно.
Заменяет <?= $var ?> на {$var} ? <? foreach($array AS $val): ?> на {foreach($array AS $val)} ?
<? include('file') ?> на {include file='file'} ?
Кому легче становится верстать? То, что верстальщикам — это
LIME пишет:
распространенное неправильное мнение
Покажите мне пример, когда использование шаблонизатора действительно оправдано, оно серьезно упрощает код и ради этого можно пожертвовать производительностью и поддержкой еще одного синтаксиса. (Добавление)
Алексеей пишет:
Может для вас это так, но новичкам, которые не знают даже html, это очень помогает. У меня заказ, создать панель управления для одного сайта, и все уже сделал, осталось решить только данную задачу.
Новичкам как раз лучше не использовать никаких шаблонизаторов.
как я понял, в интерфейсе обявляются "пустые" методы, потом класс описывает этот метод, как его реализовать. и если два класса подключаются к одному интерфейсу, то в обоих классах должны быть абсолютно одинаковые методы?
Объявление методов должно быть одинаковым, а реализация как раз разная.
я не просил загнать данные, это я сам сделал, если без интерфейса, а вот как отредактировать интерфейс не знаю, у меня один и тот же метод из интерфейса, реализуется в двух классах, вычисления разные соотв. и переменные разные.
а если твой ответ, думаешь помог офигенно, то посмотри ответ мелкого, там как раз для чайника всё понятно, раздел на форуме такой, что поделать.
Сигнатуры методов в классе, реализующем интерфейс, должны точно совпадать с сигнатурами, используемыми в интерфейсе, в противном случае будет вызвана фатальная ошибка.
Это так сложно? Я потратил на это около 40 секунд, включая поиск документации на PHP.net. Не умея пользоваться такими банальными вещами как документация языка — у вас большие проблемы будут.