序章


シリーズは、コハナとそのインストールプロセスについて説明することから始めました。 フレームワークは追加の構成や変更を必要としないため、Kohanaフレームワークを使用してWebアプリケーション開発の基本を学ぶ準備ができています。

このDigitalOceanの記事では、Kohanaがその最も重要な部分とともにどのように機能するように設計されているかを理解することに飛びつきます。 HMVC(Hierarchical Model View Controller)パターンを調べて、それぞれを作成する方法を学び、それらを連携させます!

注:これは、フレームワークの操作に焦点を当てた、Kohanaシリーズの2番目の記事です。 インストールに関する最初の情報については、コハナ入門をご覧ください。 コハナベースのWebアプリケーションのデプロイについては、コハナベースのPHPWebアプリケーションのデプロイをご覧ください。

用語集


1. 設定より規約


2. コハナの選択とその慣習


1. File Naming
2. Coding Style

3. コハナとMVCパターン


4. コントローラー-MVCパターンの「C」


1. Conventions
2. How does it work?

5. 行動


1. Conventions
2. How does it work?

6. モデル-MVCパターンの「M」


1. Conventions
2. How does it work?

7. ビュー-MVCパターンの「V」


1. Conventions
2. How does it work?

8. ルーティング


1. Conventions
2. How does it work?

9. コハナでのエラー処理


1. Registering HTTP Error Page Controllers
2. Throwing HTTP Errors

10. セッションとCookie


1. Sessions
2. Cookies

設定より規約


アプリケーションプログラミングでは、規約より規約(または規約によるコーディング)は、特定のタイプの設計(つまり、 アプリケーションの構造化/モデリング)これにより、アプリケーションは、構築されるコードがルールとコア命令を尊重することを信頼します(つまり、 モデルとコントローラーを自動的に接続します-名前を使用して識別します)。

このアプリケーション開発パラダイムは、従来のファイルベースの構成(例: config.xml)。 これは、すでに確立されている規則に従って[アプリケーションを形成する]コンポーネントに基づいており、スムーズに動作するため、追加の構成が不要になります。

コハナはこの概念に厳密に依存しているため、フレームワークを操作するのが最も簡単で簡単なものの1つです。 コハナの規則(そして非常に重要なのはコーディングスタイルを含む)に従うと、すべての作成と保守が簡単になります。

コハナの選択とその慣習


ファイルの命名


PHPによる必要なファイルの自動ロードを容易にするため(つまり、 後で作成されるもの)、コハナは厳密なスタイルを使用します。 PSR-0 Autoloading Standard に従って、クラス名の最初の文字は大文字になり、アンダースコアはそれを形成する各単語を区切るために使用されます。

例:

#  Class Name             -     Class File Location
1. MyClass                      classes/MyClass.php
2. Controller_ClassOne          classes/MyWork/ClassOne.php
2. Controller_ClassTwo          classes/MyWork/ClassTwo.php

注:慣例により、すべてのクラス定義ファイルは、 classes ディレクトリ。

コーディングスタイル


厳密に必要というわけではありませんが、上記の理由から、コハナはコードの記述に関してはBSD/Allmanスタイルを使用することをお勧めします。

このプロセスは、独自の行に中括弧を付けることで構成されます。

例:

// for (int i=0; i<x; i++)
if (a == b)
{
    proc1();
}

finally();

注:クラス名に続く中括弧は同じレベルになります。

例:

class MyClass {
// ...
// ..
/  .

覚えておいてください:コハナの慣習について詳しくは、ここにあるドキュメントを参照してください。

コハナとMVCパターン


このセクションと次の関連セクション(コントローラー、アクション、モデル、ビュー)は、Kohanaを使用したアプリケーション開発の基本の最初の主要部分、つまり要求を処理するためのプロシージャ(関数)の作成を形成します。 この後のセクションでは、他の重要な領域について説明します(例: ルートの定義、エラーの処理など)。 本番環境に対応したアプリケーションの構築に進む前に、これらの例をドロップレットでできるだけ試してみることをお勧めします。

詳細に説明したように、Kohanaは(H)MVCパターンを使用してリクエストを処理します。 コハナを使用して開発されたアプリケーションは、スムーズに動作するプログラムを作成するために、このスタイルに可能な限り完全に従うことをお勧めします。

コントローラ-MVCパターンの「C」


コントローラは、着信要求の処理の主要部分の1つを構成するプレーンテキストファイルです。 MVCパターンを形成する残りの部分を接着し、それらすべてを連携させて応答を作成して返します。 各着信要求は、ルーティングされた後、一致するコントローラーに渡され、アクションを呼び出すことによって処理されます(例: print_names)。

コンベンション


コハナの規則はそのコントローラーにも適用されるため、各コントローラーは次のことを行う必要があります。

  • 下に存在 classes/Controller/*.

  • その名前をファイル名と一致させます(つまり、 Controller_Name 中身 classes/Controller/ なので Name.php).

  • 残りの命名規則とスタイル規則に従ってください。

  • 親のControllerクラスを拡張します。

例:

# Each one of the below examples represent the top -
# section (definition) of a class on a single [class] file. 

# Example [1]
// classes/Controller/ClassOne.php
class Controller_ClassOne extends Controller {
    
# Example [2]
// classes/Controller/Namegroup/ClassOne.php
class Controller_Namegroup_ClassOne extends Controller {

# Example [3]
// classes/Controller/ClassTwo.php
class Controller_ClassTwo extends Controller_ClassOne {

それはどのように機能しますか?


コントローラは以下のように機能します。

  • Request -コントローラーは、オブジェクトとしてラップされ、[object]変数にアタッチされたリクエストデータを受信します $this->request.

  • モデルあり-コントローラーは、データベースとデータオブジェクトを変更するためにモデルに情報を渡し、モデルからデータを要求/受信してデータを処理します(ビューを通過する可能性があります)。

  • ビューあり-コントローラーは、リクエストで受け取った情報とモデルからのデータを処理した後、この情報をビューレイヤーに渡して、プレゼンテーションとともに最終応答を返します(つまり、 景色)。

  • Response -コントローラーは、によって定義されたオブジェクト[変数]としてラップされた最終応答を返します。 $this->response (例えば 最終ビュー本体は、を介して設定できます $this->response->body($my_resp).)

行動


アクションは[公開]手順です(つまり、 関数)クラスの下で定義されます。 これらは、処理する要求の呼び出し可能オブジェクトで構成されています。

コンベンション


コハナの慣例により、アクションには次のものが必要です。

  • action_ 名前の前にプレフィックスを付けます。 (すなわち action_print_names).

  • public 分類(つまり public function action_print_names()).

  • $this->response->body($view) 実行サイクルの最後に設定して、ユーザーにビューを返します。

注:アクションには2つの主要な例外があります。 これらは:

  • before(public function before())-コードをbeforeすべて実行するために使用されます。

  • after(public function after())-コードをafterすべて実行するために使用されます。

モデル-MVCパターンの「M」


Kohanaのモデルは、データベース(または任意のデータソース)のすぐ上のレイヤーを表すオブジェクトを形成/含むクラスまたはその他のデータを含むプレーンテキストファイルです。 これらの種類のオブジェクトの明確な性質(つまり 実際のデータを表すために使用されるもの)は、データの直接作成、変更、更新、または削除に関連するすべての手順を分離できるようにすることで、モデルをMVCパラダイムの完璧な部分にします。

コンベンション


慣例により、モデルの下で定義されたクラスは、コントローラーと同様に、次のことを行う必要があります。

  • の下にが存在します classes/Models/*.

  • その名前をファイル名と一致させます(つまり、 Model_Name 中身 classes/Model/ なので Name.php).

  • 残りの命名規則とスタイル規則に従ってください。

  • 親のModelクラスを拡張します。

それはどのように機能しますか?


通常、モデルはオブジェクトリレーショナルマッパー(ORM)ソリューションを使用して、データとそれを操作する方法をコントローラークラスに公開します。 Kohanaには、非常によく構造化されたオブジェクトを設計および作成できる独自のORMモジュールが付属しています。

コマンドを受信すると(場合によってはさらに変数を使用して)、モデルは必要なアクションを実行して、データの要求に対する応答を送り返すか、指定されたものでデータベースを更新します。

ビュー-MVCパターンの「V」


ビューファイルは、最終応答の表現に関連するすべてのものを形成します。 もちろん、これらのファイルにはサードパーティのリソースが直接含まれていません(例: 画像またはその他の実行時の依存関係); ただし、これらはエンドユーザーに提供されるものの基盤を形成します。 WebベースのAPIを設計している場合は、ビューを使用して、保守が容易な構造化された方法で目的のデータを返すことができます。 (例えば ajaxリクエストに対するjsonの応答)。

ビューを操作するときは、表示するデータをビューファイルから変更する論理的な操作をすべて行わないようにするのが最善です。 データの表示方法を形成するために、ビューを(可能な限り)使用する必要があります。

コンベンション


  • ビューファイルは下に存在する必要があります views/ ディレクトリ(例: views/login.php)

  • それらは可能な限り「ダム」でなければなりません。

  • 表現を形成するために提供されたデータを使用する以外の目的で使用しないでください

それはどのように機能しますか?


最終的なビューを形成するために、コントローラーは特定のペイロード(データ)をビューファイルに渡します。ビューファイルはそれらを通過します(例: リストを反復処理して、テーブルの列を形成します)。 すべて(ペイロード/データが処理されたテンプレートファイル)をコンパイルした後、ビューの表現は、要求への最終応答としてコントローラーによって転送されます。

ルーティング


コハナシリーズの最初の記事で図解して説明したように、各リクエストは解析(処理)されてルーティングされます。 これが機能する方法は、主にアプリケーションでルートがどのように定義されるかによって決まります。

これらの要素はパターンを形成し、リクエストペイロードで呼び出すアクションを決定するために(書き込まれる順序で)リクエストと照合されます。

コンベンション


独自のモジュールを厳密に開発している場合を除き、ルートは通常、 bootstrap.php ファイル-最後に。

これらのルーティングメカニズムの定義は、機能する方法が非常に柔軟で寛大です。おそらく、存在する中で最も柔軟です。 それらを使用して、正しいスキーマに従うだけで、非常に簡単に優れた成果を達成できます。

  • すべてのルート名は一意である必要があります。

  • デフォルトルートの前に定義する必要があります。

  • 特別なトークンパラメータを含めることはできません((), <>).

例:

# Route Syntax: set([name], [pattern])
# Pattern Syntax: (.. item ..)  <- optional elements,
                  <controller>  <- match a  controller,
                  <action>      <- match an action,
                  <id>          <- request variable
                  
# Example [1]
Route::set('default', '(<controller>(/<action>(/<id>)))')
->defaults(array(
    'controller' => 'Welcome',
    'action'     => 'index',
)); 

# Route explained:
# By default, match all requests - optionally with:
#                                  /controller, and,
#                                - optionally with:
#                       /controller/action,     and,
#                /controller/action/id
# Use controller "Welcome" by default if none other matched,
# Use action "index" by default if one is not matched.

# Example [2]
Route::set('logops', '<action>',
array(
    'action' => '(login|logout)'
))
->defaults(array(
    'controller' => 'logops',
)); 

# Route explained:
# Match all incoming requests to /login and /logout with
# "logops" controller and call the related action (i.e. login or logout)

注:ルートが一致するとすぐに、手順は停止します。 したがって、すべての追加ルート(つまり すべてのバー(デフォルトルート)は、デフォルトルートの前に作成する必要があります。

それはどのように機能しますか?


リクエストオブジェクトは、ルートに一致すると、データとともに転送されます。 この照合および要求ルーティングプロセスは、次のもので構成されます。

  • リクエストをルートに一致させる

  • 以下の関連するクラスを検索します classes/Controller ディレクトリ。

  • コントローラを見つけます。

  • コントローラのアクション呼び出し可能ファイルを見つけて呼び出します。

  • 応答を返します(つまり ビュー)。

コハナでのエラー処理


単体テストとともに、エラーの処理(適切な方法で)は、ほとんどすべてのアプリケーションの最も重要な部分の1つです。 コハナは、PHPの ErrorException を使用して、エラーを例外に変換し、ヘルパーによる処理を可能にします。

HTTPエラーページコントローラの登録


堅牢なWebアプリケーションは、エラーを適切に処理し、結果を提供します(つまり、 応答)ユーザーに正しく返されます。 この目的のために、コハナは例外的なエラー処理システムを提供しています(しゃれは意図されていません-上記を参照)。

例外をスローするためにHTTPエラーページを登録するには:

class HTTP_Exception_404 extends Kohana_HTTP_Exception_404 {

    public function get_response()
    {
        $response = Response::factory();
        $view     = View::factory('errors/404');
    
        $view->message = $this->getMessage();
        $response->body($view->render());
    
        return $response;
    }
 
}

HTTPエラーをスローする


Kohanaには、HTTPエラー/例外をスローするための非常に優れた操作が簡単なエラー処理メカニズムがあります。

例:

# To create an error (exception) for 404 - Not Found Error
throw HTTP_Exception::factory(404, 'Not Found');

セッションとCookie


セッションとCookieの操作を容易にするために、Kohanaは、それぞれを安全に操作できるヘルパークラスを提供しています。

セッション


セッションを操作するときは、セッションインスタンスにアクセスする変数が必要です。

# Accesing the session instance
$session = Session::instance();

セッションインスタンスにアクセスすることで、次の配列でそれらすべてを取得できます。

# Accessing the session variables
$svars = $session->as_array();

セッション変数に新しい値を追加するには:

# Usage: $session_instance->set($session_key, $value);
$session->set('uid', 1234567890);

1の値を取得するには:

# Usage: $session_instance->get($session_key, $optional_default_value);
$uid = $session->get('uid', 0);

そして最後に、削除するには:

# Usage: $session_instance->delete($session_key);
$session->delete('uid');

クッキー


コハナは安全なクッキーのみを扱っています。 このために、文字列、set-asおよびrefered-as Cookie::$salt で定義する必要があります bootstrap.php 次のようにファイルします。

# Usage: Cookie::$salt = 'secure_cookie_key'; 
Cookie::$salt = '1234567890';

Cookieの値を設定するには、Sessionsで行ったのと同じ方法を使用できます。

# Usage: Cookie::set($cookie_key, $cookie_value);
Cookie::set('uid', 1234..);

Cookieの値を取得するには:

# Usage: $variable = Cookie::get($cookie_key, $optional_default_value);
$var = Cookie::get('uid', 0);

そして最後に、削除するには:

# Usage: Cookie::delete($cookie_key);
Cookie::delete('uid');

注:コハナなどを使用してCookieを操作する方法については、の公式ドキュメント(最新版)をご覧ください。

投稿者: https ://twitter.com/ostezer ”> OS Tezer