まずZend Frameworkについて。 マニュアルの特別なセクションには、すべての必要なモジュールがリストされ、モジュールとフレームワークのクラス間の特定の依存関係が示されています。 依存関係には2つのタイプがあります:ハード(一部のクラスまたはフレームワーク全体が拡張機能に厳密に依存しており、拡張機能なしでは機能しない場合)と、拡張機能がパフォーマンスを向上させるためにのみ使用される場合(機能が利用できない場合はPHPコードを使用してエミュレートされる)
リスト全体を手動で確認した後、Oracleデータベースサポートなどの非常に特殊なモジュールを除くすべてのモジュールを選択し、テストスクリプトの配列に入れました。
はい、互換性を確認するために、QuercusPHP環境で実行され、利用可能な機能とインストールされたモジュールに関するすべての情報を収集し、ZFに必要なリストと比較するテストスクリプトを使用することにしました。
get_defined_functions PHP関数を使用して、実装されたPHP関数の完全なリストを最初に取得しました。これは、Quercusで1342でした。いくつかのユーティリティと特定の機能(たとえば、Javaと樹脂プレフィックス付きのいくつか、およびQuercusモジュール)がありました。 ところで、同じ方法で、同じモジュールでPHPを収集し、すべての機能の実装の完全性を確認する必要がありますが、これは次のテストのタスクです。
次に、関数とモジュールを手動で照合することは、他のことを行うため、環境に実装されているモジュール(拡張機能)の正確なリストを取得する必要がありました。 マニュアルには、関数get_loaded_extensionsがあり、上記の関数と同様に、スクリプトで使用可能なモジュールの配列を表示します。 QuercusPHPの拡張機能のリストは非常に大きく、31モジュールであることがわかりました。 実装された拡張機能に関する公式ドキュメントは一般的な用語でのみ書かれているため、完全なリスト(最新バージョンの3.2.1)を提供します。
mcrypt、SPL、curl、gd、mysqli、mhash、gettext、json、apc、mbstring、tokenizer、pgsql、memcache、zip、標準、ハッシュ、XMLWriter、ctype、xml、bcmath、postgres、PDO、pcre、zlib、session、 SimpleXML、Reflection、ereg、iconv、oci8、mysql
私はまだ各モジュールのすべての機能の実装の程度について詳細な調査を行っていませんが、おそらくこれは次のテストになるでしょうが、一見すると、SPLモジュールに混乱しました。 したがって、このモジュールの完全な実装の質問はまだ開いています(執筆中に、ソースコードを調査することにしました。質問は削除されました-すべての機能が実装されているようです)。 APCキャッシュが「箱から出して」すぐに実装されたことを嬉しく思いましたが、これは特にサイトで強調されました(EHCacheやJBossキャッシュなどの分散キャッシュと永続キャッシュのサポートを導入したいと思います)。 mb_stringモジュールがありますが、実用的な価値はあるように思えますが、通常のPHPとは異なり、QuercusPHPは最初は内部でUTFを完全にサポートしているため、この場合はPHP 6で期待されるものを既に実装しています。有効にするには、設定でオプションを設定する必要があります(より正確には、unicode.semanticsおよびscript-encoding)。 モジュールのリストにMemcached拡張機能があるのは嬉しかったですが、詳細に見てみると、関数のリストがありませんでした-APIがソースコードに含まれているため、実装されたメソッドのリストを取得する機能自体が奇妙である可能性があります
Zend Frameworkの依存関係のリストに何があり、何が欠けているのかを調べることは今でも残っています。 テストスクリプトには、2つの配列があります。1つはQuercusPHPにあるモジュールのリスト、もう1つはZFに必要なモジュールのリストです。 彼らのビジネスを比較するのは簡単であり、出力では欠落している5つのモジュールを取得します。
- バイナリデータのビット単位の操作用に設計されたビットセットモジュール。 実際、このモジュールの損失は最悪ではなく、Zend_Search_Luceneだけがそれに依存しています。さらに、Soft、つまりクラスが独立して機能を実装しています。 とにかく-すでにJavaプラットフォームを使用している場合、ネイティブJava Luceneを使用すると、より多くの機能があり、速度が大幅に向上します。
- Zend_Feed、Zend_Rest_Server、Zend_XmlRpc、およびいくつかのZend_Serviceモジュールなど、多くのクラスがすでに依存しているDomモジュール。 これらのモジュールはすべて非常に重要であるため、これらのモジュールがなければZFの魅力は一般に大幅に低下します。 モードに加えて、このモジュールの説明があるリンクから判断すると、SimpleXMLElementからDomオブジェクトを受け取る関数dom_import_simplexmlが 1つしかありません。 ただし、SimpleXMLモジュールは完全に実装およびサポートされています。 PHPでこの関数を手動で記述することは難しくないので、依存症を取り除くことができます。 また、優れたソースコードがあり、その構造が非常にシンプルで明確なので、Javaを知っている人はさらに進んでこのモジュールをエンジン自体に追加できます。
- libxmlライブラリーはすでにより複雑であり、多くのシステム機能が同じDomモジュールとSimpleXMLに依存していますが、このモジュールなしで実装する方法は興味深いものです。 ただし、 LibxmlJポートがあるか、他のパーサーを使用して、欠落している関数のラッパーを作成します。特に、XMLを操作するためのすべてがすでに存在するため、特定のAPIのみが異なります。 すでに何かがありますが、XMLの場合はJavaでも問題はないようです。 しかし、ここではいくつかの手作業と外部ライブラリの魅力がすでに必要です。 したがって、ZFに実際に必要であるが、欠落している最初のモジュールが検出されます。
- HTTPリクエストからデータのMIMEタイプを決定するmime_magicモジュールは、Zend_Http_Clientモジュールのみを必要とします。これは非常に具体的であり、まじめに使用されることはほとんどないと思います。 はい、モジュールには1つの関数しかありません。QuercusPHPソースを使用してラッパーを書くのは簡単だと思います。
- posixモジュールはZend_Mailに必要であり、おそらく、javaに転送するのが難しい唯一のものです...よく見ると、特にPOSIX-APIをJavaに転送するプロジェクトがいくつかあります(たとえば、 この1つまたはEasy Posix Toolkit )。すべてではなく、Zend_Mailに必要なものだけです。 おそらく、おそらく最良のオプションは、依存関係を取り除くためにZend_Mailモジュールを書き換えるか、まったく使用しないことです。 ちなみに、書き換えはそれほど難しくありません-posix_getpid関数にのみ依存し、そのような関数がない場合はコードに回避策があります。
したがって、これらすべてに基づいて、Dom / libxmlのみに存在する重大な障害のうち、残りはフレームワーク自体によって自動的にバイパスされるか、Javaクラスを直接操作する機会があるため、より高度なアナログに置き換えることができると結論付けることができます。 まず、Zend_Search_Luceneを捨ててJava Luceneから直接APIを使用することをお勧めします。または、ZFからインターフェイスを実装するコンポーネントを作成し、内部でJava Luceneを使用します。 しかし、これは大変な作業であり、Solrのようなものを使用した方がよい場合もあります。
原則として、Zend Frameworkのような強力で複雑なサードパーティ製アプリケーションやフレームワークをQuercusPHPで実行することは不可能ではありませんが、バランスの取れたアプローチと依存関係の分析が必要です。 QuercusPHPのソースコードに夢中になって、Javaの平凡な知識を持っている私でさえ、必要に応じてAPIを拡張することは非常に簡単であるという結論に達しました。
次の調査では、関数の完全な実装を詳しく調べ、QuercusPHPとPHP 5.2.8のバイナリバージョンを同じ拡張機能セットと比較します。