<div dir="ltr">мне видится решением поместить в обработчик сабу с нужными параметрами и на этапе загрузки сгенерить обертки в зависимости от атрибутов методов обработчика.</div><div class="gmail_extra"><br><div class="gmail_quote">31 марта 2015 г., 3:31 пользователь PEF Secure <span dir="ltr"><<a href="mailto:pef-secure@yandex.ru" target="_blank">pef-secure@yandex.ru</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Monday, March 30, 2015 21:01:36 Maxim Vuets wrote:<br>
<br>
> Как по мне это плохая идея. А аргументация слабая и поверхностная.<br>
<br>
</span>Есть очень много плохих идей написанных "правильно". Аргументации, кроме<br>
наличия у меня положительного опыта, я не приводил, поэтому согласен, она<br>
слабая.<br>
<span class=""><br>
> Конечно, это только ваше дело что и как использовать. И вы, как я<br>
> понял из прошлого ответа, не очень расположены обсуждать основной<br>
> вопрос, потому я не буду продолжать.<br>
<br>
</span>Я мог бы обсудить что-то, поддающееся обсуждению. C-like макросы понятно будут<br>
выглядеть ужасно, поэтому используется Filter::Simple.<br>
<br>
Ладно, попробую, если не получится, свернусь. Существуют шаблонные куски кода,<br>
они небольшие, выполняют какие то проверки и должны заполнить значения каких-<br>
то переменных, которые используются в дальнейшем в основном алгоритме. Такие<br>
куски кода, я считаю, удобно написать один раз, не в виде функций, поскольку<br>
этим функциям придётся передавать множество аргументов, а их возвращаемые<br>
значения копировать туда-сюда или хешем -- это всё засоряет текст, замыливает<br>
глаз и мешает читать основной код. В итоге у меня получается система макросов,<br>
которые скрывают это всё, остаётся только смысл выполняемого действия.<br>
<br>
Например, как может выглядеть обработчик, отвечающий на запрос получения<br>
информации о текущем клиенте, чтобы знать кому веб-сайт должен сказать<br>
"привет":<br>
<br>
handler get user info : prolog(get_user) {<br>
        return {<br>
                name         => $user->name,<br>
                email         => $user->email,<br>
                last_login    => $user->last_login,<br>
                result        => "OK",<br>
        };<br>
        end_handler;<br>
}<br>
<br>
В данном случае, handler создаёт обработчик "состояния" сессии в POE, псевдо<br>
атрибут prolog вызывает генерацию части get_user, которая создаёт объект $user<br>
из переданного ключа веб-сессии и добавляет информацию о пользователе в<br>
текущий контекст, чтобы можно было его добавить в лог, end_handler завершает<br>
формирование функции, создавая обработчик результата. Если развернуть эти<br>
несколько строк в получаемый результат, то там будет строчек на 20 больше.<br>
Писать подобные обработчики, на мой взгляд, быстрее и проще, чем на "настоящем<br>
перле". Читать и проверять код тоже. Ещё плюс в том, что это ничего не стоит с<br>
точки зрения производительности, код генерируется один раз на этапе<br>
компиляции. Конкретно в данном случае, удобно видеть какие запросы требуют<br>
авторизованного пользователя.<br>
<br>
Побочный эффект такого "псевдо-языка" ещё в том, что когда я решил менять POE<br>
на EV+pre-fork, в коде проектов не придётся ничего менять, всё полностью<br>
совместимо.<br>
<span class="HOEnZb"><font color="#888888">--<br>
PEF Developer<br>
</font></span><div class="HOEnZb"><div class="h5">--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</div></div></blockquote></div><br></div>