proga66

у нас два перца были на этой конфе, расказали что и как там. Типа что мужи из Яндекса приезжали, рассказывали как они(яндекс) выполняют удаленные операции аж на 30к серворов за секунды. Еще нам наших два перца поведали про какие то фреймворки для работы с много поточностью, о которых им рассказали зарубежные умы на этой конференции. Плюс сказали, что редис тренд. Рассказали про django и что там хотят сделать в ней.

master, То есть, это применительно и ко мне? Думаю на этом стоит закончить обсуждение …

master, нет, функция не востребована.

master, понятно.

zend paginator так сумеет? я его просто никогда не юзал, не знаю )

master, не помню, я не использую такую фичу, но думаю он дает об этом информацию :)

а если мне нужно добавить ссылки "на первую страницу", "на последнюю страницу" - с этим как быть?

использовать другой шаблон пагинатора, с другой отрисовкой, ваш кэп :)

master, на счет изменения названия параметра страницы, тут можно подумать, мой код и вправду уязвим к копипасту в этом месте, но я ума не приложу, зачем мне будет нужно менять параметр страницы :)

А то что?

будет бобо при смене типа вьюхи :)

Ну так а какие данные ей передаются? Какую структуру возвращает $model->getPaginator() ?

я использую Zend Paginator для этого, так что можешь глянуть что он возвращает, но предупрежу, я обрабатываю то что он выдаёт, то есть разделяю записи и метаданные самого пагинатора.

И ещё вопрос: как в твоём случае модель решает, сколько записей должно быть на странице?

В примере я этого не привел, но она передается в метод, как дополнительный параметр, вот вырезки из реального кода http://pastebin.com/pRSaBaKA, можно задавать как свойства для модели http://pastebin.com/jQzMSRM0

Вьюха это шаблон?

Вьюха это просто объект или массив с данными, шаблонизатор прикручивается отдельно. Да признаю, я не правильно выразился, вьюха не строит ссылки, строит шаблонизатор, который прикручен к вьюхе.

Тогда бэд практис, потому что задавать и использовать переменные нужно в одном и том же месте.

какие переменные? где использовать? поясни, не совсем понятно, что имелось в виду, и почему это плохая практика?

то есть подразумеваешь, что GET-переменная, отвечающая за номер страницы, должна называться page, это прописано в контроллере, значит и формировать url с параметром page нужно в том же месте, в контроллере

пример был абстрактен и упрощен, текущие примеры более детально раскрывают суть дела. Что на счет формировать ссылки, опять же нет, вот код отрисовки пагинатора(шаблонизатор нативный)
http://pastebin.com/XTH33u0n

master,
О вьюхе:
1) Ссылки и пагинатор, всегда должны строиться во вьюхе, если ссылки будут строиться в контроллере, то это ахтунг;
2) Вьюха должна решать, что ей надо, а что ей не надо. Как ей строить ссылки, как подключать шаблоны, все это должна решать сама вьюха, полагаясь на данные которые ей передали.
3) Название шаблона для пагинатора, можно указать в контроллере, НО только название, а не путь до шаблона или инициализированный кусок шаблонизатора. Ни в коем случае нельзя конкретизировать тип вьюхи, для которой предназначаются эти данные.

О модели:
1) Ты просишь у модели список записей, тупо список записей, ты его получаешь;
2) Ты указал модели, что хочешь получить список записей, но со смещением таким то и в таком то количестве, проще говоря ты указал состояние модели, но в ответ ты получаешь так же тупо список записей, но с маленькой помаркой, модель как то получала этот список записей и от этого у нее появились об сием действии данные, она их кинула в один из своих свойств(атрибутов). Ты опять же получаешь свой список записей, но если тебе нужен пагинатор, то ты тупо эти данные забираешь у модели с помощью контролера, через метод $model->getPaginator(), и отдаешь их вьюхе, а вьюха видя наличие этих данных радостно строит по ним пагинатор. Все хэппи энд.

Я не понимаю, почему я на столько очевидные вещи доказываю пользователю с ником master.

с этого места можно поподробнее? куда ты предлагаешь вынести пагинатор из контроллера?

В модель логику, в вьюху интерфейс.

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

public function index(){
  $records = $model->collection();
  return array(
    'records' => $records
  );
}

с пагинатором,

public function index($page){
  $records = $model->collection($page);
  return array(
    'records' => $records
    'paginator' => $model->getPaginator()
  );
}

AlexB, мне кажется такое поведение php, вполне логично и оправдано. Но хочу сказать, что в моей практике, неудобств такое поведение не вызывало, так как я сделал фабрику для инициализации объектов, в не

Я бы не парился насчёт количество файлов, да ещё бы отдельно неймспейс наворочал R2\Exceptions

+1

lolcat, :|

Я имел ввиду не замыкания, а http://php.net/manual/ru/language.namespaces.importing.php .

lolcat, если кодишь на php 5.3, то обгораживаешь все файлы неймспейсом напримере

namespace SomeOldSystem;

#код

в итоге вся старая система доступа в одном неймспейсе, можно развить тему дальше и написать эмулятор для существующего кода с использованием возможностей неймспейсов, то есть переопределение функции и бла бла бла.

А поверх забобахать классный фреймворк, и SomeOldSystem, научить работать с этим фреймворком, путем use и тех же переопределений.

sam, как реализуете возможно запускание вне документ_рут, отпишитесь в эту тему.

sam, Знаете почему ваша система отстой, потому что я ее не могу развернуть, так как у нее в требованиях документ_рут, у меня все скрипты могут работать независимо от их расположения. Разве так сложно использовать dirname(__FILE__) или __DIR__?

Что касаемо кода, заглянул в контроллеры:
1. Толстые контроллеры;
2. Много статики, фабрик и повторяющейся шулухи, используйте внедрение зависимостей;
3. Много шаблонного кода, который можно вытянуть в родительский класс.

К примеру, метод из контроллера News:

	public function indexAction()
	{

		$page = intval(Request::getInstance()->getPart(1));
		
		if($page < 1)
			$page = 1;
		
		$from = ($page-1) * $this->_config->get('num_in_list');	
		 
   		$model = Model::factory('News');
   		 
   		$params = array(
   		 		'sort'=>'news_date',
   		 		'dir'=>'DESC',
   		 		'start'=>$from,
   		 		'limit'=>$this->_config->get('num_in_list')
   		);
   		 
   		$filters = array('published'=>true);

   		/*
   		 * Hard cache!
   		 */
		$data = $model->getList(
	   		 	$params,
	   		 	$filters,
	   		 	array('id','title','news_date'),
	   		 	true		 	
	   	);	

	   	$itemsCount = $model->getCount($filters,false,true);
	   		   	
	   	$pager = new Pager(); 
   		$pager->curPage = $page;
   		$pager->numLinks = 5;
   		$pager->pageLinkTpl = Request::url(array($this->_router->findUrl('news') , '[page]'));
   		$pager->numPages = ceil($itemsCount / $this->_config->get('num_in_list'));
   		
   		$template = new Template();
		$template->list = $data;
		$template->page = $this->_page;
		$template->pager = $pager;
		$template->router = $this->_router;
		

		$this->_page->text = $template->render($this->_page->getTemplatePath('news_list.php'));  		
	}

Зачем в контроллере пагинатор? Зачем в контроллере шаблонизатор? Да, это понятный код, но не поддерживаемый.

Работая в офисе, ставят задачи тимлид и ПМ через Redmaine, уточняю, если что не понятно, потом составляю план на день. Про что говорил master, у нас решается путем выставления приоритетов на задачи, которые выставляет ПМ. Время на задачи оцениваю сам, как и все в команде. факмоймозгвмоемпостеопечатка