20BEAR.Sundayでカスタムhostを利用するPHPBEAR.SundayはじめにBEAR.Sundayアドベントカレンダーの天重さんの記事ではカスタムスキームの登録でしたが、この記事ではhostの登録です。HTTPのURLでいえばプロトコルは変わらずホストが違う場合ということです。やりたいこと例えば社内で共通の処理を独立した形で公開し、複数のアプリケーションにまたがって利用したいことなどないでしょうか?最終的にアプリケーションからこんな感じで社内ライブラリのResourceを利用できたら便利そうですね。$this->resource->get('app://acme/article');ライブラリ(AcmeFramework)を作る各アプリケーションから共通機能を利用するためのブリッジになるような基盤の仕組みを作成します。このAcmeFrameworkはcomposerのパッケージとして各アプリケーションにインストールされる想定です。SchemeCollectionProvider標準ではResourceアクセスの際のスキーマやホストの解決のために、BEAR\Resource\Module\SchemeCollectionProviderが用意されていますので、これを参考にします。}}コストラクタで$appNameと$appNameAcme、$appInjectorと$appInjectorAcmeとそれぞれ2種類扱っているのは、ライブラリを利用するアプリケーションとライブラリ自体、それぞれ2つのBEAR.Sundayアプリケーションを扱うためです。AcmeFrameworkModule上記のSchemeCollectionProviderが実際に適用されるようにしたいと思います。アプリケーションからはModuleをインストールすることで利用できます。}}コンストラクタでAppMetaを色々操作しているのは、以下のような設定を実現するためです。何でも良いのですが、アプリケーションとバッティングしないように。tmpDir(キャッシュなどの一時ファイル置き場)アプリケーションに用意されたディレクトリ。{$appDir}/var/tmp/{$context}logDir(ログ置き場)アプリケーションに用意されたディレクトリ。上記Moduleをinstallするだけです。BEAR\Package\PackageModuleよりも先にinstallする必要があります。}}これで以下のようにアプリケーション内でライブラリのリソースにアクセスできるようになっていると思います。$this->resource->get('app://acme/article');おまけResourceの中でSQLを扱う場合、コードからインフラに関わるコード(MySQLやKVS、APIへのアクセスなど)を排除するためのRay.QueryModuleというものがあり、よくSQLのInjectで利用されていると思います。これが以下のようなルールで運用できたら更に処理の共通化がしやすいのではないでしょうか。アプリケーションに該当のSQLファイルが用意されていたらアプリケーションのSQLファイルを使うアプリケーションに該当のSQLファイルが用意されていなかったらライブラリのSQLファイルを使うつまり、sqlファイルの探索を優先順位がつけられた二箇所から行うようにするということです。以下のようにインストールします。引数で優先して探索するsqlディレクトリを指定します。upLoginユーザーは見つかりませんでした。