- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
хе-хе. а я наоборот :) освобождает время для "правильной" работы. Особенно, если есть генерация кода - за пару минут можно сделать то, на что раньше уходило несколько дней, а то и недель. А ORM как удобно - прописал связи и можно быстро получать данные не задумываясь о том что за запрос нужно строить.
Ну вот видите, это дело вкуса. Кто-то любит, а кто-то нет :)
Вообще с трудом понимаю, зачем нужны шаблонизаторы?
Зачем мне учить синтаксис шаблонизатора, который имеет ограничения, если я могу выучить синтаксис PHP, который универсален??
Ну допустим я знаю PHP, зачем мне учить синтаксис шаблонизатора, если я могу написать это на PHP?
Двойная работа получается. Я чем учить синтаксис шаблонизатора, выучу синтаксис, ну не знаю, того же Бэйсика. И вместо того, что я буду владеть каким то левым шаблонизатором. я буду владеть Бэйсиком!
Все равно я не понимаю преимуществ шаблонизатора.
Ну ладно... Возможно...
Тут я совсем не понимаю.
Что мешает работать параллельно используя PHP?
Или верстальщик настолько тупой, что не может хотя бы ПОВЕРХНОСТНО разобраться в PHP?
C другой стороны если верстальщик может ПОЛНОЦЕННО работать с шаблонизатором, то это совсем как бы не тупой верстальщик, и без наличия базовых знаний PHP все равно не обойтись...
В нативной верстке мы и так работаем используя минимум 2-3 языка - PHP, разметка HTML (еще часто JS) и тут мы добавляем еще необходимость изучения и использования псевдоязыка шаблонизатора...
Кстати знания JS верстальщику нужны? Или он будет постоянно бегать к программисту?
Все равно не вижу преимуществ шаблонизаторов перед нативной версткой.
Я готов понять шаблонизаторы при использовании которых шаблон остается HTML-страничкой с разметкой, а не превращается (смарти) в подобие псевдокода.
Что-то LEOnidUKG сильно возбудился, я вообще не призываю пользоваться шаблонизаторами, но верстальщикам, с которыми я работал шаблонизаторы больше нравятся, чем шаблоны на php.
С наследованием - банально у вас есть общий шаблон страницы, куда вы вставляете контент, сгенерированный вашим модулем. Вам надо сменить для какой-то одной страницы этот общий шаблон на, допустим, упрощенный где нет каких-то частей. Меню, например, нет или другое оно вообще. Как это сделать в шаблоне на php?
В вызовом родительских блоков - надо вставить в <head> какой-нибудь скрипт только на одной странице.
anton831, я как программиста вас понимаю, но я полагаю, что шаблонизаторы сделаны для удобства верстальщиков. Если вам приходится еще и шаблоны натягивать, то это печально, я лично против такой универсализации.
anton831, я как программиста вас понимаю, но я полагаю, что шаблонизаторы сделаны для удобства верстальщиков. Если вам приходится еще и шаблоны натягивать, то это печально, я лично против такой универсализации.
Мне их еще и верстать и в фотошопе рисовать, и флэшки для них делать приходится.:)
Возбуждаюсь я только на девушек. На всякие споры с пионерами нет, уж увольте.
WP посмотрите как это сделано ок?
Предусмотреть, при разработке CMS.
Когда я их разрабатываю, я смотрю на вёрстку, если там меняется вся сердцевина или как вы говорите, упрощённый вариант, то просто проектирую систему именно под такие возможности и всё.
Никто не запрещает все нужные данные обрабатывать в 1 файле, а потом нужные переменные вставлять в любой шаблон.
Так же никто не запрещает делать
<head>
<?php include('основные модуля'); ?>
</head>
Только вот вопрос, а чем этот подход отличается от шаблонизаторов? Шаблонизаторы написаны на PHP у них физически не может быть больше возможностей, чем у PHP.
---------- Добавлено в 16:22 ---------- Предыдущее сообщение было в 16:19 ----------
Не путайте понятие: "Мне больше нравиться, потому ЧТО" и "Мне больше нравиться т.к. другого я не знаю".
Вам надо сменить для какой-то одной страницы этот общий шаблон на, допустим, упрощенный где нет каких-то частей. Меню, например, нет или другое оно вообще. Как это сделать в шаблоне на php?
Все равно не совсем понимаю... что мешает подключить второй - упрощенный -шаблон вместо первого в контроллере? Или же в самом шаблоне поставить условие не показывать какие-то блоки в зависимости от параметров переданных из контроллера во вью?
Тут или проблема надумана, или я не понимаю всей её глубины, или же это сложно как раз при использовании сторонних шаблонов.
В контроллере - ничего, но это у вас уже тогда view залез в controller получается.
Либо усложнение шаблонов.
Это вы не путайте, я работал с шаблонизаторам с вынесением логики в шаблон и без логики в шаблонах и с php-шаблонами и просто с echo "<html>".
Можно цитату или ссылку, где я говорю, что у шаблонизаторов больше возможностей, чем у php? А то вы мне все что-то пытаетесь приписать и оспорить тезисы, которые я не выдвигал, успокойтесь.
Про добавление, допустим, в <head> скрипта из шаблона пример будет? Без извращений, типа ob_-функций?
но это у вас уже тогда view залез в controller получается
Почему? Вот пример (немного повырезал несущественное):
То есть, у нас подключается layout (column2), в него уже вставляется шаблон create в конкретном actionCreate. у нас есть две возможности - в конкретном action Create или подключать другой темплейт (не create), или же подключить другой layout
$this->layout = 'column3';
или же условие сделать в темплейте.
p.s. Кстати, вспомнил об одном случае, когда были проблемы в введением переменных в родительский шаблон. Хотя то скорее исключение было.
Про добавление, допустим, в <head> скрипта из шаблона пример будет? Без извращений, типа ob_-функций?
Чего пример то? Я должен сам придумать кривую структуру CMS, которая это не позволяет и потом делать выводы? 😂
Ну что мешает сделать обычно:
<head>
if ($page='pay') {
<script src="ajax.js"></>
}
</head>
Можно лучше, в шаблон сделать так:
<head>
....
<css
<js
<title
....
<?php echo $addhead; ?>
</head>
Всё, теперь при обработке скриптов, мы всегда имеем возможность вставить в нашу переменную $addhead любые данные.
В чём проблема то?