MODx Revolutionのプロセッサプログラミングパラダイム

この記事が推論であり、思考の糧であることを直ちに予約してください。 私は絶対にホリバーを手配し、他の人に私のプログラミング方法を課したくありません。 私は自分自身に、過去1年間に使用したプログラミング方法が大きく変わっており、過去数年間の方法とは根本的に異なっていると感じているため、お伝えしています。



この記事では、MODx Revolution全体がプログラミングに対する私のアプローチをどのように変えたかを説明したいと思います。

誰がどのようにプログラムするのかわかりませんが、私はずっと前にOOPメソッドを使ってプログラミングしてきたと思います。 一般的に言えば、プログラミングは何でしたか? 私は自分のタスクのためのクラスを作成しました(または既製のクラスを取りました)(データベースを操作するためのクラス、テンプレートを操作するためのクラス、他の何かのためのクラス)。 ほとんどのクラスは非常に大きく、プロファイルで多くの必要なタスクを実行しました。 多くの場合、プロジェクトが拡大するにつれて、多くのクラスが拡大するか、拡張機能を取得します。 何らかの方法で、次の変更を加えることができる場所を見つけ出すために、数千行と数十のメソッドでオブジェクトを分析する状況に出くわしたと確信していますが、他のものは壊れません。 しかし、私の意見では、最も難しいことは、特に特定のアクションを実行するときにエラーをインターセプトするという点で、さまざまなオブジェクト間の調和した相互作用を確保することであり、最も重要なことは、エラーの時点で、それがどれほど重要であり、実行プロセスを中断する価値があるかどうかを決定するか、さらに進めることができるかどうかです また、ここでは、サーバー部分(テンプレートへのさらなるレンダリング)およびAjax要求の実行応答を標準化するために、クライアントサーバーソリューションを割り当てます。



MODx Revolutionは、プロジェクトロジックのプログラミングにどのようなツールを提供していますか? 2つのクラスのみがあります:Processor(modProcessorクラスによって実行される)およびConnector(modConnectorクラスによって実行される)。

これは何ですか プロセッサは、ほとんどの場合1つまたは複数の小さなタスクを持つ個別のファイルであり、その結果、回答は肯定的(実行の肯定的結果を示す)のみ、または否定的(できれば特定のエラーメッセージ)である必要があります。重大な問題が発生しました。



例を挙げましょう。 新しいドキュメントを作成します。 文書が作成された場合は、そうでない場合はエラーメッセージを取得する必要があります。



1. core / model / modx / processor /にプロセッサ用のフォルダを作成し、たとえば、assets /

2.プロセッサフ​​ァイルdoc / create.phpを作成します(フルパスはcore / model / modx / processor / asset / doc / create.phpになります)

3.必要なコードを書き込みます
<? if(!$scriptProperties['pagetitle']){ return $modx->error->failure('    '); } if(!isset($scriptProperties['parent'])){ return $modx->error->failure('     '); } $doc = $modx->newObject('modResource', scriptProperties); if(!$doc->save()){ return $modx->error->failure('   '); } return $modx->error->success('  ', $doc->toArray());
      
      







4.そして、必要な場所で、このプロセッサを呼び出します
 $response = $modx->runProcessor('assets.doc.create', array( 'parent' => 0, 'pagetitle' => ' ' )); if($response->isError()){ print " ". $response->getMessage(); } else{ $object = $response->getObject(); print "    ID {$object['id']}"; } /*$modx->runProcessor -   MODx.   .php     ,       create.php  -  .      assets.doc.create   ,       assets/doc/         core/model/modx/processors/       ,       $modx->runProcessor($path, $properties, array( processors_path => self::$processorsPath));    $properties -  ,          scriptProperties.       .       $modx,            . */
      
      







これは個人的な例であり、私が言いたかったことについても明らかにしていません。

ネストされた複数のプロセッサを一度に使用すると、この方法を使用する利点がより明確になります。

ここでは、他のプロセッサが呼び出されるプロセッサを呼び出します(呼び出されたプロセッサのコードが提供されます)。
 <? $user = false; $doc = false; //    $response = $modx->runProcessor('security/user/create', $scriptProcessor); //  ,      if($response->isError()){ return $modx->error->failure($response->getMessage()); } else{ //    $user = $response->getObject(); } //   ,      $response = $modx->runProcessor('assets.doc.create', array( 'parent' => 0, 'pagetitle' => ' ' )); // -,  ,      if($response->isError()){ return $modx->error->failure($response->getMessage()); } else{ //    $doc = $response->getObject(); } //   ,   return array( 'success' => true, 'message' => '', 'object' => array( 'user' => $user, 'doc' => $doc, ) ); /*  ,        $modx->error->success(failure),    .         ,    $response->getObject()      ,     .  $modx->error->success('', $object);    .    $modx->error->success    ,               ,          .       ,    security/user/create   $user->toArray(),   $user,       $user,   .           modUser  ->toArray()      'object',    ,       $response->getObject()->get('id'); */
      
      





したがって、出力では、明確な結果、または$ response-> isError()を取得します。

同時に、これらのプロセッサの入れ子の程度については考えません。プロセッサの入れ子のレベルが何であっても、適切な実行の組織で、エラーの入れ子のレベルに関係なく、$ modx-を返すため、それについて知り、テキストメッセージを表示します>エラー->失敗($応答-> getMessage()); 毎回、次の組み込みプロセッサのメッセージを返します。



MODxのadmin部分全体がプロセッサー上に記述されていることに注意する必要があります(/ core / model / modx / processor /フォルダーを参照)。プロセッサーが正しく使用されている場合、多くのサードパーティパッケージはまったく必要ないかもしれません。

$ modx-> runSnippet( 'security / login'、$ scriptProcessor)よりシンプルなものは何ですか?

MODxは必要なすべてを実行し、その場合はすべての場合に規定されたエラーメッセージの1つを返します。 これらのプロセッサでは、アクセス権、すべての種類のシステム変数、および他の関連するプロセッサへの呼び出しをチェックします。 一般的に、必要なものはすべて...



したがって、小さなアクションごとに、必要なプロセッサを作成し、より広範なタスクを実行するために、ヒープ内の個々のプロセッサを収集します。

まず、これらの個々のプロセッサは理解しやすいです。 彼らは、何が行われていて、タスクの論理的な完了がどこにあるかを明確に理解しています。 おそらく最も重要なことは、if、elseなどの不必要な分岐よりも少ないことです。これらのif-elseは、時には数百(または数千)のコード行に達することがあるためです。

次に、1つのプロセッサの障害は、コードまたは何かの解析エラーによる1つの大きなクラスの障害と比較して、サイト全体の動作に与える悪影響がはるかに小さくなります(もちろん、これは通常のプログラマーには理解できませんが、それでもすべてが起こります)。

しかし、第三に、一般的に、そのような実装を備えたエンジンは、はるかに簡単かつ直感的にサービスされます。



しかし、このアプローチのもう1つの非常に強力な利点は、サーバー側とブラウザー(Ajaxを使用する場合)の両方で標準化された回答が得られることです。

必要なプロセッサが呼び出されるコネクタに要求を送信すると、応答はJSONオブジェクトとして返され、成功するとメッセージとオブジェクトが返されます。

これにより、サーバーロジックと擬似クライアントの両方に同じプロセッサを使用できます。

興味がある場合は、後でコネクタについて詳しく説明します。



All Articles