А можно я с глупыми вопросами влезу. =) Программист думает что подготовил и передал все данные в шаблон. Что есть? Шаблонизатор, который при отсутствии переменной пишет на ее место пустую строку. Тогда весь вопрос в том, что когда я вижу пустую строку я не могу знать переменная такая пришла и все в порядке или просто переменной нет и есть ошибка. Как написано выше: весь вопрос в том, что когда я вижу пустую строку я не могу знать переменная такая пришла и все в порядке или просто переменной нет и есть ошибка. Да хорошие тесты покроют эту переменную не пустым значением. Но если шаблон велик, то человеческий глаз банально пропустит ошибку. Да грамотное автоматизированное тестирование найдет ошибку, но велик ли процент людей которые пользуются таким тестированием. PS: Т.е. простой цикл PHP: <?php if($arr=$db->fetchAssoc()){ foreach($arr as $key=>$val){ $tpl->$key=$val; } }?> Должен быть изменен так чтобы: 1)Сообщить что ничего не выбрано. 2)Проверить что все переменные которые он должен заполнить заполнены ? PPS: И совсем глупый вопрос. А какую нагрузку несет "_" в Код (Text): echo _("smth");
если переменная вводится в шаблон для того, чтобы её вывести и мы ожидаем, что она будет выведена, то всё достаточно прозрачно. Разве нет? Твой пример с как раз подходит под вариант с is_set(), который я приводил выше. То, что get() выводит в случае отсутствия переменой пустую строку, не значит что невозможно никак контролировать вывод. И не надо меня на этом ловить. gettext
Дело не в "невозможно". Вот я и пытаюсь понять как контролируется вывод. Глазами человека? Автоматизированными тестами? Что я упустил? Если я ничего не упустил, то получение нотиса надежнее глаз и проще автоматизированного тестирования. А значит мы говорим на тему "у меня работает, мне удобно, не нравиться не ешьте", т.е. спорим о вкусах. =))
покажи мне хоть одну реализацию, которая бы не придерживалась этого принципа кто здесь спорит? Я вообще белый и пушистый и давно всё слил. Обсуждаем проблему, которой не существует. А по поводу реализаций я много раз здесь говорил: «делайте как хотите, пока мне это не доставляет проблем мне пох»
Ну есть еще принцип "у меня работает, мне удобно, не нравиться не ешьте, но похоже у вас вкуснее". Это исключая всякие "у меня не работает..."
Нда, как обсуждалось в части форума для модераторов и админов - твердолобость и неприятие иных концепций отдельными членами форума понемногу убивает сам форум. Между прочим все единогласно согласились. Народ, вы себе выбрали единственный правильный для вас подход и отрицаете все другие. Проблема в этом. Вы упираетесь в то, что если вы забыли присвоить переменную в шаблон - должен вывалится чёртов Notice. Оке, я понимаю зачем это вам нужно. Ситуация другая - вы по ошибке перепутали крест-накрест перепутали присвоения, опечатались или в спешке. У вас обе переменные существуют, никаких Notice не высыпало. Всё ок, делаем работу дальше? У вас получается именно так, нотис для вас индикация что есть ошибка - их отсутствие - ошибок нет. А вот хрен, нужно ещё визуально всё проверить и оттестировать. И ошибку свою вы не найдёте раньше меня, найдём мы её одинаково, с той лишь разницей что у вас возможно будет Notice, а я просто увижу что на странице чего-то не хватило и перепуталось. Как писал Luge, списки всякие и массивы перед обработкой в шаблонах проверяются на существование и если их нету, то это видно моментом. Если тип данных не совпал типа ждали массив, пришла пустая строка - ругнётся foreach что ему дали не то. Не определена была такая переменная? foreach тоже ругнётся. Да, ещё хороший бонус такого подхода в том, что по умолчанию у меня все данные в парсере одноразовые - т.е. удаляются при первом же доступе - экономит память знаете ли прилично, особенно когда большие массивы гонять приходится. К тому же следующий шаблон может использовать опять же то же имя для передачи данных (я обычно юзаю "data") - единообразие в шаблонах и если я что-то забуду передать - у меня никогда не возникнет конфликта имён и не попадут данные предыдущего шаблона.. Если надо живущую всё время переменную - есть флаг соответствующий, а вообще в планах такие переменные перевести на properties объекта parser на __get/__set функционал. В общем откройте глаза и уведите, что мир не единым MVC жив, и что разнообразных подходов море и они не хуже, а может иногда даже и лучше. Я данный подход использую уже на протяжении 4-ого проекта, мне самому этот подход показал мой наставник в своё время, а он с этим подходом не два и не три десятка проектов сделал. В общем там 440Hz номер 2. Спросите 440Hz что он думает по поводу этого подхода, он со мной проработал 5 месяцев, меня он не ругал и ничего не предлагал переделать.
Psih да всё нормально, кому надо тот всё понимает! Ничёго форум не убивает Я допустим высказал своё мнение, но я вполне согласен на ваш с лигу подход. Если надо будет делать так, я буду делать так. Если я буду делать как я хочу, я сделаю с эксцепшеном. Какие проблемы нах? )))
Это не вопрос пальца, это вопрос реального мира. Мира где ТДД практикует только каждый 100й, где возможны деплойменты не до конца оттестированной версии в продакшн и т.д. null и false отлично кастуются в ''. Вопрос неявного приведения там где в этом нет необходимости... он вызывает сокрытие ошибок - для меня это неприемлимо. Даже если, как говоришь ты, этот способ применяется не повсеместно, а лишь на верхнем уровне шаблонов. Единственное место где он нужен - это там где стоит isset (для того чтобы не писать много раз эти конструкции), но в вашем случае это выделено отдельно. Логики я не вижу. А, ну еще как способ доступа к некоему глобальному репозиторию данных, раз уж речь идет не об ООП подходе, и ведь остальное как-то работает (как?) раз эта функция применяется не везде. Но я не должен придумывать для чего это надо. Это, мягко говоря, ваша задача. Вы же сами сказали - если переменной нет - отдать пустую строку. Лажу не пишем? Ок? Логи в идеале должны быть девственно чисты. Но их чистота не гарантирует полного отсутствия ошибок. Нотис - это дополнительная информация о ошибках и потенциальных ошибках. Именно поэтому E_ALL | E_STRICT Да, это не избавляет от тестирования, и не убережет от сознательных диверсий, от проколов в логике и т.д. Но это повышает раскрываемость ошибок. А внятного объяснения необходимости get() в топике не было. Заканчиваем верить в собственную непогрешимость. Все делают ошибки. "Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) пофиг кто. Феерично. Если у нас еще и шаблоны начинают передавать данные. (точно для передачи? может для получения?) При таком расхождении с логикой...(нет, придумать как будет работать даже такой код - я могу), но я, пожалуй, пас. Если у Luge будет что сказать - то обсудим. А с остальными "гуру" я завязываю. Мне жалко мою психику маньяка-психопата склонного к насилию.
Simpliest Поправочка - следующий шаблон, который будет выводится, может вполне ожидать данные для себя под тем же именем, что и пред идущий шаблон, который парсился до него. Учитывая, что каждый модуль сам по себе, это вполне нормальная ситуация. Учитывая кол-во шаблонов (коих насчитывается больше 400 штук и растёт дальше), выдумывать для каждого уникальный префикс, под которым передавать данные, смысла не не вижу. Читайте не так прямолинейно, а в контексте. Мы же всё же не сочинения пишем и иногда не совсем ясно излагаем мысль. Переспросили бы что-ли... Про непогрешимость опять читаете так, как хочется вам. Видно сразу, это значит что ошибки эти всплывают при первых же тестах и исправляются ещё до того, как код тестируют другие. По крайней мере большая часть. Про null и false я понятным языком написал, что в этих случаях данные в шаблоне обрабатываются с должной тщательностью. А вообще я не допускаю что бы эти значения попадали в шаблоны, т.к. они не имеют там никакого смысла. Я стараюсь всегда следовать методу, что я либо данные устанавливаю когда их нужно вывести (о наличии данных заботится код модуля), либо я просто не устанавливаю переменную в парсер. Дальше в шаблоне просто проверка на is_set('name'). Смотрите немного шире чем шаблонизатор, суть то в общем подходе. Вырванный из контекста винтик, он и есть ни на что не способный винтик, ему нужна хотя бы гайка, что бы он мог что либо удержать привинчиным. Система строится из общего подхода, это совокупность её компонентов, которая заставляет всё это работать. А возьми любую её часть и скорее всего она не будет уметь половины из того, что она позволяет делать в купе с остальными частями. Важно не только то, что умеет сам шаблонизатор и как, но и как он используется. Вы использование моего шаблонизатора подводите под свои идеалы и то, как вы работаете со своим. Вот здесь вы допускаете ошибку и не способны увидеть всё с другого угла - уперлись в свою накатанную дорожку и всё. Я же вас не критикую, я даже на оборот сказал, что я вас понимаю и вижу почему вы делаете именно так (и со Smarty плотно были знакомы, и с replace шаблонизаторами, и с Savant игрались). А вы меня понять не хотите, твердите своё, считая, что я ни хрена не понимаю. А уж про непогрешимость, чур вас! Вы в сказки верите, если считаете что я тут сижу, пишу это сообщение и уверую в то, что я написал его без ошибок, и код я пишу точно так же - с первого раза и без ошибок. Да вы, батенька, прям расист какой-то. Сделали из меня арийца какого-то. Вот что - заканчивайте с голословными оскорблениями, мать вашу! Я нормальный, ошибающийся, человек. Я пишу код так же с ошибками, у меня вылезают баги, иногда много, иногда на удивление работает с первого раза. Это всего лишь значит что у меня накопилось опыта и выработалась система, при которой я пишу относительно не глючащий код. По крайней мере серьёзных багов стало гораздо меньше, чем когда то.
жаждю деталей как при должном контроле данных может образоваться нотис. Причём такой, что его последствия можно отследить только по логам (не применимо к какому-то решению, а, хотя бы, в общем). Остальное не интересно по причине бессмысленного переливания из пустого в порожнее и мерения пиписьками.
Где я должен был увидеть общий подход на примере вырванного из контекста куска кода? Я 3-5 сообщений подряд не был даже уверен, что правильно понял, то что цитировал. И все ждал - когда же мне скажут - "нет, ты ошибся оно не для этого". Не сказали... Чего мне теперь думать? Для рассмотрения архитектуры и правильности какого-то конкретного решения в ее рамках... тут 5ть строчками сообщения, получасом времени и парой 100ен строк кода на форуме не отделаешься. Поэтому работаем с тем, что есть(дали). Йо, да скажите что get() используется для доступа к какой-то области, где лежат текущие переменные шаблона - и вопросов нет (хотя вру - есть, непонятно почему тогда используется не везде). Более того, я вполне даже допускаю поведение (вокруг которого весь спор) ... в проектах с несложной логикой или так называемых хайлоадах, где каждая ошибка буквально выпрыгивает и моментально сказывается на работе. Но это частные случаи. Если это про меня - то это фантастика (replace и zend_view - и все). Я не профессиональный программист. И 5-10 лет опыта хороших программистов полностью не заменишь никаким умом и интуицией, но отчасти компенсировать - можно. А опыт работы, когда код комитится чуть ли не сразу в продакшн - кого угодно сделает параноиком и расистом.
тогда совсем не интересно, так мы придём к ситуации, что надо всё время ходить под зонтиком — птицы же гадят Всё, упёрся, теперь фиг что докажете. Вот вам лучше перл из одного супер шаблонизатора: PHP: <?php //clear all not replaced values $result = preg_replace("'{.*?}'si","",$result); ?>
Ну я отписал пост, уехал гулять на природу, вернулся 6 часов спустя, если не больше Естественно я _не_ отвечал. Форум же, не чат Общий подход в том куске кода, что я выложил. У меня весь остальной код модулей написан так же, с вариациями на тему сложности этих самых списков. Костяк везде одинаков, тютелька в тютельку. Ну get именно так и юзается. По большей части да, мы находимся в нутри области видимости шаблонизатора. Да вот только данные хранятся не в properties, а key => value масиве. Вы бы хоть код разобрали, там 5 чёртовых методов по 5-10 строк, а get функция используется для того, что бы не писать $this->get('name') а сократить до get('name') и т.к. функция имеет глобальную область видимости, так удобнее и не накладывает никаких ограничений на использование парсера. Про смарти & co это я про себя. Вы? Параноик? Да я уже 4 года один проект поддерживаю, у меня правка и тестирование кода на Live прямо. Так что не будем про это, у меня вообще должно быть "Вот тааакие медные яйца!" © Полицейская Академия, номер части не помню уже. Так что я вообще нацистом должен быть
главный вопрос в том, как эта функция будет генерировать html. А еще как быть с кешированием - пускай оно будет в шаблонизаторе, или пускай контроллер куда хочет сам сохраняет html. Вот ты "дружбой" уже - не?
это не вопрос для топика и быть не может. это решается в конкретных условиях, конкретного проекта. потому что в топике его однозначно решить нельзя не. хотя дружба тож переписана есть. ща я на BestNATIVE с поддержкой участкового кеша хотя вообще забавно всё. кто же win? ставлю на себя Simpliest а если вот метеорит на серверную упадёт и логи пропадут? как ошибки искать тогда...
Насколько я понял get используется для каждой переменной. То что без get либо из foreach пришло, либо ранее get'ом взято, либо просто текст.
вопрос топика и вообще раздела - конкретные реализации. Поделись кэшированием, интересно же) Ставлю что win - точка зрения, что Notice: undefined variable в шаблоне лишнее. По крайней мере моя точка зрения, с которой начался этот холивар, теперь оказывается подтверждается 4-х летней работой совсем не маленького портала) Кстати, ты тоже писал, что шаблонизатор должен просто отдавать html.
нельзя дать конкретный ответ на неконкретный вопрос. этих реализация столько можно нариализовывать, что о-го-го. всем не угодишь. вот если бы я выложил кеширование, обязательно появился бы тот кто сказал бы, что вот тут не так, а тут надо по-другому. а вот если бы была конкретная задача, я бы мог его послать нафиг =) у меня точка зрения такая: мне вообще параллельно есть там нотис или нет. потому что если мне надо будет нотисы, они там будут, если нет, то нет.
Я так понимаю вопрос следующий: что делать если переменная шаблона не установлена (=== null), неправильно установлена (===false) или вообще не определена. Решение предельно простое: - выводим пустую строку для тех данных которые могут быть не инициированы, как например данные формы - выводим сообщение типа: "запрашиваемая вами информация в данный момент не доступна..." для тех данных, которые пользователь заведомо ожидает - проверку того, получены ли null или false вместо ожидаемых данных можно осуществлять дважды: - первый раз вне класса шаблонизатора, до того, как переменным шаблона начнут присваиватся значения, потому что внутри класса шаблонизатора заведомо неизвестно что за данные и какое сообщение необходимо выдать (или вообще не нужно ничего выдавать) - второй раз внутри класса шаблонизатора: если $var===null или $var===false то $var=""; (конечно если в этом есть реальная необходимость)
Я оптимизировал свой шаблонизатор, теперь он весит 78 строк при немного большей функциональности. Никакого кэширования и компиляции, всё просто - говорим шаблонизатору какой шаблон скушать и чего в нём заменить на заранее подготовленный контент.
мое кунг-фу сильнее твоего: PHP: <?php $replaces = array('%name%' => 'Hight', '%time%' => time()); $template = 'templates/main.template.html'; echo str_replace(file_get_contents($template), array_keys($replaces), $replaces); ?> Заметь, весь заявленный тобой функционал уложился в 3 строки.
флоппик Да, смысл такой. Но это ты концепцию показал, принцип. Сам же понимаешь, что у меня этим дело не ограничивается