Меню
Что нового?

Гуру, я не знаю что такое MVC в PHP, хоть и считаю себя опытным программистом. Объясните наконец!

Alien85

Alien85

I like my cat
Духовность™ написал(а):
а зачем нужен шаблонизатор, если есть php?
Нажмите для раскрытия...
удобство, понятность.
Лично я использую собственный шаблонизатор. Он простейший как 2х2.

Пример:
PHP: 
<body>
	Привет {L_Name},
	Ваши заказы:
	{S_Orders}
		Заказ {Orders.ID}: {Orders.Name} - {Orders.Cost} руб.<br />
	{E_Orders}
</body>
С таким подходом абсолютно не портится html код, полное разделение: управление-шаблон.
Есть поддержка автокомпиляции шаблонов в php файлы, такие как у вас :)

Конечно, кому как удобнее.
 
С.

С.

Продвинутый новичок
rvolt написал(а):
Разве к View не относится весь код, который отвечает непосредственно за построение представления?.
Нажмите для раскрытия...
В таком случае вообще ВЕСЬ код (вклкючая PHP и OS) отвечает за построение представления. Давайте будем проводить черту адекватно. Согласитесь, что ни шаблонизатор, никакие другие части комплекса не влияют на отображение, только сам шаблон.

rvolt написал(а):
В том числе и код, который предварительно подготавливает данные, получаемые от модели для отображения в шаблоне (например, нестандартный колоночный вывод, линеаризация иерархии для вывода без рекурсивных вызовов)?
Нажмите для раскрытия...
Хелперы -- это трудное место MVC. На то MVC и является ПРАДИГМОЙ, то есть диктующей только основополагающие принципы, но не детали. Есть например христианская парадигма (идея), но в реальности она материализуется в католицизм, православие, лютеранство и т.д.

MVC не оговаривает хелперы, но практика показывает, что без них никак. Логически хелперы можно отнести как модели, так и к вью (в нем всегда присутствуют как собственно вью, так и элементы модели). Поэтому примите любую понравившуюся вам конфессию и да прибудет с вами MVC.
 

rvolt

Новичок
Духовность™ написал(а):
а зачем нужен шаблонизатор, если есть php?
Нажмите для раскрытия...
1. Нет нужды везде писать "<?php ?>" и нормальное обращение к массивам: "{$array.key.subkey}" - пожалуй, это основные определяющие моменты для большинства разработчиков.

2. Удобнее применять всякие модификаторы (опять же "<?php ?>" и не нужно использовать синтаксис вызова функции - имя + 2 скобки вокруг аргумента(ов)) - "{$value|escape}".

3. При использовании PHP для вывода HTML возникает дилемма - написать:
PHP: 
<?php
foreach($items as $item)
{
?>
	html html <?php echo $var1 ?> html <?php echo $vaк2 ?> html
	html <?php echo $var3 ?> html
	html html <?php echo $var4 ?> html <?php echo $var5 ?> html
<?php
}
?>
или
PHP: 
<?php
foreach($items as $item)
{
	echo "html html {$var1} html {$var2} html";
	echo "html {$var3} html";
	echo "html html {$var4} html {$var5} html";
}
?>
С шаблонизатором таких дилемм не возникает

Шаблонизатор - это прежде всего читабельность и экономия времени при создании, поддержке и рефакторинге шаблонов.
 
craz

craz

Нестандартное звание
rvolt написал(а):
1. Нет нужды везде писать "<?php ?>" и нормальное обращение к массивам: "{$array.key.subkey}" - пожалуй, это основные определяющие моменты для большинства разработчиков.

2. Удобнее применять всякие модификаторы (опять же "<?php ?>" и не нужно использовать синтаксис вызова функции - имя + 2 скобки вокруг аргумента(ов)) - "{$value|escape}".

3. При использовании PHP для вывода HTML возникает дилемма - написать:
PHP: 
<?php
foreach($items as $item)
{
?>
	html html <?php echo $var1 ?> html <?php echo $vaк2 ?> html
	html <?php echo $var3 ?> html
	html html <?php echo $var4 ?> html <?php echo $var5 ?> html
<?php
}
?>
или
PHP: 
<?php
foreach($items as $item)
{
	echo "html html {$var1} html {$var2} html";
	echo "html {$var3} html";
	echo "html html {$var4} html {$var5} html";
}
?>
С шаблонизатором таких дилемм не возникает

Шаблонизатор - это прежде всего читабельность и экономия времени при создании, поддержке и рефакторинге шаблонов.
Нажмите для раскрытия...
3. второй вариант не делемминичен - он просто работает медленнее значит заменяется первым
 
Alien85

Alien85

I like my cat
2. Удобнее применять всякие модификаторы (опять же "<?php ?>" и не нужно использовать синтаксис вызова функции - имя + 2 скобки вокруг аргумента(ов)) - "{$value|escape}".
Нажмите для раскрытия...
У вас логика в шаблоне, что я считаю не допустимым. Но для вас возможно так лучше.
 

rvolt

Новичок
С. написал(а):
В таком случае вообще ВЕСЬ код (вклкючая PHP и OS) отвечает за построение представления. Давайте будем проводить черту адекватно. Согласитесь, что ни шаблонизатор, никакие другие части комплекса не влияют на отображение, только сам шаблон.
Нажмите для раскрытия...
Как же не влияет. Шаблонизатор это неотьемлемая часть View. Это механизм, который на основе конфигурации - шаблона, генерит представление.
Наверное, всё зависит от реализации. Я привык, что компоненты слоя контроллера содержат ссылку на объект View, контроллер запускает генерацию кода View, но ссылка на объект шаблонизатора хранится в самом View, а не в контроллере.
Даже если контроллер содержит ссылку на объект шаблонизатора и сам общается с ним напрямую, то 1) всё равно шаблонизатор не становится частью контроллера, где же тогда слой View, это не MVC? 2) ИМХО, это хреновый дизайн системы.
 
craz

craz

Нестандартное звание
меняем ваш вид с html на xml в контролере,в зависимости к примеру от $_REQUEST, что происходит с шаблонизатором? если в виде сслыка на него?
 

rvolt

Новичок
Alien85 написал(а):
У вас логика в шаблоне, что я считаю не допустимым. Но для вас возможно так лучше.
Нажмите для раскрытия...
Это не бизнес-логика, а логика вывода. За вывод четный-нечетный у вас разве модель отвечает?
Флаги наверное ставите, или дробите данные на две части - одну по чёту выводить другую по нечету:
PHP: 
for(...)
{
	echo $odd[$i];
	echo $even[$i]
}
шутка :)
 

rvolt

Новичок
craz написал(а):
меняем ваш вид с html на xml в контролере,в зависимости к примеру от $_REQUEST, что происходит с шаблонизатором? если в виде сслыка на него?
Нажмите для раскрытия...
В моём случае это не получится сделать в контроллере. В том-то всё и дело, что объект вида сам знает, как ему отображаться и шаблонизатор он инстанцирует сам. Это не позволит контроллеру подсунуть ему шаблонизатор, которым он не умеет пользоваться или не рассчитан на него.
Вы когда создаете представления всегда рассчитываете их на всевозможные шаблонизаторы или как? Если в вашем приложении контроллер подменит шаблонизатор, что будет с приложением?
Если вид поддерживает несколько форматов генерации документа, то он сам должен определять какой формат использовать сейчас (по конфигу, по запросу). Если вы доверите это контроллеру, то при каждом изменении, по сути, в слое представления вам придется ковыряться не просто в чистеньком контроллере, а уже в вариации ТТУКа
 

rvolt

Новичок
craz написал(а):
меняем ваш вид с html на xml в контролере,в зависимости к примеру от $_REQUEST, что происходит с шаблонизатором? если в виде сслыка на него?
Нажмите для раскрытия...
Не понял сразу. У меня контроллер содержит ссылку на экзепляр класса представления, специфичного для данной страницы (группы страниц). А они уже знают всё, что нужно для построения страницы.
 

rvolt

Новичок
craz написал(а):
3. второй вариант не делемминичен - он просто работает медленнее значит заменяется первым
Нажмите для раскрытия...
Во-первых, незначительное повышение производительности проекта при ухудшении читаемости и поддержки. Для меня дилемма осталась. Любая оптимизация должна быть многокритериальной.
Во-вторых, при использовании компилируемого шаблонизатора, мы на выходе из шаблонизатор получим тот код который устроил вас. Хотя тут есть свои оговорки.
 
craz

craz

Нестандартное звание
rvolt написал(а):
В моём случае это не получится сделать в контроллере. В том-то всё и дело, что объект вида сам знает, как ему отображаться и шаблонизатор он инстанцирует сам. Это не позволит контроллеру подсунуть ему шаблонизатор, которым он не умеет пользоваться или не рассчитан на него.
Вы когда создаете представления всегда рассчитываете их на всевозможные шаблонизаторы или как? Если в вашем приложении контроллер подменит шаблонизатор, что будет с приложением?
Если вид поддерживает несколько форматов генерации документа, то он сам должен определять какой формат использовать сейчас (по конфигу, по запросу). Если вы доверите это контроллеру, то при каждом изменении, по сути, в слое представления вам придется ковыряться не просто в чистеньком контроллере, а уже в вариации ТТУКа
Нажмите для раскрытия...
именно из-за того, чтобы не оправдываться, что у меня нельзя всю туже инфу вывести в xml/json/doc/pdf/все что угодно, потому и потому, я не пользуюсь шаблонизаторами сторонними.

или просто к примеру мне надо изменить для каких то пользователей вид отображения новостей, к примеру для арабов каких-нить выводить их справа на лево...
 
craz

craz

Нестандартное звание
rvolt написал(а):
Не понял сразу. У меня контроллер содержит ссылку на экзепляр класса представления, специфичного для данной страницы (группы страниц). А они уже знают всё, что нужно для построения страницы.
Нажмите для раскрытия...
если ссылка получаеться у вас рендера нет? так? а если и есть как с шаблонизатором вы будете с ним работать?
 

rvolt

Новичок
craz написал(а):
или просто к примеру мне надо изменить для каких то пользователей вид отображения новостей, к примеру для арабов каких-нить выводить их справа на лево...
Нажмите для раскрытия...
Он может подключать 2 разных TPL-файла.
Может использовать другой шаблонизатор, если потребуется - View может делать всё, что связано с логикой отображения.
Его задача подготовить данные модели для шаблона и запустить его рендеринг.
 
craz

craz

Нестандартное звание
rvolt написал(а):
Он может подключать 2 разных TPL-файла.
Может использовать другой шаблонизатор, если потребуется - View может делать всё, что связано с логикой отображения.
Его задача подготовить данные модели для шаблона и запустить его рендеринг.
Нажмите для раскрытия...
не удобно я бы написал другой вид и отрендерил бы его в контроллере в зависимости от геоайпи. И не поимел бы ТТУК кстати.

но каждый как известно...
 

rvolt

Новичок
craz написал(а):
если ссылка получаеться у вас рендера нет? так? а если и есть как с шаблонизатором вы будете с ним работать?
Нажмите для раскрытия...
Некоторый абстрактный класс для представлений, использующих Smarty:
PHP: 
abstract class ..._Mvc_SmartyView extends ..._Mvc_AbstractView
{
	...
	public function build()
	{
		$smarty = self::getSmartyInstance(); // Singleton
		...
		$smarty->assign($this->templateVars); // условно. переменные для шаблона утанавливаются в методе prepare()
		...
		return $smarty->fetch($templateFileName);
	}
	...
}
Генерация View упрощенно:
PHP: 
$view = new $className(...); // класс определяется исходя из поступившего запроса
...
// готовим всё, что нужно для генерации представления, кстати View у меня генерит не только страницы, но и отдельные блоки, которые требуют специальной подготовки данных
$view->prepare();
...
// генерация и отдача страницы
echo $view->build();
 

rvolt

Новичок
craz написал(а):
не удобно я бы написал другой вид и отрендерил бы его в контроллере в зависимости от геоайпи. И не поимел бы ТТУК кстати.

но каждый как известно...
Нажмите для раскрытия...
Ваш вариант тоже можно использовать. Но, если получение данных для генерации шаблона идентично для всех geo, т.е. мы где-то во View :: prepare вызываем:
PHP: 
$model->getData($geo);
то не зачем создавать второй класс для View, а во View просто выбрать другой шаблон для генерации вывода.
 
craz

craz

Нестандартное звание
rvolt написал(а):
Ваш вариант тоже можно использовать. Но, если получение данных для генерации шаблона идентично для всех geo, т.е. мы где-то во View :: prepare вызываем:
PHP: 
$model->getData($geo);
то не зачем создавать второй класс для View, а во View просто выбрать другой шаблон для генерации вывода.
Нажмите для раскрытия...
эээ какой второй класс? у вас View - классы?
PHP: 
class MyController extends Controller_Action{
public function fooAction(){
  if ("arrabi" == GEOIP::GetNationByIP($ip)){
     $this->render("arrabi"); // my/arrabi.phtml
  }else{
      $this->render(); // my/foo.phtml
  }
}
}
}
 

rvolt

Новичок
Да много View классов, Page-классов (слой Controller) и один FrontController.
Вообще Zend-ский подход с ActionsController и действиями-методами меня не устраивает по ряду причин.
В общем у меня слой View действительно отделен от Controller.
 
Войдите или зарегистрируйтесь для ответа.
Сверху