данные не придут тогда, когда ты их туда не передашь. Другого варианта нет. Ещё раз: парсим шаблон — да, выводим данные — да, принимаем от скрипта данные — да. Отладка приложения на уровне шаблона — нет. Единственное, что в этом смысле позволено делать в шаблоне — это: PHP: <?php if(is_set('row')):?> покажем чего хотели <?php else:?> ой, блин, а никого нет дома <?php endif?> а разбор и логирование того почему произошло так, что is_set('row') == false — это задача совсем другого куска кода. Ещё раз: шаблон показывает, а не контролирует.
А чего там отлаживать? К примеру, когда переменная неожиданно окажется пустой HTML: <span><?php echo $var?></span> PHP: $tpl -> var = mysql_fetch_row($res, 0); // вылетит ошибка в этом месте, если данные не пришли или PHP: $tpl -> var = file_get_contents('file.html'); // вылетит ошибка если файла нет или PHP: $tpl -> var = $array['var']; // если нет такой пермеенной, то нотис и так тут вылетит единственная возможная ошибка, которой не будет в логах - программист забыл присвоить переменной значение.
не лезь, если не умеешь читать. Еще раз. В вашем случае он вообще ничего не показывает. Он тупо выводит пустое место. PHP: <?php echo $this->undefined; // я получу нотис function get($varname) { return isset($this->{$varname}) ? $this->{$varname} : ''; } echo get('undefined'); // а дульки мне, а не нотис в логи. Еще вопросы?
читать то я умею. Тут размером h1 вопрос тебе ставится - ЗАЧЕМ НОТИС В ШАБЛОНЕ? get('undefined') да, не вызовет ошибки, но если была неудачная попытка определить переменную, то ошибка и так вылетит в месте определения.
PHP: <?php $parser->set('var',$var); // нотис ещё до начала парсинга ;) ?> теперь твоя очередь привести вариант штатной ситуации, когда переменная была задана, но не дойдёт до момента вставки в шаблон
[vs] школьники курят пока в сторонке. Я закончу беседовать, и только потом буду заниматься просветительской деятельностью с тобой. Не-не, не уважаемый. Это ваш метод get() для не заданных переменных. И родился он в вашем коде - а посему это ваши проблемы, где оно у вас возникает. Я фантазировать на этот счет не собираюсь. Если же у вас все переменные в шаблоне определены при помощи $parser->set('var',$var); - то в чем фишка get('var')? Абы було? Ога? P.S. В моем случае происходит инициализация пустых структур, но они валидны и все их свойства defined, а посему и никаких нотисов в шаблонах вызвать не могут, и буде вкрадется ошибка, то я это залогирую, поскольку не занимаюсь маскировкой ошибок.
уже фантазируешь. Не я же про недошедшие данные и несуществующие нотисы начал Если бы get() брало значение из глобального пространства переменных, то да, была бы проблема. Так как мы работаем с конкретным массивом данных, который сами же сознательно и заполняем, то о каких нотисах и неконтролируемых ошибках может идти речь? Вот честно, не понимаю. Мы задали, мы получили. Это как если бы говорить про код PHP: <?php $vars = array(); $vars['var'] = 'val'; $param = $vars['var']; // … echo isset($param)?$param:''; ?> «из-за isset() мы не можем гарантировать, что $param существует и что-то содержит, а это потенциальное место ошибки, потому что потому».
Luge Контрольный в голову. В чем смысл echo get('var'); вместо echo $var какую, нагрузку несет этот вызов?
ууу, началось. В принципе каждый велен делать как хочет, НО я лично убеждён в следующем: я в принципе так и делаю - в шаблонизаторах, на методе __get генерирую исключение, если нет ключа. Не знаю как вы Luge так разбираетесь, что шаблонизатор должен обрабатывать чьи то ошибки забывания передачи переменной в виде возврата пустого значения или еще как то, но это если ключа нет, то это ошибка программиста, как по мне. Да, может вам так и удобнее, но увы, у нас разные взгляды )) Mr.M.I.T. а я так и делаю. Кстати ничего там заумного не надо, просто экшен возвращает представление зоны и всё. Оно так и дёргается - древовидно или даже графовидно.
Костян А мне кажется, что на самом деле никаких проблем такой подход не создает. Наоборот - юзабилити
лучше массив, тк. это универсальный формат данных системы, сокращаем лишние вызовы шаблонизатора плюс получаем абстрагирование вида. тоесть в разных зонах, блок новостей может выглядеть поразному или вообще не быть Simpliest Luge бгг. есть вариант "для всех" error_reporting(E_ERROR | E_WARNING); /*.....*/ print $var; =)
Шаблон не включён в область видимости заполняющего его метода, он просто не знает о существовании какой-то гипотетической $var. Для того, чтобы получить от get('var') какие-то данные их сначала надо определить. Опять же, через get('var') происходит обращение к элементу заполненного нами массива, а не к какой-то переменной в дебрях кода. где-то читал, что обращаться к приватным свойствам класса не получится. Врут?
E_ALL | E_STRICT Конечно врут Ключевая ошибка в PHP: <?php public function __toString() { ob_start(); include $this->template; // $this->var даже для приватных переменных. $return = ob_get_clean(); ob_end_clean(); return $return }
Ещё раз вопрос в зал: зачем шаблону заботиться о типе или наличии даных, которые в него пришли? Это задача и зона ответственности программиста. Самое интересное, что стой в методе get() какое-нибудь PHP: <?php Logger::error('undefined_variable', gebug_backtrace()); die('Ахтунг!!!'); ?> вопросов бы не возникло. А самое смешное, что функциональность с возвращением пустой строки используется только в конечном собирании общего шаблона страницы из уймы мелких.
вот и пускай шаблон разрешит ситуацию и присовит переменной null! Аминь! ЗЫ. Почему делают $var=''; вместо $var=null; если надо просто инициализировать?
да он без проблем присвоит. Дело в том, что будет вопрос, передал ли я туда null в контроллере или туда вообще никто ничего не передал! Вот в этом вся дилема. а у меня вроде массив и потом instanceof-ы всякие, я не помню..., ну массив лучше, да
о, я понял, главное недовольство вызвало get('var') вместо $this->var . Ну, вот такие мы засранцы, не сующие явно объект в шаблон. Про нотисы и их сокрытие лучше давай. Любая переменная приходит из моего же кода, я контролирую что передаётся в шаблон и откуда у нас тут нотис? Будет ошибка — появится ещё раньше, при добавлении. Кстати, в случае с $this->var нотис так же появится ещё до вызова.
Вы не засранцы, это называется несколько иначе Вы просто поимеете анальный секс (или уже поимели) эпических масштабов с областями видимости, когда выяснится что надо иметь более 1го шаблона. Разве? А это зависит от того как использовать. $this->view->payments = $payments; и даже если мы этого делать не будем, то notice - будет отсутствовать ровно до тех пор, пока мы не обратимся к payments внутри шаблона. Причем в вашем случае get('var') А в моем случае будут матюки в логах.
ты рассматриваешь ситуацию, когда $payments в любом случае существует, а с $this->view->payments что-то может произойти и она почему-то не существует (ну, или опечатка какая). Я — совершенно противоположную. Так мы ни к чему не придём. Давай тогда определим: программист подготовил все данные для шаблона, типы данных сответствуют тому, что будет обрабатываться в шаблоне. В шаблоне стоит вывод переменной. При написании переменной программист опечатался и вернулась а) пустая строка вместо массива — ругнётся цикл, который должен работать с этим массивом б) пустая строка вместо строки данных — с нотисом или без него ты увидишь отсутствие нужных данных Так объясни, что же тебе кажется ненормальным и я пойду смотреть кино, как наши солдаты убивают одной пулей сотню фрицев.
как там сейчас не знаю, Psih появится — поправит, но раньше одна страница собиралась из 10-15 шаблонов и проблем с пересечением имён переменных (если ты об этом) не было, хотя в многие шаблоны приходили переменные с именами data или rows.
Если он не существует, то как справедливо ты заметил - ошибка будет до шаблона. в варианте "б" в вашем варианте я не контролирую отсутствие данных. Т.е. я могу думать что угодно и что алгоритм у меня идеальный. Но по факту в рабочем режиме могут быть и будут возникать ошибки, которые программист упустил. Поэтому в моем случае я явно получу ошибку в логе. в вашем варианте - пустое место увидит юзер, а я могу об этом и не узнать. Вот пример ждем Код (Text): $this->user_name as string передали Код (Text): $this->view->name_user = $user_name; И все... приплыли у вас вывелась пустая строка, и это никак не отразилось в логах.
Я же тебя не убежу в высосанности проблемы из пальца? Проблемы связанные с пользовательским вводом отсеиваются на этапе обработки данных, проблемы получения данных из потока или базы — зона ответственности интерфейса работы с потоком, опечатки и отсутствие данных — ты сам увидишь проблему при первом же пробном запуске скрипта. Если происходит исключительная ситуация, достойная фиксации в логи, то это должно быть обработано задолго до шаблона. А опечатки и забывчивость — что ж, и такое бывает, но такие ошибки отсеиваются элементарно.