Какими будут контроллеры в PR2?

[trevel]

Собственно 1-й способ самый безгеморойный и внятный при всех его недостатках. Думаю он и останется, в противном случае будет одна морока.

[skorney]

В принципе согласен, просто радует что разработчики sf2 так глубоко копают. На самом деле 5 вариант мне тоже как-то по душе. Тем более что он совместим с первым, только с чуть большими возможностями, то есть в PR2 может что-то и поменяться. Будет довольно интересно если это произойдет.

[trevel]

насчет прямой передачи параметров — это очень неприятно использовать, хотя бы со стороны именования этих самых парметров и вообще иденобразия и понятности кода. Да и зачем забивать голову разработчика лишним… Думаю эти варианты посколь-постольку, никто в здравом уме с проектом в таком масштабе не откажется об №1. Остальные просто перекладывают проблемы безопасности на разработчика, где в 90% случаях это просто не нужно. Ну и другие популярные фреймворки идут по тому же пути.

[fantaseour]

тут есть одно но. Такой способ крайне прямолинеен при работе с DI. Никто туда руками это количество параметров совать не будет. IoC контейнер это сделает за Вас. Зато отлаживать и тестировать удобно, когда все закинуто через конструктор и никаких чудес и магии.

Так, что
function __construct(User $user, Request $request, $maxPerPage)

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

а вот с номером 1 вы как раз пихаете один большой супер-мега-глобальный контекст в класс и внутри начинается магия.

[krestjaninoff]

Обеими руками за первый способ!

[se_pavel]

почему такая конструкция считается простой?

$limit = $this->container->request->getParameter('max');

почему нельзя иметь глобальный массив params, заполняемый где-то раньше и доступный как

$limit = $params['max'];

мне кажется конструкция
$this->container->request->getParameter

подчеркивает красоту ОО структуры классов и структуризации, но очень неудобна, когда ты пишешь код (5-10 строк) внутри метода контроллера ибо занимает слишком много места

[skorney]

ну идея в том что глобальные переменные — это свойства контейнера, обращение к ним:

$global = $this->container['max_per_page'];

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

$limit = $this->request['max'];

А если учитывать что контейнер всегда определен, то доступ к глобальным переменным довольно краток:

$global = $this->getParameter('max_per_page');

использовать доступ к глобальному массиву с метода action — это нехорошо, думаю, с точки зрения безопасности.

[se_pavel]

> использовать доступ к глобальному массиву с метода action — это нехорошо, думаю, с точки
> зрения безопасности.

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

2. с точки зрения безопасности весь этот массив входных параметров можно прогнать через stripTags функцию где-нибудь в dispatch методе

3. $this->getParameter мне тоже не нравится :),… этой функцией предполагается пользоваться к каждом методе контроллера

if ($u = User::get_by_id($this->getParameter('id')){… }

а визуально лучше
if ($u = User::get_by_id($param['id']){… }

[Olegas]

«но успокаивает факт, что вы можете использовать метод контейнера в этих случаях». Тут на самом деле не про «метод контейнера» а про «IoC-контейнер». Речь о паттерне «Обращение контроля».
Не очень понятен перевод если не знать о таком паттерне.

ИМХО самый технологичный способ.

[AmdY]

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