конфиги- это уже по части модели. когда я говорю "взаимодейстовать с пользователем" про контролеры, всегда имею в виду только взаимодействие через браузер. если например взаимодействие через сеть, как в случае команд асичному боту, это тоже по части моделей. Контролеры только для взаимодействия через браузер.
я иногда больше склоняюсь к мнению что вид и контроллер то в браузере они , а модель и инфраструктура в скрипте!!!
что такое вьюшка в МВЦ? вьюшка- это какой-то класс, который отображает модель. это ее единственное назначение. какую вьюшку накинешь сверху на модель, так она и отобразится. поэтому вьюшка- это тоже код, а не браузер.
Мои 5 копеек (если я правильно понял задачу) Дано. объекты - пользователи Надо. Вывести n пользователей на страницу Пример станицы Модели Код (Text): class User { protected $_name; public function __constuct($name) { $this->_name = $name; } public function getName() { return $this->_name; } } class UserGateway() { public function getUsers($count) { $result = array(); foreach ($i = 0; $i<$count; $i++) { $result[] = new User('user_name' . $i); } return $result; } } Контроллер Код (Text): class UserController { public function showUsers() { $number_of_users = 10; if (isset($_POST['number_of_users']) && another_checks) { $number_of_users = $_POST['number_of_users']; } $gateway = new UserGateway(); $view = new UserView(); $view->users = $gateway->getUsers($number_of_users); $view->render(); } } Представление Код (Text): class UserView { public $users; public function render() { // начало html // вывод пользователей foreach ($this->users as $ind => $user) { echo '# ' . $ind . ' пользователь ' . $user->getName() . '<br />'; } // окончание html } } В данном случае ни модели, ни представления не хранят количество пользователей в отдельных полях. Контроллер получает (возможный) ввод пользователя, модели работают с тем, что надо показать пользователю, представление выводит. Это то, что хотел пользователь [/quote]
Тогда надо в условие задачи дописать, что с этим количеством делать. Например, если надо на странице показать то можно в методе showUsers() контроллера дописать Код (Text): $view->number_of_users = $number_of_users; с добавлением соответствующей переменной в представление.
когда я был маленьким, всегда путался куда засунуть этот number_of_users. Иногда мне казалось что в модель, иногда что во вьюшку или сегодня кажется что в модель, а завтра уже во вьюшку. Мне казалось, что тут нет какого- то однозначного решения. Все от ситуации, ситуация изменилась и все делится по-новому. Все надо переписывать. гавеный мвц. а обещали, что сказка. А потом я понял, что правильное разделение на три класса только одно, а все остальные неправильные. если все делать правильно, то никогда ничего не приходится переделывать и никогда в них не путаешься. Даже если через месяц в правильную МВЦ поставить новую задачу, про которую и не думал, когда писал классы месяц назад, она туда вольется так же легко, как будто ты спецально для нее их писал. все классы вспомняться сами собой, потому что они только так и могут делить обязанности. Только так и могут взаимодействовать. в том то и дело, что не надо этого знать. ты ведь не знаешь, что тебе придется делать завтра с этими классами. а если не отображать на странице, а что- то другое или ты хочешь все переписывать? если правильно разделить между М В и Ц, тебя это и не будет никогда волновать. Потому что разделить можно только одним способом вне зависимости от того, для чего это потом будет использоваться.
А вы предложите задачу, в которой необходим список пользователей и/или $number_of_users. И посмотрим, надо ли будет переписывать предложенные классы. Тогда не будет спора об избыточности хранения данного выбора пользователя в модели ExamlePage.
просто Пажер по определению предоставляет доступ к определенной странице данных из всего набора. Это не зависит от того, отображаются потом эти данные или нет, листает их пользователь или нет. Так? а как же он сможет предоставить к ним интерфейс, если даже не знает, сколько объектов должно быть на странице? Как тогда подготовить страницу? вот еще другой способ которым я всегда пользуюсь. мое авторство. чтобы очистить модель от всего лишнего, я всегда представляю консольное приложение. Это легко сделать. С пагером должно получиться что- то такое PHP: <?php $pager= new Pager(); $pager->number_of_users=25; $pager->page= 7; foreach($pager->getPage() as $user) fwrite($f, $user->getName()); все что есть в воображаемом консольном приложении- это модель. Больше тут не надо думать. Если потом надо обернуть этот класс пользовательским интерфейсом, пожалуйста, я накину на него вьюшку и контроллер. Если не надо, так и буду пользовать. Точно таким же способом можно проверить любую уже готовую тройку МВЦ. Делаем все наоборот. Выкидываем из нее контролер и вьюшку. Если получится написать консольное приложение только в моделях, значит все ОК, а если для этого придется притянуть контролеры и вьюшки - значит что-то не так.
то что должно стать моделью- это всегда модель. вьюшка- это всегда вьюшка, а контроллер- это всегда контроллер. это объективно есть. Т.е. они такие есть и все. это никак не может измениться от ситуации в которую они попадают. нельзя сказать, что это мне сейчас не надо в модели, поэтому я это добавлю во вьюшку. это будет уже ни то, ни се. получится кокой- то гибрид полу модель- полу вьюшка. От которой потом уже толком не пронаследовать ни модели, ни вьюшки. А человек, который будет использовать эти классы вообще повесится. Он то думает, что $number_of_users в модели. Откуда он знает, что вы решил так перераспределить функционал? Так ведь? Я это все прошел, честно говоря, когда нет строгости в коде, даже сам в своем же коде путаюсь. Сегодня так поделил, завтра уже кажется что все должно быть по другому. должно быть одно правило, тогда даже на 1000 моделях не будет проблем . если это данные из предметной области или бизнеслогика- это модель или модели. не важно. важно, что уровень моделей. Если это какое- то воздействие пользователя на модель через браузер- это контроллер. если это отображение модели - это вьюшка.
м? PHP: <?php $criteria = Criteria::create(User::dao())->paginate(5, 20); foreach ($criteria->getList() as $user) { // mail(...); } Если честно, то я уже потерял нить спора...
Оки. Задача усложнилась. 1. Есть база пользователей, из которой надо выбрать определенное количество пользователей, пропустив определенное количество. 2. При этом наглобалив так, чтобы MVC переделать в MV. Задача 2 кажется сложной, так как место, в котором создаются модели, будет определенным контроллером с определенным действием. Задача 1. 1. Добавляем в UserGateway метод getUsersFromBase($offset, $limit), в котором выполняем запрос к базе, получаем имена пользователей и создаем массив пользователей, который и возвращаем. 2. Делаем представление, которое подготовит нужный html или что будет посылаться на мыло. В это представление пойдет массив пользователей. 3. Делаем пересылку по почте с подготовленным представлением.
Примерно так сделано в onphp (они делали по аналогии с hibernate). За абсолютную точность примера не ручаюсь. Метод paginate переведёт всё в классический LIMIT и OFFSET.
В том числе и кол-во объектов. Я думаю, что контроллер создает модель, которая может выдать список объектов и запросить у этой модели объекты с такого-то в таком-то количестве. Затем передать этот список представлению, которое сделает с него страницу или запишет в файл. Зачем хранить запрошенное количество объектов в модели? И запрошенный номер?