Comments 10
Собственно 1-й способ самый безгеморойный и внятный при всех его недостатках. Думаю он и останется, в противном случае будет одна морока.
В принципе согласен, просто радует что разработчики sf2 так глубоко копают. На самом деле 5 вариант мне тоже как-то по душе. Тем более что он совместим с первым, только с чуть большими возможностями, то есть в PR2 может что-то и поменяться. Будет довольно интересно если это произойдет.
насчет прямой передачи параметров — это очень неприятно использовать, хотя бы со стороны именования этих самых парметров и вообще иденобразия и понятности кода. Да и зачем забивать голову разработчика лишним… Думаю эти варианты посколь-постольку, никто в здравом уме с проектом в таком масштабе не откажется об №1. Остальные просто перекладывают проблемы безопасности на разработчика, где в 90% случаях это просто не нужно. Ну и другие популярные фреймворки идут по тому же пути.
тут есть одно но. Такой способ крайне прямолинеен при работе с DI. Никто туда руками это количество параметров совать не будет. IoC контейнер это сделает за Вас. Зато отлаживать и тестировать удобно, когда все закинуто через конструктор и никаких чудес и магии.
Так, что
function __construct(User $user, Request $request, $maxPerPage)
вполне будет жить и вы об это споткнетесь только когда плагин будете писать. и там это будет удобно и уместно.
а вот с номером 1 вы как раз пихаете один большой супер-мега-глобальный контекст в класс и внутри начинается магия.
Так, что
function __construct(User $user, Request $request, $maxPerPage)
вполне будет жить и вы об это споткнетесь только когда плагин будете писать. и там это будет удобно и уместно.
а вот с номером 1 вы как раз пихаете один большой супер-мега-глобальный контекст в класс и внутри начинается магия.
Обеими руками за первый способ!
почему такая конструкция считается простой?
$limit = $this->container->request->getParameter('max');
почему нельзя иметь глобальный массив params, заполняемый где-то раньше и доступный как
$limit = $params['max'];
мне кажется конструкция
$this->container->request->getParameter
подчеркивает красоту ОО структуры классов и структуризации, но очень неудобна, когда ты пишешь код (5-10 строк) внутри метода контроллера ибо занимает слишком много места
$limit = $this->container->request->getParameter('max');
почему нельзя иметь глобальный массив params, заполняемый где-то раньше и доступный как
$limit = $params['max'];
мне кажется конструкция
$this->container->request->getParameter
подчеркивает красоту ОО структуры классов и структуризации, но очень неудобна, когда ты пишешь код (5-10 строк) внутри метода контроллера ибо занимает слишком много места
ну идея в том что глобальные переменные — это свойства контейнера, обращение к ним:
а вы описали доступ к параметру запроса — поэтому чуть громоздко.
то что вы написали, наверное будет выглядеть так:
А если учитывать что контейнер всегда определен, то доступ к глобальным переменным довольно краток:
использовать доступ к глобальному массиву с метода action — это нехорошо, думаю, с точки зрения безопасности.
$global = $this->container['max_per_page'];а вы описали доступ к параметру запроса — поэтому чуть громоздко.
то что вы написали, наверное будет выглядеть так:
$limit = $this->request['max'];А если учитывать что контейнер всегда определен, то доступ к глобальным переменным довольно краток:
$global = $this->getParameter('max_per_page');использовать доступ к глобальному массиву с метода action — это нехорошо, думаю, с точки зрения безопасности.
> использовать доступ к глобальному массиву с метода 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']){… }
> зрения безопасности.
1. мне не доступ к глобальному массиву нужен, а список входных параметров. А других путей кроме как сделать это через глобальный массив, с точки зрения простоты синтаксиса, я не вижу.
2. с точки зрения безопасности весь этот массив входных параметров можно прогнать через stripTags функцию где-нибудь в dispatch методе
3. $this->getParameter мне тоже не нравится :),… этой функцией предполагается пользоваться к каждом методе контроллера
if ($u = User::get_by_id($this->getParameter('id')){… }
а визуально лучше
if ($u = User::get_by_id($param['id']){… }
«но успокаивает факт, что вы можете использовать метод контейнера в этих случаях». Тут на самом деле не про «метод контейнера» а про «IoC-контейнер». Речь о паттерне «Обращение контроля».
Не очень понятен перевод если не знать о таком паттерне.
ИМХО самый технологичный способ.
Не очень понятен перевод если не знать о таком паттерне.
ИМХО самый технологичный способ.
и зачем этот геморой, если достаточно пятого, который самый понятный и удобный. а то всё стремяться найти замену глобалсам и таскать их повсюду.
Sign up to leave a comment.
Какими будут контроллеры в PR2?