数週間前、リードアーキテクトのジェイソンコワード（「opengeek」）は、中規模サイトでのMODXの将来に対するビジョンを共有しました。 この情報と他のオンラインディスカッションに基づいて、MODX 3について何を知っていますか？ 彼のステータスは何ですか？また、いつライブを見ることができますか？
正直なところ、まだ正確な答えはありません。 まとめることができる情報はほんの一部です。 MODX 3はまだ作成されていないため、多くの仮定と「高度な」仮定があります。 MODX 3は、始まったばかりの長期プロジェクトです。
まだMODX 3が必要なのはなぜですか？
多くの人が現在のバージョンのMODXを大いに活用しています。 このシステムにより、設計者とフロントエンド開発者は、競合他社とは異なり、最小限の労力とカーネルの変更で完全にユニークなサイトを作成できます。 現在のバージョンでも、ウェブサイトの開発は、今後何年もの間、シンプルで完全に実行可能なビジネスになります。 テンプレートと要素の非常に強力な言語、追加フィールド（TV）、および拡張機能-これらはすべて将来使用する準備ができています。
おそらく、MODX 3が必要な最大の理由は単なる数字です。 レガシーコードをクリアし、開発者に業界標準を満たす改善されたツールを提供するには、MODXシステムに重大な変更が必要になります。 また、MODXは
セマンティックバージョニングの原則に従っているため、重要な変更の実装時にメジャーバージョンを増やす必要があります。 MODX Revolutionのバージョン2がインストールされているため、バージョン3が必要になります。
では、MODXの現在のバージョンがまだ非常に関連性がある場合、なぜ重要な変更が必要なのでしょうか？ これは、MODXがPHPの世界の変化の流れに追従するために必要だと思います。 PHPコミュニティは、過去数年間で驚くほどのスピードで、より専門的かつ標準化されています（特に、
フレームワーク相互運用性グループ -互換性コンセプトグループおよび
PHP：The Right Way -PHP：right wayのようなイニシアチブのおかげ）。 この動きに参加することで、MODXカーネルコードは格段にクールになります（安定性、テスト可能性、および場合によってはボリュームの削減）。 逆に、MODXは他のPHP開発者にとってはるかに魅力的なプラットフォームになります。
開発の世界では、重大な変化が進行中です。 EvoからRevoへの例外的な飛躍により、MODXは実際にはより安定し、過去数年にわたって進化を続けましたが、特定の観点から、既存のコードが許可するすべてを超えるために重要なリリースが発生する必要があります。
症候群「それを発明したのは私たちではなかった」
多くの場合、MODXは「他者の開発の拒否」
（組織外で発生するすべてのイノベーションを意識的または本能的に無視する傾向-約翻訳者）の概念を使用して開発されました。 これは基本的に、コードの各部分が以前にMODXコミュニティ内で開発されていた場合、将来、外部コミュニティによって開発されたより標準化されたライブラリを使用できることを意味します。
Composerと
Packagistのおかげで、このような変更は近年、PHPコミュニティ内で発生しました。これにより、外部開発者のコードをできるだけ簡単に使用できるようになりました。
サードパーティ開発者のこのような外部ライブラリを接続することにより、個々のモジュールの完全にテストされたコード（ユニットテスト）を利用して、信頼性の高いアプリケーションをより速く、より良く開発することが可能になります。 現在、MODXには有用な単体テストがないため（
まだ多少の動きはありますが）、これはアーキテクチャとコード品質の観点から非常に重要です。
外部ライブラリを使用する前に、MODXコマンド内で以前に開発されたモジュールの例をいくつか示します。
- ジャーナリング。 現時点では便利なメソッド$ modx-> log（）がありますが、PSR-3インターフェースのサポートに従ってこのメソッドを変更すると、開発者はMonologなどのさまざまなロギングシステムにログエントリをダンプできます。 Monologシステムは膨大な数の優れたログ管理機能を提供し、MODXがPSR-3のサポートを開始すると、MODXカーネルを変更せずにそれらのいずれかをサポートできるようになります。
- ルーティング リクエストを正しい答えに変換することでかなりクールなことができるライブラリがあります。 以下のスリムフレームワークのセクションを参照してください。
- テンプレートシステム。 正直なところ、Revolutionのテンプレート言語は本当に好きですが、Twigのようなより「標準的な」ものを使用することは興味深い改善かもしれません。 いずれにせよ、Twigは他の多くのプロジェクトで使用されているため、これにより多くの人々の学習曲線が短縮されます。
これらは、既製の外部コードの再利用について話すときに思い浮かぶ非常に最初のものです。
スリムとは何ですか？なぜ使用するのですか？
ジェイソンは一連の記事「
MODXを最新の状態に保つ 」の第2部で、
スリムフレームワーク（バージョン3）がMODXカーネルで使用される可能性が最も高い候補であると述べました。 これは見過ごされませんでした-多くの人々はスリムを考え始め、それが何であり、どのように機能するかを考え始めました。
Slimについて知っておくべきことは次のとおりです。- Slimはルーターです。 要求（GET /マネージャー/リソース/更新など）を応答（リソースを更新するためのフォームなど）に変換します。
- Slimはミドルウェアパターン（ミドルウェア）をサポートしています。 このパターンを使用すると、基本的に、個々のリクエストを処理する多くのレイヤーと、次のレイヤーに到達する前にそれらを変更する機能を備えたレスポンスが得られます。 ミドルウェアパターンの技術的説明はこちらにあります 。 ミドルウェアパターンは、動作を拡張する非常に効果的な方法です。 Slim 3は、ミドルウェアの実装においてPHP FIGのPSR-7標準（ドラフト）を実際にサポートしています。つまり、PSR-7パターンをサポートするミドルウェアは、Slim 3で安全に使用できます。
- Slim 3はまだ開発中です。 言い換えれば、実際の製品での作業の準備はまだ整っていませんが、Slim 3コードは安定しているようです。
おそらく、SlimはMODXの現在の要求ハンドラーと応答ハンドラーの代わりになります。 ミドルウェアコードを追加する可能性を考えると、これは非常に柔軟で強力なシステムにつながります。
ManagerとExtJSはどうですか？
システムの最も愛されていない部分についてMODX開発者のランダムグループに尋ねると、おそらくExtJS（より一般的には「マネージャー」）になります。 現時点では、Managerについて明確な指示はありませんが、ExtJS 3.4へのバインドは明らかにすべきことではありません。 ExtJS 3は非常に古く、十分に高速ではなく、モバイルデバイスを適切にサポートしていません。 さらに、ExtJS 6は
アーリーアクセスですでに利用可能
であるため、ExtJS 3.4は更新されなくなりました。
そのため、Managerがどのように見えるか、または何に基づいて構築されるかはまだわかりませんが、これがExtJS 3にならないことは確かです。
しかし、私たちは何を知っていますか？JasonのコアライブラリとしてのSlimの選択、
Tacitプロジェクト（Slimに基づく「高性能RESTfulフレームワーク」）での彼の仕事、およびさまざまなIRCチャネルと
Slackでの議論を考えると、次のManagerがRESTful APIを取得するようですその基礎。 現在のManagerにもAPIがありますが、その構造は完全に標準化されておらず、一部の場所ではExtJSが期待するものを正確に目指しています。 間違いなくRESTfulではありません。
メインサービスとしてRESTful APIに移行する場合、バックエンドとインターフェースはコードの観点からさらに分離されます。 これにより、真にユニークなマネージャーの開発が容易になり、プラットフォームのこれら2つの部分が互いに独立したものになります。 デザイナーは第3版のManagerインターフェースの開発に集中でき、開発者はその間堅牢なAPIに取り組みます。
次は？
ジェイソンは、現在の将来のMODXに関する一連の記事の待望の第3部に取り組んでいます。 このパートでは、彼は持続可能性のトピックに関するビジョンを共有します-基本的に、データベースとの相互作用。 MODXアーキテクチャの場合、これは非常に重要な決定であるため、Jasonは結果を公開する前にいくつかの可能なオプションを準備しています。
現時点では、MODXの主な焦点はバージョン2.3と今後のバージョン2.4です。 MODX 3のリリースはエキサイティングで魅力的であることが約束されているため、新しいMODX革命の基本を決定する前に、ある程度の時間を費やすことが重要です。