is_subclass_ofを使う場面

is_subclass_ofというメソッドを見つけました。機能は、指定したクラスを継承しているかを判定してくれるというものです。

instanceofやis_aメソッドを使った判定と同じイメージです。違いはinstanceofやis_aがオブェジェクトだけを判定できるのに対して、is_subclass_ofはクラス名について判定することができます。

クラスからオブジェクトを生成する前に判定が可能ということです。

複数のプログラマが利用する共通部を作成するような場合に使えそうです。今回は、あるディレクトリ配下のクラスファイルを全て読み込んで、特定のクラスを継承しているクラスのみ生成するという処理に利用しました。

誤ったファイルを置かれても、不具合が出ないための対応ですが、ちゃんと作れとか、ルールが明記してあるドキュメントを整備しろとかあるとは思いますが、これはこれでいい対策かなと思います。

advanced custom fieldsがプレビューに対応していた

以前、advanced custom fieldsプラグインでプレビューもやりたいという記事を書きましたが、最新版ではプレビューにも対応していました。

プラグインをアップデートしたら、以前の記事に書いたプレビュー対応の部分でエラーがでたため、一旦外したところ、外した後もプレビューできていました。これからは、プラグインを有効化するだけで、プレビューにも対応可能ですね。

手間が減るって嬉しいことです。中身がどう変わったのかも、見てみようと思います。

Zend_Framework1のDbMetaキャッシュ設定をapplication.iniで行う

ZendFramework1は、DBアクセスする際に、DbMeta情報を取得します。
MySQLだと、describeで取得できるテーブルの構造です。
この情報は、あまり変わらないのでキャッシュすることで、性能アップが実現できます。

以前、“ZendでDbのMeta情報をキャッシュする”という記事で書かせて頂いたように、Bootstrapの中で定義していました。

    protected function _initDbCache()
    {
        $frontendOptions = array('automatic_serialization' => true);
        $backendOptions = array('cache_dir' => APPLICATION_PATH . '/../cache/db');
        $cache = Zend_Cache::factory('Core', 'File', $frontendOptions, $backendOptions);
        Pb_Db_Table_Abstract::setDefaultMetadataCache($cache);
    }

これ、application.iniに設定を書くことで、全く同じことが実現できました。
問題無く動いていたし、Bootstrap自体が修正が入ることが少なかったので、気づきませんでした。
以下のように、記述することで、ソースコードを書く必要がなくなります。
書かなくていいものは、書かない方がいいですよね。

; dbメタキャッシュ設定
resources.cachemanager.db.frontend.name  = "Core"
resources.cachemanager.db.frontend.customFrontendNaming = false;
resources.cachemanager.db.frontend.options.lifetime = 7200
resources.cachemanager.db.frontend.options.automatic_serialization = true
resources.cachemanager.db.backend.name = "File"
resources.cachemanager.db.backend.customBackendNaming = false;
resources.cachemanager.db.backend.options.cache_dir = APPLICATION_PATH . '/../cache/db'
resources.cachemanager.db.frontendBackendAutoload = false

Zend_Framework2では、どんな設定方法になるんだろう。
まだ触っていないので、書くことはできませんが、わかったら書きたいと思います。