Пространства имен с Phalcon

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

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

следующее, что я сделал, чтобы получить все мои вещи организованы в папки и пространства имен, и по-прежнему использовать всю основу.

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

Phalcon vs пространства имен

OK, поэтому, если вы решили сохранить исходный код PHP, организованный в папках и пространствах имен, приготовьтесь настроить почти все основные функции, а также больше явный в ваших реализациях (i.e везде используйте полные пути классов).

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

но, несмотря на всю эту дополнительную работу впереди, я решил сохранить это дизайнерское решение; в конце концов, мы выбрали структуру MVC по какой-то причине, верно?! Мы хотим держать вещи организовано. Особенно в огромных проектах, где очень важно разбавить источник в нескольких пространствах имен / файлах для улучшения ремонтопригодности.

Структура Каталогов

во-первых, вы должны знать о структуре каталогов, которую я выбрал, чтобы понять, о чем я говорю ниже. Поверьте, я истратил немного!--36-->часа дней настройки этой структуры и чтение о структурах, рекомендованных другими фреймворками MVC и ведь моя личная рекомендация очень проста: выбирайте менее проблемную! Как правило, это означает более развязанный / фрагментированный.

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

четкое понимание структуры каталога / пространства имен удаляет значительное количество догадок при реализации новых материалов и помогает вам написать развязанный код невольно. Если вы "отходы" какое-то время думать об этом в начале, это означает, менее болезненным переделывает для вас в будущем.

Загрузчика Класс

вы заметили source/ папка и ее содержимое организовано более или менее как стандарты PSR требования?! Причина этого в том, что "Фэлкон" по загрузчика класс соответствует PSR-0;

поэтому в основном мне просто нужно зарегистрировать только source/ папка в загрузчик:

$phLoader = new PhLoader();
// Considering the public folder as your current __DIR__
$phLoader->registerDirs(['../source/']);
$phLoader->register();

...и вуаля! Вы просто ссылаетесь на класс (используя полный путь, когда это необходимо), и внутренние реализации PHP и Phalcon найдут его. Например, чтобы зарегистрировать один из моих компонентов в контейнере DI:

// At the first time the service 'foo' is needed
// Phalcon will read the file at 'source/MyApp/Components/Foo.php'
// and then call Foo's constructor
$di->set('foo', 'MyApp\Components\Foo'); 

маршрутизатор и контроллеры

если все контроллеры находятся в одном пространстве имен/папки вы можете просто сделать это:

$router->setDefaultNamespace('MyApp\Controllers');

приятно!

но что, если у вас есть контроллер под MyApp\Controllers\Foo\BarController?!

как и поведение загрузчика по умолчанию, маршрутизатор не пытается интерпретировать Foo часть как другой уровень пространства имен.

ATTOW нет обходного пути, чтобы сделать маршрутизатор для поиска контроллеров в" более глубоких " пространствах имен. Мое решение до сих пор-отключить поведение маршрутизации по умолчанию и добавить вручную четыре общие схемы for каждое пространство имен бранч.

под "четырьмя общими шаблонами" я подразумеваю следующие маршруты:

:namespace/index/index ^{_{когда определено только пространство имен}}

:namespace/:controller/index/ ^{_{когда определено только пространство имен и имя контроллера}}

:namespace/:controller/:action/ ^{_{когда пространство имен, контроллер и имя действия определены}}

:namespace/:controller/:action/:params ^{_{когда все определено и включает параметры}}

включить эти маршруты для всех пространств имен Я заменил :namespace regex заполнитель с другим regex, который соответствует всем возможным пространствам имен и реализован "конвертер", который переводит маршрут в правильное пространство имен (i.e "/ foo / bar / baz"--> ['namespace' => 'MyApp\Controllers\Foo', 'controller' => 'bar', 'action' => 'baz']).

чтобы проиллюстрировать, о чем я говорю, вот пользовательский маршрутизатор, который я написал некоторое время назад и использует это метод: https://gist.github.com/snolflake/9797835

модели

вы должны следовать, что документы говорят. Это означает, что каждый раз, когда вы ссылаетесь на модель на PHQL (или определения отношений) нужно всегда использовать полный путь к классу.

вид

на вид я имею в виду в основном шаблоне. Конечно, они не находятся под пространствами имен, но поскольку ваши контроллеры автоматический выбор вида не работает должным образом. Поэтому ваши представления следует выбирать вручную:

namespace MyApp\Controllers\Foo;

class BarController
{
    public function bazAction()
    {
        // The path is relative to the views dir you've set before
        $this->view->pick('configurations/subscriptions/index.volt')
        ...

С удовольствием вы можете использовать событие beforeExecuteRoute чтобы автоматически выбрать представление на основе ваших собственных соглашений.

вывод

кажется, что Phalcon стремится больше в простом / тривиальном проекте, но это вполне разумно и даже со всем этим шаблонным кодом, чтобы получить ваше приложение более причудливым фреймворк сам по себе делает все это стоящим работы позже.

между тем я просто надеюсь, что следующие версии включают в себя более удобные для пространства имен функции.