Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 93
Ну, метод явно имеет место быть. Но по первому впечатлению это весьма специфичный «фреймворк», так скажем. Оттого и короткий. На вид. Просто ведь тут у вас выложен сам «роутер», а к нему ещё прикручен немаленький шаблонизатор, который берёт на себя всю генерацию выхода и разные контроллеры, которые берут на себя всю логику. Так что минимализм — это по большей части оптический обман :)
Да, по замыслу, в этом фреймворке могут использоваться любые шаблонизаторы, API c SQL, движки Javascript. Чтобы не переучиваться :) Все-в-одном не всегда есть гут.
Ну, так я к тому и говорю, что это не «фреймворк», а всего лишь крошечная (хотя и центральная) часть большинства фреймворков — маршрутизатор :)
Странно, что мало кто работает на уменьшение кода, обычно код фреймворка все время увеличивается, вбирая в себя мелкие велосипеды, 50% из которых никому не нужны. Почему никто не скажет — довольно, хватит палить из пушки по воробьям, давайте сделаем лайт версию нашего монстра, а остальное по мере надобности подключат плагинами?
Возьмите любого монстра; отключите то, что вам не нужно; получайте лайт версию!
Это был больше аргумент в защиту компаний, которые не занимаются выпуском каких-то лайт версий.
В том и дело что я видел что там внутри. Например это:
— <td class="<?php echo implode(' ', $classes) ?>"><span class=«day»><?php echo $day[0] ?></span><?php echo $output ?></td>
— и это
— // Load the session
$query = $this->db->from($this->table)->where('session_id',$id)->limit(1)->get()->result(TRUE);
— и это
— $stmt = $this->db->prepare(«SELECT `t`.`title`, `v`.`name`, `ts`.`id` AS `type_id`, `ts`.`name` AS `type`, `ts`.`title` AS `typetitle`,
IFNULL(`val`.`value`, `val_def`.`value`) as `value` FROM `sys_cfg` `cfg_def`
INNER JOIN `sys_cfg_values` `val_def` ON `val_def`.`cfg_id` = `cfg_def`.`id` AND `cfg_def`.`section` = 0
LEFT JOIN `sys_sections` `s` ON `s`.`name` = :section
LEFT JOIN `sys_modules` `m` ON `m`.`name` = :module
LEFT JOIN `sys_cfg` `cfg` ON `cfg`.`section` = `s`.`id` AND `cfg`.`module` = `m`.`id`
LEFT JOIN `sys_cfg_values` `val` ON `val`.`cfg_id` = `cfg`.`id` AND `val`.`name` = `val_def`.`name`
INNER JOIN `sys_cfg_vars` `v` ON `v`.`id` = `val_def`.`name`
LEFT JOIN `sys_cfg_titles` `t` ON `t`.`id` = `val_def`.`title`
LEFT JOIN `sys_cfg_types` `ts` ON `ts`.`id` = `val_def`.`type_id`
WHERE `cfg_def`.`module` = `m`.`id`»);
— <td class="<?php echo implode(' ', $classes) ?>"><span class=«day»><?php echo $day[0] ?></span><?php echo $output ?></td>
— и это
— // Load the session
$query = $this->db->from($this->table)->where('session_id',$id)->limit(1)->get()->result(TRUE);
— и это
— $stmt = $this->db->prepare(«SELECT `t`.`title`, `v`.`name`, `ts`.`id` AS `type_id`, `ts`.`name` AS `type`, `ts`.`title` AS `typetitle`,
IFNULL(`val`.`value`, `val_def`.`value`) as `value` FROM `sys_cfg` `cfg_def`
INNER JOIN `sys_cfg_values` `val_def` ON `val_def`.`cfg_id` = `cfg_def`.`id` AND `cfg_def`.`section` = 0
LEFT JOIN `sys_sections` `s` ON `s`.`name` = :section
LEFT JOIN `sys_modules` `m` ON `m`.`name` = :module
LEFT JOIN `sys_cfg` `cfg` ON `cfg`.`section` = `s`.`id` AND `cfg`.`module` = `m`.`id`
LEFT JOIN `sys_cfg_values` `val` ON `val`.`cfg_id` = `cfg`.`id` AND `val`.`name` = `val_def`.`name`
INNER JOIN `sys_cfg_vars` `v` ON `v`.`id` = `val_def`.`name`
LEFT JOIN `sys_cfg_titles` `t` ON `t`.`id` = `val_def`.`title`
LEFT JOIN `sys_cfg_types` `ts` ON `ts`.`id` = `val_def`.`type_id`
WHERE `cfg_def`.`module` = `m`.`id`»);
Судя по запросу (да и вообще по приведённому куску кода) вы копали уже CMS.
это вырезки из Kohana и mzz. Валялось на винте просто… :)
Какой вы посоветуете фреймворк?
Какой вы посоветуете фреймворк?
Мне нравится Zend, но я могу быть субъективен в своих оценках =). Нравится он главное образом тем, что библиотеки можно без проблем использовать без предложенной реализации MVC, если не устраивает её тяжеловестность или что-то другое.
Понравился Symfony, а вот Kohan'y не смотрел. На мой взгляд фреймворк не должен быть связан с какой-то структурой базы (это же не CMF или CMS). Будет обидно, если запрос из Kohana, ведь судя по отзывам грамотная вещь!
Понравился Symfony, а вот Kohan'y не смотрел. На мой взгляд фреймворк не должен быть связан с какой-то структурой базы (это же не CMF или CMS). Будет обидно, если запрос из Kohana, ведь судя по отзывам грамотная вещь!
я говорю о перемешивании кода HTML с <?php echo. От этой парадигмы отказались еще в начале века.
Нет в этом ничего страшного, поверьте. Главное правильно разделять логику шаблона и и всё остальное. Любой шаблонизатор ставит для нас жёсткие рамки, но можно просто использовать мозги и не разрешать себе лишнего в шаблонах. А как будет выглядеть цикл: {foreach from=$items item=item} иди <?php foreach ($items as $item) { ?> — не так уж важно.
простите, он же весит под 15МБ, да еще библиотеки эти… Можете на глаз сказать сколько метров кода реально проходит через парсер php при одном вызове среднестатистической странички?
Не весь же фреймворк одновременно проходит через интерпретатор. А потом не стоит экономить на спичках: не такая уж большая разница по времени будет между интерпретацией 10 строк и 1000 строк сравнивая со временем выполнения одного запроса к базе.
вы меня не поняли, сори. Я говорю о крупных проектах, которые занимают 1Мегабайт целиком, а вы мне про 15 мегабайтный фреймворк, на котором еще библиотеки, да еще надо писать логику программы сверху на этом всем. Вы разницу себе представляете?
Вы тоже поймите, что фреймворк весит 15 мегабайт, а используется в проекте из всего этого только 100-200Кб. Остальное просто лежит на диске.
Не верю! — фраза, ставшая популярной в мире кино, театра и в бытовой сфере, после того, как её стал употреблять в качестве режиссёрского приёма Станиславский.
Вы говорите о том, что вызывается всего 1-2% из фреймворка, и у меня нет оснований вам не верить (я не работал с этим фреймворком).
Теперь СТОП, вы абсолютно правы!!! Реально запускается 100КБ, а если еще покопаться? Может быть выяснится что из этих 100 нужно всего лишь 10? :)))
Вы говорите о том, что вызывается всего 1-2% из фреймворка, и у меня нет оснований вам не верить (я не работал с этим фреймворком).
Теперь СТОП, вы абсолютно правы!!! Реально запускается 100КБ, а если еще покопаться? Может быть выяснится что из этих 100 нужно всего лишь 10? :)))
Закончим этот холивар, друг мой. Те кто понял, связались со мной по icq :)
Вам скажу так — вы правы, правы во всем, абсолютно и бесконечно, космическая правда в ваших словах.
Точка, не надо более дискуссий :)
Вам скажу так — вы правы, правы во всем, абсолютно и бесконечно, космическая правда в ваших словах.
Точка, не надо более дискуссий :)
Вы правы, если тщательно подойти к вопросу, то ~50-60% кода можно убрать без ощутимой потери функциональности :)
В этом и плюс фреймворка, что его можно использовать не полностью, а только задействуя необходимые библиотеки. Вы же предложили по сути свою реализацию, как было сказано ниже, роутера (маршрутизатора). А это лишь одна библиотека.
Абсолютно точно ОДНА! и даже не библиотека, а тупой свитчер. Я согласен, сейчас многие не могут представить себе жизни без класса метра на 3 весом.
Как я объясню что у меня функционал почти весь внутри SQL (в pl/sql), а php используется только для дерганья $db->query(«select
Как я объясню что у меня функционал почти весь внутри SQL (в pl/sql), а php используется только для дерганья $db->query(«select
Согласен, что при таком подходе библиотеки по работе с базой можно отбросить (сам грешен написанием своего «lite» варианта MVC =)). Но теже библиотеки валидации, форм всё равно нужны. И как же модульность?
понятие модульности достаточно абстрактно, я понимаю под модулем логическую атомарную единицу (сущность) с которой можно произвести полный спектр действий insert/update/delete… соотв. за это отвечает индивидуальные плагины, каждый из которых занимается сугубоб своим делом, лишний код не подключается и время на его парсинг не затрачивается. Например, модуль customer — понятно что в нем обрабатывается абонент, а не тарифные планы. Общие валидаторы, типа is_digital, is_email, is_??? у всех одинаковые они везде есть, даже в самом PHP встроено. Некоторые, типа is_ip, is_mac, is_date надо доделать самому (интересно есть подобное в толстых фреймворках?).
Велосипед детектед!
ИМХО без «старения над изучением классов и методов» через некоторое время будем стареть над рефакторингом и расширением, это фреймворк одного-двух разработчиков.
Кстати когда-то, во времена буйной молодости мой коллега «изобрел» именно такой «фреймворк». Там тоже класс и его метод передавались через GET…
ИМХО без «старения над изучением классов и методов» через некоторое время будем стареть над рефакторингом и расширением, это фреймворк одного-двух разработчиков.
Кстати когда-то, во времена буйной молодости мой коллега «изобрел» именно такой «фреймворк». Там тоже класс и его метод передавались через GET…
И да, это не «фреймворк с поддержкой плагинов», это метод «прозрачного» дергания функций из файлов на диске.
«Плагины» будут по прежнему написаны кто-во-что-горазд.
«Плагины» будут по прежнему написаны кто-во-что-горазд.
Ваш топик в несколько раз длиннее фрэймворка. Через некоторое время, когда вам надоест дублировать код и писать велосипеды на каждый чих, ваш фрэймворк обрастёт библиотеками, плагинами, модулями и тд. И тогда он станет настоящим фрэймворком. А будет он хорошим или плохим, зависит от вас.
Ну уж нет. Если его хватило для полнофункционального биллинга, то обрастать ему никак не требуется. Да и зачем? И так хватает всяких монстров, тут уж велосипед действительно не стоит изобретать.
Т.е. эти 50 строк кода мне помогут быстро написать биллинговую систему? Круть!!!
зачем 50? тут 10 строчек, и да, помогут. Какие сложности?
Отделяем сущности (абонент, договор, сервис, гроссбух, оператор, адрес и т.д.),
делаем SQL таблицы (с references по id), триггеры, функции (перекладываем часть логики внутрь БД), и только потом 10 строчек нам начнут помогать загружать плагины customer, service, contract и пр.
А какую методику используете вы?
Отделяем сущности (абонент, договор, сервис, гроссбух, оператор, адрес и т.д.),
делаем SQL таблицы (с references по id), триггеры, функции (перекладываем часть логики внутрь БД), и только потом 10 строчек нам начнут помогать загружать плагины customer, service, contract и пр.
А какую методику используете вы?
как вы будете писать ваши сущности и триггеры? Для каждой сущности писать уникальные классы, валидаторы, хэлперы. Для каждого проекта писать заново функции для работы со строками, БД, xml, изображениями, конфигами и тд? Т.е. всё это как два байта переслать, а вот эти 10 строчек вот это фрэймворк.
Сущности и триггеры описываются мною в Nushpere Phped, разумеется для каждого проекта они разные. В складском учете нет понятий трафика, IP адресов, а в биллинге нет приходных накладных :) Для каждого проекта разные и валидаторы, проверить наличие товара на складе для его расхода и правильность введения IP адреса — имеют мало чего общего, согласитесь.
Для валидации существует в принципе ограниченное число стандартных правил (длина поля, тип данных, проверка на емайл/IP и т.д.). Напишите один класс с 20 правилами, а не 20 классов с одним. Механизм валидации хоть не придется копипастить ;)
механизм валидации есть. Используется в PRE модулях, и да, это 1 класс. Но он пока не стал частью фреймворка. Спасибо за советы, господа, я использую их в развитии фреймворка добавив в него необходимый минимум.
Я говорил про разные проекты:
>> Для каждого проекта разные и валидаторы, проверить наличие товара на складе для его расхода и правильность введения IP адреса — имеют мало чего общего, согласитесь.
>> Для каждого проекта разные и валидаторы, проверить наличие товара на складе для его расхода и правильность введения IP адреса — имеют мало чего общего, согласитесь.
Дык я и говорю — создается класс валидатор, в нем пишутся типовые методы проверки (IP/email/длина/число и т.д.). Далее в любом проекте используется только один этот класс. Если надо расширить его — пожалуйста.
А автор предлагает для каждого проекта использовать свой валидатор (точнее писать каждый раз правила под нужды проекта).
А автор предлагает для каждого проекта использовать свой валидатор (точнее писать каждый раз правила под нужды проекта).
это фреймворк за 5 минут. Это не «аналог зенда иди symfony» за 5 минут. Какой базовый функционал? авторизацию и валидаторы? Ну дак они отдельно. Прилагаются К… А не являются частью…
Сущности и триггеры описываются мною в Nushpere Phped
А фрэймворк ваш, видимо, лежит в папке Framework на диске D:.
Соответственно, URI может быть такой: "/service_edit/123", "/article_new", "/customer_update/10077"
…
Плагины находятся не в корне html, а в “../inc” (расположение их до корневой директории способствует секурности)
Ммм, прям подмывает подсунуть вашему велосипеду что-то в духе "/../../../etc/passwd"… А загрузка файлов есть? :)
Каждый охотник разработчик желает знать куда ставить свой велосипед.
Весьма узкоспециализированный фреймворк получается. Как с БД работать? Кэш? Роутинг вообще жестко прописан и весьма некрасив. Надо расширять фреймворк. А как только он обрастет модулями с требуемой функциональностью, станет достаточно сложным, чтобы программист выбрал один из распространенных FW, который по крайней мере стабилен, предсказуем и подробно описан.
Сорри, не писал систему планетарной обработки данных, поэтому фреймворк можно рассматривать как узкоспециализированный :) С БД можно работать через PDO или тот API, который вам известен. Кеш берет на себя шаблонизатор, может сохранять чистые HTML и вообще не использовать php для рендеринга. Плиз, дайте ссылку на посмотреть где реализация подобного фреймворка красива на ваш взгляд.
При чем тут планетарная обработка данных?
1. Как указать желаемый формат УРЛ?
2. Т.е. с БД работаем напрямую, в каждом контроллере прописываем заново одну и ту же последовательность вызовов…
3. А данные кэшировать не надо?
4. Работа с изображениями как происходит? Капча?
5. Авторизация? ACL?
Я к чему все это пишу — есть перечень стандартных модулей, которые всегда востребованы в проектах. Как только Ваш фреймворк разрастается, он становится ничем не лучше тех сложных проектов, от которых Вы отказались.
PS. Мне нравится Kohana v3, но я не кричу о том, что это совершенный фреймворк ;)
1. Как указать желаемый формат УРЛ?
2. Т.е. с БД работаем напрямую, в каждом контроллере прописываем заново одну и ту же последовательность вызовов…
3. А данные кэшировать не надо?
4. Работа с изображениями как происходит? Капча?
5. Авторизация? ACL?
Я к чему все это пишу — есть перечень стандартных модулей, которые всегда востребованы в проектах. Как только Ваш фреймворк разрастается, он становится ничем не лучше тех сложных проектов, от которых Вы отказались.
PS. Мне нравится Kohana v3, но я не кричу о том, что это совершенный фреймворк ;)
1. Вот так: /объект_действие/<ID> (в случае когда этого мало, можно структурировать его иначе — это зависит от конкретной задачи)
2. С БД работаем через класс DB (который наследован от любого ивестного вам API). В классе DB тоже присутствует диспетчер и мягкие
корректоры данных под конкретную задачу. Понятие «Каждый контроллер» не использую, их один.
3. Надобности кешировать данные пока не возникало. Может это мое упущение… надо будет озаботиться где бы мне это понадобилось.
4. По правде сказать не работал с изображениями… Вероятно в этом плане есть сложности, которые мне пока неизвестны. В качестве капча
берется опять же любой свежий класс, который прошел очередное тестирование на ботов :)
5. Авторизация и ACL — да, это надо будет описать подробнее… хотя, судя по коментам, это мало кому интересно :)
PS Спасибки, изучу на досуге Kohana.
2. С БД работаем через класс DB (который наследован от любого ивестного вам API). В классе DB тоже присутствует диспетчер и мягкие
корректоры данных под конкретную задачу. Понятие «Каждый контроллер» не использую, их один.
3. Надобности кешировать данные пока не возникало. Может это мое упущение… надо будет озаботиться где бы мне это понадобилось.
4. По правде сказать не работал с изображениями… Вероятно в этом плане есть сложности, которые мне пока неизвестны. В качестве капча
берется опять же любой свежий класс, который прошел очередное тестирование на ботов :)
5. Авторизация и ACL — да, это надо будет описать подробнее… хотя, судя по коментам, это мало кому интересно :)
PS Спасибки, изучу на досуге Kohana.
1. О чем и речь, я обязан указывать УРЛ именно в виде объект_действие, а не скажем, объект/действие. Для того, чтобы использовать УРЛ другого вида, мне придется править код фреймворка, так? Некошерно. Не говоря уже о значениях по умолчанию (куда меня отправит роутер при вводе адреса example.com?).
2. Не знаю, что там внутри, но получаем уже дополнительный класс. Скорее всего он тоже в дальнейшем будет расширяться ;)
4. Как только понадобиться зааплодить аватарку или наложить водяной знак — столкнетесь с проблемами :) Опять же, разные капчи будут использовать свои собственные библиотеки для работы с изображениями? А разные плагины?
5. Т.е. оно уже есть? Значит фреймворк еще вырос.
В результате из маленького класса для обработки введенного УРЛа получаем целую систему взаимосвязанных классов. Насколько данная система проще, чем фреймворки? И чем лучше?
2. Не знаю, что там внутри, но получаем уже дополнительный класс. Скорее всего он тоже в дальнейшем будет расширяться ;)
4. Как только понадобиться зааплодить аватарку или наложить водяной знак — столкнетесь с проблемами :) Опять же, разные капчи будут использовать свои собственные библиотеки для работы с изображениями? А разные плагины?
5. Т.е. оно уже есть? Значит фреймворк еще вырос.
В результате из маленького класса для обработки введенного УРЛа получаем целую систему взаимосвязанных классов. Насколько данная система проще, чем фреймворки? И чем лучше?
1. $action изготовляется методом апачевского rewrite. Не вижу смысла менять URI на другой. Если же надо, то правим не фреймворк, а rewruterule в .htaccess. (как-то так ^/(.+?)/(.+)$ /?action=$1_$2)
При отсутствии параметров отправит в «Incorrect action», поскольку $object и $task не определены.
2. Да, функциональные блоки будут расширяться, при этом не затрагивая сам фреймворк.
3. Проследим путь аплоада аватарки.
* $action=«user_update»
* в user.pre.php валидация полей, включая парсинг аватарки (по успеху UPDATE данных в SQL), user.pre.php выходит по exit!
* если все ок, то возвращаем через json result=>success (либо result=>error,avatar=>«ошибка формата»)
* на клиенте подсвечиваем «данные изменены», либо подсвечиваем поле с id=avatar и выводим на нем попап «ошибка формата»
* страница на клиенте не меняется, поскольку через AJAX модуль PRE передал лишь нужный ответ.
** если надо редиректить юзера после аплоада аватарки, то передаем через тот же json redirect=>"/user_show" (ID юзера берем в $_SESSION)
4. Вырос не сам фреймворк, а мясо на его скелете.
При отсутствии параметров отправит в «Incorrect action», поскольку $object и $task не определены.
2. Да, функциональные блоки будут расширяться, при этом не затрагивая сам фреймворк.
3. Проследим путь аплоада аватарки.
* $action=«user_update»
* в user.pre.php валидация полей, включая парсинг аватарки (по успеху UPDATE данных в SQL), user.pre.php выходит по exit!
* если все ок, то возвращаем через json result=>success (либо result=>error,avatar=>«ошибка формата»)
* на клиенте подсвечиваем «данные изменены», либо подсвечиваем поле с id=avatar и выводим на нем попап «ошибка формата»
* страница на клиенте не меняется, поскольку через AJAX модуль PRE передал лишь нужный ответ.
** если надо редиректить юзера после аплоада аватарки, то передаем через тот же json redirect=>"/user_show" (ID юзера берем в $_SESSION)
4. Вырос не сам фреймворк, а мясо на его скелете.
1. Как минимум должны быть дефолтные действия. Ну неприлично в качестве корня сайта указывать example.com/blog/index. Кроме того, маршрутизация в разных модулях (плагинах) может выглядеть по-разному, а в .htaccess так просто не залезешь. Например, захотим мы короткие УРЛ вида example.com/login, как его сделать? Хотя это опять возврат к дефолтным значениям.
2,4. Сам фреймворк — это не только механизм маршрутизации запросов. Это и те самые кирпичики (картинки, БД и т.д.), которые помогают создать работающую систему. Или Вы предлагаете каждому пользователю наращивать мясо самостоятельно? :)
3. Я имел в виду обрезание предложенной картинки, все то же наложение водяного знака и т.д.
Задаю эти вопросы, т.к. интересна позиция «велосипедиста», не подумайте, что придираюсь.
ЗЫ. Отвечайте на комментарий, пожалуйста, а то таким вот образом уведомления не приходят ;)
2,4. Сам фреймворк — это не только механизм маршрутизации запросов. Это и те самые кирпичики (картинки, БД и т.д.), которые помогают создать работающую систему. Или Вы предлагаете каждому пользователю наращивать мясо самостоятельно? :)
3. Я имел в виду обрезание предложенной картинки, все то же наложение водяного знака и т.д.
Задаю эти вопросы, т.к. интересна позиция «велосипедиста», не подумайте, что придираюсь.
ЗЫ. Отвечайте на комментарий, пожалуйста, а то таким вот образом уведомления не приходят ;)
1. Про дефолтовые действия согласен. Можно $object и $task не обнулять, а присваивать им дефолты.
Также маршрутизатор разделен на две части. Это означает что может сработать ПРЕпроцессор одного плагина, а отрисовка будет от другого плагина. Это ключевой момент!
2. Рассматриваю этот фреймворк как фундамент, а будет ли на нем стоянка для автомобилей или небоскреб — это дело кодера. Кирпич ему в руки (одному PDO, Dwoo, JQuery, другому AdoDB, Smarty, Prototype).
3. Это все входит в понятие валидации.
PS Я тут упустил кое-что. Дело в том, что я ~30-50% логики из php вынес в PosgreSQL (plpgsql), фактически, php нужен лишь для того чтобы подготовить данные и сделать $db->query(). Может поэтому мне хватает такого «прозрачного дергателя плагинов» ;-)
Также маршрутизатор разделен на две части. Это означает что может сработать ПРЕпроцессор одного плагина, а отрисовка будет от другого плагина. Это ключевой момент!
2. Рассматриваю этот фреймворк как фундамент, а будет ли на нем стоянка для автомобилей или небоскреб — это дело кодера. Кирпич ему в руки (одному PDO, Dwoo, JQuery, другому AdoDB, Smarty, Prototype).
3. Это все входит в понятие валидации.
PS Я тут упустил кое-что. Дело в том, что я ~30-50% логики из php вынес в PosgreSQL (plpgsql), фактически, php нужен лишь для того чтобы подготовить данные и сделать $db->query(). Может поэтому мне хватает такого «прозрачного дергателя плагинов» ;-)
Я не программист, но мне интересно: почему нельзя писать шаблоны на простом пхп, но при этом отделять их от всего остального?
чтобы не получался код HTML вперемешку с echo и print, которые тупо замусоривают код HTML своими <?php echo или <?= $var. Гораздо проще редактировать чистый HTML без вкраплений логического мусора php.
1. Почему конструкция php — «логический мусор», а конструкция сматри — не мусор?
2. Почему должно быть сложнее редактировать html со вставками на php, чем со вставками на смарти, синтаксис которого еще надо дополнительно выучить?
2. Почему должно быть сложнее редактировать html со вставками на php, чем со вставками на смарти, синтаксис которого еще надо дополнительно выучить?
1. потому что надо взять и посмотреть глазами как выглядит код с перемешкой php и как выглядит ТОТЖЕ код на смарти.
2. см. п.1
PS Смарти не надо, лучше учить Dwoo. Да, минут 15 надо потратить на это «изучение» :)
2. см. п.1
PS Смарти не надо, лучше учить Dwoo. Да, минут 15 надо потратить на это «изучение» :)
«Взять и посмотреть» — это не объяснение.
Чем { if лучше <? if? Что плохого в echo?
Чем { if лучше <? if? Что плохого в echo?
в мусоре в виде "<?php".
и чем больше вставок, тем больше мусора. Проще уже тогда как в посте картинка номер 2. там хотя-бы пробелами код HTML от echo отделили :)
и чем больше вставок, тем больше мусора. Проще уже тогда как в посте картинка номер 2. там хотя-бы пробелами код HTML от echo отделили :)
И что, «мусор» в виде <?php стоит затрат на изучение синтаксиса шаблонизатора и оверхеда на его использование?
То, что я вижу на картинке, написано явно человеком, который не в курсе, что вместо
можно написать
То, что я вижу на картинке, написано явно человеком, который не в курсе, что вместо
...
echo 'строка 1';
echo 'строка 2';
echo 'строка 3';
...
можно написать
...
?>
строка 1
строка 2
строка 3
<?php
...
да, стоит. Хотя бы потому что шаблонизаторы могут СОХРАНЯТЬ чистый отрендеренный HTML и повторно его не будут рендерить и дергать php (типа кеша такого).
Это написано весьма недурными спецами, они поняли что лучше сделать бордюрчик в виде echo ' чем потом разбираться в "<?php. Это вообще-то SquirrelMail
Это написано весьма недурными спецами, они поняли что лучше сделать бордюрчик в виде echo ' чем потом разбираться в "<?php. Это вообще-то SquirrelMail
Это умеют делать специальные кэширующие библиотеки без всяких шаблонизаторов. Разве нужен шаблонизатор, чтобы вызвать ob_start()?
А на «спецов» можно особо не смотреть: внешний вид таблиц у них тоже задан атрибутами, хотя CSS был придуман также очень давно.
А на «спецов» можно особо не смотреть: внешний вид таблиц у них тоже задан атрибутами, хотя CSS был придуман также очень давно.
Ну так почему же эти недурные спецы не использовали шаблонизатор?
SqurrelMail — это что-то, что можно поставить в пример?
SqurrelMail — это что-то, что можно поставить в пример?
они поняли что лучше сделать бордюрчик в виде echo ' чем потом разбираться в "<?php
Так <?php стоят себе отдельно, и не надо в них разбираться. Наоборот, читаемость улучшается, писать меньше.
А вот echo повторяется в каждой строке. И чем тогда «бордюрчик» лучше?
СТОП, хватит. Это уже холивар. Нравится вам echo — супер! Я не возражаю.
Ну где же тут «холивар»? Я задаю Вам вопросы по Вашей позиции, хочу вот какое-то обоснование логическое услышать.
Вы хоть и не программист, но рассуждаете здраво!
поржал, спасибо :)
Обратите внимание сколько людей вам доказывает, что ваша позиция не совсем верная. Ваших сторонников пока не объявилось. Это повод задуматься.
Его объявили не еретиком, а «сильно заподозренным в ереси»; такая формулировка также была тяжким обвинением, однако спасала от костра. После оглашения приговора Галилей на коленях произнёс предложенный ему текст отречения. Копии приговора по личному распоряжению Папы Урбана были разосланы во все университеты католической Европы.
И все таки она крутится :)
И все таки она крутится :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP — фреймворк с поддержкой плагинов за 5 минут