- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
public function __construct() {
$this->em = \Zend_Registry::get('em');
$this->_pid = mysql_connect(
$this->em->getConnection()->getHost(),
$this->em->getConnection()->getUsername(),
$this->em->getConnection()->getPassword());
mysql_select_db( $this->em->getConnection()->getDatabase(), $this->_pid);
}
Follow us!
зачем?
по Zend Conventions называем классы по схеме A_B_C и кладем в папки A/B/C.php, после чего они находятся сами, что может быть проще?
Кроме того, зендовские классы все равно нужно патчить, если уж их использовать с AMF. По крайней мере - выбросить все ошибки и заменить на что-то свое (зендовские ошибки пишутся вместе с сериализованными сообщениями в один поток, и вместо того, чтобы что-то сообщить об ошибке превращают даже какую-то вменяемую другую информацию, которую туда же записали в месиво, которое нет возможности разобрать). Всю работу с файловой системой - тоже выбросить, ну и т.д.
Это скорее не вина Зенда а того человека, который туда эту библиотеку добавил: тем, кому нужна эта библиотека Зенд совсем не нужен, и, вполне возможно, что обратное тоже верно - я никогда не спрашивал.
поясню: скажем, у нас есть зендовский лоадер, и куча require_once - тогда все будет валиться. если же расширить зендовский загрузчик, чтобы искал, скажем, в нужной директории, а уж потом стандартным зендовским способом, и убрать require_once - оба способа хранения классов будут допустимыми
Особенно полезная вещь, когда имя класса который нужно загрузить указывает клиент (именно так это происходит в AMF).
> это тот же require, но плюс в том, что не нужно его писать, и не нужно знать точных путей
Это как раз и есть недостаток. Не просто нужно, а необходимо знать точные пути. Нужно обязательно писать что загружается. Иначе - см. выше.