Отдельных классы action-ов выполняют не столько задачу по укорачиванию кода, сколько по унификации реализации функционала, используемого в разных частях приложения. По тонким контроллерам — поддерживаю, вся логика реализуется именно в моделях. Action реализует лишь связь между запросом и ответом, как бы это не было очевидно. Если есть множество контроллеров, с типичными в общих чертах реализациями action-ов, я думаю вполне обоснованно их реализовать в виде отдельных классов. Расширяемость класса может решить проблему частных случаев. Если же реализовать определенный функционал в контексте класса action-a не получается, его можно и не использовать.
Action каптчи, как и action обработки ошибки в основном подключаются в одном единственном контроллере на всё приложение. Для виджета каптчи можно указать адрес обработчика каптчи. В данной статье они приведены как пример механизма standalone action.
Форм билдер не использует скорее из-за его неочевидности.
По нижнему подчёркиванию у защищённых свойств классов, да, каюсь, давняя привычка обозначать таким образом видимость свойства.
Action каптчи, как и action обработки ошибки в основном подключаются в одном единственном контроллере на всё приложение. Для виджета каптчи можно указать адрес обработчика каптчи. В данной статье они приведены как пример механизма standalone action.
Форм билдер не использует скорее из-за его неочевидности.
По нижнему подчёркиванию у защищённых свойств классов, да, каюсь, давняя привычка обозначать таким образом видимость свойства.