Реализация шаблона Page Controller

Опубликовал read-php в 17.02.2011 Категория: Шаблоны корпоративных приложений PHP

Хотя при применении шаблона Page Controller метут возникать трудности, сам шаблон чрезвычайно прост. Управление привязано к представлению или набору представлений. В простейшем случае это означает, что управление находится в самом представлении, хотя его можно отделить, особенно если представление тесно связано с другими представлениями (т.е. в случае, когда вам в различных ситуациях нужно перенаправлять к разным страницам).

Вот простейший пример реализации шаблона Page Controller.

<?php

try {

$venues = woo_domain_Venue::findAll();

} catch ( Exception $e ) {

include( ‘error.php’ );

exit(0);

}

// Стандартная страница расположена ниже

?>

<html>

<head>

<title>3aведения</title>

</head>

<body>
hl>3аведения </hi>

<?php foreach( $venues as $venue ) { ?>

<?php print $venue->getName(); ?> <br />

<?php } ?>

</body>

</html>

Этот документ состоит из двух элементов. Элемент-представление управляет отображением, а элемент-контроллер управляет запросом и вызывает логику приложения. Хотя представление и контроллер находятся на одной и той же странице, они строго разделены.

К этому примеру можно мало что добавить (кроме работы с базой данных, которая выполняется «за сценой». Блок PHP-кода вверху страницы пытается получить список всех объектов типа Venue, который он сохраняет в глобальной переменной $venues. Если происходит ошибка, эта страница делегирует полномочия по ее обработке странице error. php с помощью функции include ( ), за вызовом которой следует вызов функции exit ( ), чтобы прекратить любую дальнейшую обработку текущей страницы. Я предпочитаю этот механизм механизму пересылки по протоколу HTTP, который является более сложным и при использовании которого теряются все текущие сеансовые переменные окружения, которые вы сохранили в оперативной памяти. Если вызов include ( ) не используется, то отображается представление, заданное внизу страницы, описанное HTML-кодом.

Scr08 Реализация шаблона Page ControllerКак видите, мы реализовали шаблон Page Controller в виде тестового примера довольно быстро, но при создании больших систем, вероятно, потребуется приложить гораздо больше усилий, чем в данном случае.

Ранее код шаблона Page Controller был неявно отделен от представления. Сейчас я сделаю это разделение явным, начав с определения элементарного базового класса Page Controller.

abstract class woo_controller_PageController {

private $request;

function _construct() {

$request = woo_base_RequestRegistry::getRequestО;

if ( is_null( $request ) ) {

$request = new woo controller Request();

}

$this->request = $request;

}

abstract function process();

function forward( {resource ) {

include( $resource );

exit( 0 );

}

function getRequestO {

return $this->request;

}

}

В этом классе используются средства, которые мы уже рассматривали, в частности, классы Request и RequestRegistry. Главные задачи класса PageController — обеспечить доступ к объекту Request и управлять включением представлений. Этот список задач в реальном проекте будет быстро расти, по мере того как у дочерних классов будет возникать необходимость в общей функциональности.»

Дочерний класс может находиться внутри представления и поэтому отображать его по умолчанию, как и раньше, или находиться отдельно от представления. Мне кажется, второй подход более подходящий, поэтому я выбрал именно его. Приведем пример реализации класса PageController, в котором предпринимается попытка добавить новое заведение к системе.

class woo_controller_AddVenueController extends

woo_controller_PageController {

function process() {

try {

$request = $this->getRequest() ;

$name = $request->getProperty( ‘venue_name’ );

if ( is_null ( $request->getProper^( ‘ submitted’) ) ) {

$request->addFeedback(«Выберите имя заведения»);

$this->forward( ‘ Addvenue .php’ );

} else if ( is_null( $name ) ) {

$request->addFeedback(«Имя должно быть обязательно задано»);

$this->forward( ‘Addvenue.php’ );

}

$venue = new woo_domain_Venue( null, $name );

$this->forward( «ListVenues.php» );

} catch ( Exception $e ) {

$this->forward( ‘error.php’ );

}

}

}

$controller = new woo_controller_AddVenueCont-roller();

$controller->process();

В классе AddvenueController реализован только метод process ( ), который отвечает за проверку введенных пользователем данных. Если пользователь не заполнил форму или заполнил ее неправильно, то включается стандартное представление (add venue .php), обеспечивающее обратную связь и выводящее форму. Если мы успешно добавили новое заведение, то в этом методе вызывается метод forward ( ), который перенаправляет пользователя контроллеру страницы Listvenues.

Обратите внимание на формат, который я использовал для представления. Я стараюсь различать файлы представлений от файлов классов, используя для первых в именах символы нижнего регистра, а для вторых— соединение слов и символы верхнего регистра на границах слов.

Приведем пример представления, связанного с классом AddvenueController.

<?php

require_once( «woo/base/Registry.php» );

$request = woo_base_RequestRegistry::getRequest() ;

?>

<html >

<head>

<ti11е>Добавление заведения</title>

</head>

<body>

<hl>Добавление заведения</hl>

<table>

<tr>

<td>

<?php

print $request->getFeedbackString(»</td></tr><tr><td>») ;

?>

</td>

</tr> <

/table>

<form action=»AddVenue.php» method=»get»>

<input type=»hidden» naшe=»submitted,, value=»yes»/>

<input type=»text» name=»venue_name» />

</form>

</body>

</html>

Как видите, в этом представлении не делается ничего, кроме отображения данных и обеспечения механизма для генерации нового запроса. Причем этот запрос делается к классу Pagecontroller, а не снова к представлению. Помните, именно класс PageController отвечает за обработку запросов.

На рисунке ниже показана схема этой более сложной версии реализации шаблона Page Controller.

Scr09 Реализация шаблона Page Controller

Комментариев нет

Добавить комментарий