今年の ZendCon 中に、Zend Framework の 2.0.0beta1 をリリースしました。このリリースの重要なストーリーは、新しい MVC レイヤーの作成であり、ストーリーをさらに面白くするために、モジュラー アプリケーション アーキテクチャを追加することです。
「モジュラー？それはどういう意味ですか？」 ZF2 の場合、「モジュール」とは、アプリケーションが 1 つ以上の「モジュール」で構築されていることを意味します。 IRC ミーティング中に合意された用語集では、モジュールとは、アプリケーションまたは Web サイトの特定の基本的な問題を解決するコードとその他のファイルのコレクションです。
例として、技術分野の典型的な企業 Web サイトを考えてみましょう。あなたは次のようなことをしているかもしれません:
これらは個別のモジュールに分割できます:
さらに、これらが適切かつ個別に開発されていれば、異なるアプリケーション間で 再利用 することができます!
それでは、ZF2 モジュールについて詳しく見ていきましょう!
ZF2 では、モジュールは単なる名前空間ディレクトリであり、その下に単一の「モジュール」クラスがあります。それ以上もそれ以下も必要ありません。
例として:
リーリー上記は、「FooBlog」と「FooPages」という 2 つのモジュールを示しています。それぞれの下の「Module.php」ファイルには、モジュールごとに名前空間が設定された単一の「Module」クラスが含まれています: FooBlogModule andFooPagesModule。
推奨されるディレクトリ構造があります: リーリー 上記の重要な部分:
設定は「configs」ディレクトリにあります。
です。その構造内のモジュールは各サブツリーの目的を明確に示しているため、開発者は簡単にサブツリーをイントロスペクトできます。 モジュールクラス
前述したように、モジュール クラスはモジュールの名前空間に存在する必要があります。通常、これはモジュールのディレクトリ名と同じになります。ただし、コンストラクターが引数を必要としないこと以外に、実際の要件はありません。
リーリーそれでは、モジュール クラスは何をするのでしょうか?
モジュール マネージャー (クラス
) は 3 つの主要な目的を実行します:
ZendModuleManager
モジュールマネージャーがこれを行います。認識しているすべてのモジュールをループし、その構成を 1 つの構成オブジェクトにマージします。これを行うために、各モジュール クラスの
メソッドをチェックします。
getConfig() メソッドは、array または Traversable オブジェクトを返す必要があるだけです。このデータ構造には、トップレベルに「環境」、つまり ZF1 と Zend_Config で使い慣れた「production」、「staging」、「testing」、「development」キーが必要です。返されると、モジュール マネージャーはそれをマスター構成とマージするので、後で再度取得できるようになります。
通常、構成で以下を指定する必要があります:getConfig() method simply needs to return an array or Traversable object. This data structure should have "environments" at the top level -- the "production", "staging", "testing", and "development" keys that you're used to with ZF1 and Zend_Config
foo_blog.apikey = "..."
The easiest way to provide configuration? Define it as an array, and return it from a PHP file -- usually your configs/module.config.php file. Then your getConfig() method can be quite simple:
<span <code lang="php">
public function getConfig()
{
return include __DIR__ . '/configs/module.config.php';
}
</code></span>In the original bullet points covering the purpose of the module manager, the third bullet point was about module initialization. Quite often you may need to provide additional initialization once the full configuration is known and the application is bootstrapped -- meaning the router and locator are primed and ready. Some examples of things you might do:
url() view helper needs a configured router in order to work.The way to do these tasks is to subscribe to the bootstrap object's "bootstrap" event:
<span <code lang="php">
$events = StaticEventManager::getInstance();
$events->attach('bootstrap', 'bootstrap', array($this, 'doMoarInit'));
</code></span>That event gets the application and module manager objects as parameters, which gives you access to everything you might possibly need.
The question is: where do I do this? The answer: the module manager will call a Module class's init() method if found. So, with that in hand, you'll have the following:
<span <code lang="php">
namespace FooBlog;
use Zend\EventManager\StaticEventManager,
Zend\Module\Manager as ModuleManager
class Module
{
public function init(ModuleManager $manager)
{
$events = StaticEventManager::getInstance();
$events->attach('bootstrap', 'bootstrap', array($this, 'doMoarInit'));
}
public function doMoarInit($e)
{
$application = $e->getParam('application');
$modules = $e->getParam('modules');
$locator = $application->getLocator();
$router = $application->getRouter();
$config = $modules->getMergedConfig();
// do something with the above!
}
}
</code></span>As you can see, when the bootstrap event is triggered, you have access to theZend\Mvc\Application instance as well as the Zend\Module\Manager instance, giving you access to your configured locator and router, as well as merged configuration from all modules! Basically, you have everything you could possibly want to access right at your fingertips.
What else might you want to do during init()? One very, very important thing: setup autoloading for the PHP classes in your module!
ZF2 offers several different autoloaders to provide different strategies geared towards ease of development to production speed. For beta1, they were refactored slightly to make them even more useful. The primary change was to the AutoloaderFactory, to allow it to keep single instances of each autoloader it handles, and thus allow specifying additional configuration for each. As such, this means that if you use theAutoloaderFactory, you'll only ever have one instance of a ClassMapAutoloader orStandardAutoloader -- and this means each module can simply add to their configuration.
As such, here's a typical autoloading boilerplate:
<span <code lang="php">
namespace FooBlog;
use Zend\EventManager\StaticEventManager,
Zend\Loader\AutoloaderFactory,
Zend\Module\Manager as ModuleManager
class Module
{
public function init(ModuleManager $manager)
{
$this->initializeAutoloader();
// ...
}
public function initializeAutoloader()
{
AutoloaderFactory::factory(array(
'Zend\Loader\ClassMapAutoloader' => array(
include __DIR__ . '/autoload_classmap.php',
),
'Zend\Loader\StandardAutoloader' => array(
'namespaces' => array(
__NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__,
),
),
));
}
</code></span>During development, you can have autoload_classmap.php return an empty array, but then during production, you can generate it based on the classes in your module. By having the StandardAutoloader in place, you have a backup solution until the classmap is updated.
Now that you know how your module can provide configuration, and how it can tie into bootstrapping, I can finally cover the original point: the module manager aggregates enabled modules. This allows modules to "opt-in" to additional features of an application. As an example, you could make modules "ACL aware", and have a "security" module grab module-specific ACLs:
<span <code lang="php">
public function initializeAcls($e)
{
$this->acl = new Acl;
$modules = $e->getParam('modules');
foreach ($modules->getLoadedModules() as $module) {
if (!method_exists($module, 'getAcl')) {
continue;
}
$this->processModuleAcl($module->getAcl());
}
}
</code></span>This is an immensely powerful technique, and I'm sure we'll see a lot of creative uses for it in the future!
So, writing modules should be easy, right? Right?!?!?
The other trick, then, is telling the module manager about your modules. There's a reason I've used phrases like, "enabled modules" "modules it [the module manager] knows about," and such: the module manager is opt-in. You have to tell it what modules it will load.
Some may say, "Why? Isn't that against rapid application development?" Well, yes and no. Consider this: what if you discover a security issue in a module? You could remove it entirely from the repository, sure. Or you could simply update the module manager configuration so it doesn't load it, and then start testing and patching it in place; when done, all you need to do is re-enable it.
Loading modules is a two-stage process. First, the system needs to know where and how to locate module classes. Second, it needs to actually load them. We have two components surrounding this:
Zend\Loader\ModuleAutoloaderZend\Module\ManagerThe ModuleAutoloader takes a list of paths, or associations of module names to paths, and uses that information to resolve Module classes. Often, modules will live under a single directory, and configuration is as simple as this:
<span <code lang="php">
$loader = new Zend\Loader\ModuleAutoloader(array(
__DIR__ . '/../modules',
));
$loader->register();
</code></span>You can specify multiple paths, or explicit module:directory pairs:
<span <code lang="php">
$loader = new Zend\Loader\ModuleAutoloader(array(
__DIR__ . '/../vendors',
__DIR__ . '/../modules',
'User' => __DIR__ . '/../vendors/EdpUser-0.1.0',
));
$loader->register();
</code></span>In the above, the last will look for a User\Module class in the file vendors/EdpUser-0.1.0/Module.php, but expect that modules found in the other two directories specified will always have a 1:1 correlation between the directory name and module namespace.
Once you have your ModuleAutoloader in place, you can invoke the module manager, and inform it of what modules it should load. Let's say that we have the following modules:
<span modules/
Application/
Module.php
Security/
Module.php
vendors/
FooBlog/
Module.php
SpinDoctor/
Module.php
</span>and we wanted to load the "Application", "Security", and "FooBlog" modules. Let's also assume we've configured the ModuleAutoloader correctly already. We can then do this:
<span <code lang="php">
$manager = new Zend\Module\Manager(array(
'Application',
'Security',
'FooBlog',
));
$manager->loadModules();
</code></span>We're done! If you were to do some profiling and introspection at this point, you'd see that the "SpinDoctor" module will not be represented -- only those modules we've configured.
To make the story easy and reduce boilerplate, the ZendSkeletonApplication repository provides a basic bootstrap for you in public/index.php. This file consumesconfigs/application.config.php, in which you specify two keys, "module_paths" and "modules":
<span <code lang="php">
return array(
'module_paths' => array(
realpath(__DIR__ . '/../modules'),
realpath(__DIR__ . '/../vendors'),
),
'modules' => array(
'Application',
'Security',
'FooBlog',
),
);
</code></span>It doesn't get much simpler at this point.
One trick I've learned deals with how and when modules are loaded. In the previous section, I introduced the module manager and how it's notified of what modules we're composing in this application. One interesting thing is that modules are processed in the order in which they are provided in your configuration. This means that the configuration is merged in that order as well.
The trick then, is this: if you want to override configuration settings, don't do it in the modules; create a special module that loads last to do it!
So, consider this module class:
<span <code lang="php">
namespace Local;
class Module
{
public function getConfig()
{
return include __DIR__ . '/configs/module.config.php';
}
}
</code></span>We then create a configuration file in configs/module.config.php, and specify any configuration overrides we want there!
<span <code lang="php">
return array(
'production' => array(
'di' => 'alias' => array(
'view' => 'My\Custom\Renderer',
),
),
);
</code></span>Then, in our configs/application.config.php, we simply enable this module as the last in our list:
<span <code lang="php">
return array(
// ...
'modules' => array(
'Application',
'Security',
'FooBlog',
'Local',
),
);
</code></span>Done!
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
