PHPでCMSを書いています。 パート2

このベンチャーから私を思いとどまらせるために何度も試みましたが、私はまだ計画通りに続けています。 前の部分の各コメント、私は読んで考慮しました。 一部の人々の私自身の願いと、自分の自転車を回転させないという緊急の推奨事項の両方を満たしました。 私の意見では、 アイヌとフェザーのコメントが好きでした。これは、今日のCMSとフレームワークに欠けているものについて非常に建設的な意見です。 たとえば、ブログの使用方法を説明するのが非常に困難な人のために、ブログをすばやく簡単に作成するというタスクの実装は、本質的に非常に複雑です。 そして、そのようなタスクはますます頻繁に現れるので、私はこの考えに密接に対処することにしました。



ソーシャルネットワーク、Analytics API、およびエンドユーザー向けの情報技術の世界の現在の機能の他の「お菓子」の統合を実装することがどれほど便利か想像できますか？ 情報リソースのインターフェースをどの程度簡単かつ直感的に作成できますか？ かなり長い間、自分のアイデアと目標を説明し続けることができますが、これが起こっている間、進歩は進歩していません。つまり、時間は無駄になっています。 これについては、私の一連の記事の以下の部分で説明しますが、今のところは-ケースについてです。

プロジェクトのサブディレクトリ階層

• エンジン
  
  
  • サービス
  • システム
  
  
  
• モジュール
  
  
  • モジュール
  • ...
  
  
  
• 公開
  
  
  • ダウンロード
  • ...
  
  
  
• 見る
  
  
  • テーマ
  • ...
  
  
  

非常に多くの場合、大規模なプロジェクトで作業しているときに、稼働中のシステムの「重要な」コンポーネントを含む膨大な数のフォルダーに出会いました。 たとえばDjango / Symfonyについて言えないこと。 それぞれのフォルダーは、ある程度独自の自律的なコンポーネントを担当します。これは、最初は特定の目標を達成することを意味します。 他の多くのフレームワークでも同じことが言えますが、今ではそうではありません。



エンジンフォルダーには、システムクラスと、特定のタスクのパフォーマンスを提供するサービスが含まれます。



モジュールフォルダーには、ルーティング、構成ファイル、キャッシュファイル、特性の説明を持つコントローラーが含まれます。



パブリックフォルダーには、サーバーを直接発行することにより、クライアントが直接アクセスすることになっているファイルが含まれています。 つまり、ユーザーがダウンロードするファイル。



ビューフォルダーには、カスケードスタイル、スクリプト、sassソース、画像、およびその他の表示可能なメディアコンテンツの形式で必要なすべてのコンポーネントを含むテーマのフォルダーが含まれます。

建築

前の記事で、デザインパターンの無知に夢中になりました。 私の弁護では、設計パターンはすべての状況に適しているとは言えません。 たとえば、MVC / HMVCを使用すると、PHPでWEBアプリケーションを簡単に設計できます。 しかし、同じPattern FacadeまたはObserverを使用すると、全体像はそれほど明白ではなくなりますが、想像できます。



達成したいことをより視覚的に説明するために、Django（Python）でユーザー認証を実装する例を示します。

def auth_controller(request): user = authenticate(username=request.POST['username'], password=request.POST['password']) if user.is_active: login(request, user)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、私は多くの小さな詳細を省略しましたが、最も重要なことを見逃さず、達成したいと思います。 Django開発チームが示したように、現時点では承認/登録などを実装する必要があります。 CMSサービスがFacadeテンプレートに従って設計されている場合、かなり良い結果を達成できます。 この場合のすべてのチェック、エスケープ、検証はコントローラーで行われるべきではありませんが、よく見ますが、データがフィルターされ、タスクが完了するとすぐに結果が報告されるサービスで-プログラムサイクルが続行されるコントローラーに。 一見したところ、このような小さなことは、入力データ処理プロセスと不正確なタスク実行サイクルの不注意や無知のためによくある基本的なミスを容易にし、加速し、回避できるようにします。 したがって、CMSのサービスの実装に関しては、Facadeパターンが最も正しいという結論に達しました。



モジュール自体も同様の原則に従って実装されますが、いくつかの微妙な違いがあります。 多くの場合、基本的なAPIを実装する必要がありますが、CMSを使用することは、システム自体によって提供されない場合、かなり面倒で難しいタスクです。 したがって、各モジュールのエントリポイントはベースモジュールの親メソッド-" request "になり、その引数は、結果のヘッダーセットを変更する手段を含むオブジェクトになります。 したがって、コントローラーの主なタスクである特定の要求に対するサーバーの応答を変更するための、最も変更可能で便利なインターフェースを実現します。



良い例として、RSS実装：

 namespace Module/News; class RSS { public function request($request) { $request->response->headers['Content-Type'] = 'application/xml'; } public function route($router) { $router->map('^rss\.xml$', [$this, 'feed']); } public function feed($io) { return $this->service('Rss', $this->service('News')->getLatest(0, 50)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例はかなり粗雑であり、私が見せたいことの全体像を示しているわけではありませんが、前述したように、モジュールには明確にするためにコントローラーを格納できる特性を含めることができます。 また、モジュールが大きすぎる場合でも、ルーティング中に同じ名前空間から「Module / News / Feed :: xml」という形式のコールバックをルーティングすることを妨げるものはありません。

結論として

いつものように、私はあなたの建設的な批判を楽しみにしています。 次のパートでは、この記事へのコメントを考慮に入れて、すべての改訂、感謝、およびGithubリポジトリを投稿します。 最高！