Применяем делегирование совместно с наследованием для организации контроллеров действий

По такому принципу?

Class Common_EditActionHelper implements Common_IActionHelper
{
       protected $controller = null;
       
       public function __construct( Zend_Controller_Action $controller ) {
           $this->controller = $controller; 
       }
     
       public function execute()  {
            // логика из _editActionHelper()
       }
}

Class Common_Controller extends Zend_Controller_Action
{
       public function executeActionHelper( $action ) {
             $class = 'Common_' . $action . 'ActionHelper'; // опустим валидацию $action для наглядности
             $helper = new $class( $this );
             $helper->execute();  
       }

}

Class VideoController extends Common_Controller 
{
       public function editAction() {
           $this->executeActionHelper( 'edit' );
       }
}

Применяем делегирование совместно с наследованием для организации контроллеров действий

а можно получить гибкость

Применяем делегирование совместно с наследованием для организации контроллеров действий

В этом случае не нужные экшены будут доступны через веб, т.е. вы добавили новый контроллер Test — смотрите в него он пустой, а на самом деле, через веб доступны и /test/edit/, /test/add/ и т.д. добавили в базовый контроллер еще одни общий экшн и он сразу появился во всех контроллерах, даже в тех, где он не нужен.

Применяем делегирование совместно с наследованием для организации контроллеров действий

это фргагменты класса, в реале есть вариант «выйти без сохранения» со снятием блокировки.

Применяем делегирование совместно с наследованием для организации контроллеров действий

принцип хороший, но не слишком ли это радикально целый класс ради одного метода?

ORM в PHP быть или не быть?

согласен

ORM в PHP быть или не быть?

Далее например строим запрос с помощью qb — потом он разбирается. Спрашивается зачем?

— если запрос может быть гибким, поиск например, по многим полям в разных комбинациях.

ORM в PHP быть или не быть?

Есть еще очень популярные варианты — как yii/laravel/kohana/phalcon/propel, — последний вариант
а еще нет варианта с велосипедом — второй вариант

ORM в PHP быть или не быть?

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

так и было собственно

ORM в PHP быть или не быть?

интересный взгляд

ORM в PHP быть или не быть?

смущает тихая ленивость, которая скрывает ошибки, этого же можно добиться используя явный метод вроде loadText()

ORM в PHP быть или не быть?

я бы так не делал ). Была такая ситуация, в select() перечислил только необходимые поля (выборка ~150 записей), через несколько дней появилась необходимость вывести в шаблоне еще одно поле, про select к этому времени успешно забыл, но оно само заработало, доктрина не ругнулась, что поля нет, а тихо сходила в базу за ним… 150 раз ) поскольку база девеловская, без нагрузки, на глаз это почти не заметно, увидел случайно в профайлере.

Опрос. Как вы делаете деплой на production сервер(а)?

такую схему по-умолчанию предлагает Zend Framework, я правильно понял?

Опрос. Как вы делаете деплой на production сервер(а)?

а саму работу делают (архив, распаковка, выгрузка на ftp) делают собственные sh скрипты? Или для тимсити есть готовые плагины?

Опрос. Как вы делаете деплой на production сервер(а)?

естесно ))

Опрос. Как вы делаете деплой на production сервер(а)?

спасибо за ответы

Опрос. Как вы делаете деплой на production сервер(а)?

А кто использует deb пакеты, какими утилитами собираете?

Опрос. Как вы делаете деплой на production сервер(а)?

для многих php фреймворков по-умолчанию это одно и тоже ), в общем случае, конечно это папка где лежит весь проект.

Опрос. Как вы делаете деплой на production сервер(а)?

думал про них, но они сами по себе только предоставляют GUI, а так сказать транспорт для разливки, обычно более низкоуровневый или тот же bash скрипт или deb

Опрос. Как вы делаете деплой на production сервер(а)?

видел такой вариант: держат в руте svn копию, когда надо сделать релиз делают svn up. А если делать хранилище ВЫШЕ document_root, то дальше какой алгоритм? svn up потом экспорт в папку с новым релизом?