問題タブ [kohana]

Kohana をすぐに使い始めるために、すべての Web 開発者が必要とするすべての基本的なものを利用する洗練されたスケルトン プロジェクトを誰かが作成したことがあるだろうかと思います。

• ログインによる基本的なユーザー認証
• MySQL データベースからいくつかのものを取得して表示する

手で私はこれをかなり速くします。でもコハナでは、それを達成するためにモンエベレストに登らなければならないように感じます. それらは完全な例を提供するものではなく、あらゆる種類のもののコード断片を提供するだけです。動的なプラットフォームの作成を開始するための「基本的な形状」があると便利です。つまり、最近ではほとんどすべての Web サイトで、何らかの認証、ログインなどの機能が必要になっています。

ajax & co のような大量の異常なもので爆破されていない、単純で基本的な作業スケルトン プロジェクトの例を誰かが知っていれば、リンクは素晴らしいでしょう。

私は小さなプロジェクト用に独自の小さな軽量フレームワークを作成していましたが、現在は Kohana に切り替えています。

しかし、ナビゲーション階層を実現するにはどうすればよいのだろうか。

例: 次のようなメニューがあります。

ホーム | 製品 | サポート | コンタクト

私の古いフレームワークでは、ユーザーが「Products」をクリックすると、フレームワークはこれがどのナビゲーション レイヤーであるかを認識し、ビューはそのメニュー項目の css クラスに「_active」サフィックスを付けたので、強調表示されました。すべての親ナビゲーション要素について同じです。

このようなことを実現するために、Kohana でサイトをどのように設定していますか?

メニュー バーを含む 1 つの大きなレイアウト ビューを作成することを考えました。そこでは、どのメニュー項目をアクティブとして強調表示する必要があるかを判断するために、すべてのロジックを実装する必要があります。これには巧妙なメカニズムがありますか、それとも、URL セグメントがメニュー項目と一致する場合、if ステートメントの束で現在の URL から何らかの形で把握する必要がありますか?

KohanaPHP フレームワークでプロジェクトをテストする PHPUnit のベスト プラクティスを探しています。

Kohana は次のように URL を自動的に設定します

http://www.example.com/controller/method/argument1/argument2/etc

今、ダッシュを使用して URL 内の単語を区切るのが好きで、次のようなアドレスがあります。

http://www.example.com/business-hub

私のコントローラーのタイトルは BusinessHub_Controller です。私を悩ませているのは、/business-hub/ が BusinesHub コントローラーと一致するようにすることです。application/config フォルダーの下の routes.php にカスタム エントリを追加する必要があります。また、メソッドごとに 1 つ追加する必要があるようで、これは本当に面倒です。たとえば、ここに抜粋があります。

明らかに、これは本当に迷惑です。とにかく、KohanaにURLをキャメルケース名に変換するように指示できますか?

私は Kohana を数か月間使用していますが、コード/プレゼンテーション/db レイヤーを整理する MVC スタイルにはまだ比較的慣れていません。残念ながら、コントローラーを作成し、ビューを確立し、モデルを介してデータベースと対話する方法に関するドキュメントはたくさんありますが、クリーンで提案された開発パターンを扱う多くのリソースは見つかりませんでした。

簡単な例を挙げましょう：

私の最新のプロジェクトにはコントローラーが 1 つあります。それよりも多くのコントローラーを作成する必要があるかどうか、またはいつ新しいコントローラーを作成する必要があるかがわからないためです。新しいコントローラーが必要な時期と、新しいモデルが必要な時期を正確に判断するにはどうすればよいですか?

コハナにフックを構築するにはどうすればよいですか...

コントローラのインデックスメソッドを呼び出し、引数として「non_exisitng_method」を渡すことを除いて、コントローラのタイトル「a_controller」にルーティングしますか？

また、フォールバックを許可する必要があるため、non_existing_methodがメソッドである場合は、そのメソッドにルーティングする必要があります。

したがって、私のフックは、一致するメソッドがない場合、インデックスにルーティングし、残りのURLを引数としてインデックスに提供します。

どうすればいいですか？

Kohana はリクエストが AJAX かどうかをどのように判断しますか?

リファラー文字列に違いはありますか? おそらくGETパラメータを追加する必要があり?ajax=trueますか?

私はCodeIgniterシステムをしばらく使用していますが、欠点があります。それが教えてくれたことに感謝していますが、今は新しい非codeigniterプロジェクト用のライブラリが必要なので、どのライブラリに正しいものがあり、どのライブラリが正しくないかについてのアイデアを探しています。必要なものをすべて入手するには、おそらくいくつかのライブラリから断片を取得する必要があります。

Kohana PHPセッションライブラリを調べたところ、データアクセスのために$ this-> sessionに変更を強制する代わりに、$_SESSIONスーパーグローバルを使用するネイティブPHPの方法に戻る方法が気に入っています。

とにかく、私が混乱しているかもしれない他の良いセッションライブラリがあるかどうか知りたかったのです。CRUDだけでなく、セッションで処理しなければならないことがたくさんあります。

• 非Cookieベースのセッションパッシングのサポート（つまり、FacebookまたはFlashアップローダー）
• 次のページの読み込みの間だけ持続し、その後自動削除される「フラッシュデータ」。
• $_SESSIONまたは$this->sessionと連携して、プログラマーが既存のコードを変更する必要がないようにします。
• ページの途中でIDを変更する場合に備えて、新しいセッションID（つまり、session_id（'new id'））の設定をサポートします。
• データが追加または削除されるたびにではなく、ページ要求の最後にすべてのデータを保存します（余分なDBクエリを保存します）。
• ストレージ用のファイル、Cookie、またはデータベースの使用をサポートします。（またはmemcachedがいいでしょう）
• セッションハイジャックの場合にアクセスを拒否しようとします。（IP、ユーザーエージェント、または指紋）

CodeIgniterとKohanaのセッションライブラリのロジックを少し時間をかけて調べたところ、それぞれがページのセッションを開始および終了する方法について次のことがわかりました。

私はいくつかのPHPフレームワークを調査しており、現在の最有力候補はコハナです。

Railsのバックグラウンドを持っているので、Railsコミュニティが「RESTful」ルートと呼ぶものに慣れてきました。したがって、「GET / posts」はすべての投稿を表示し、投稿コントローラーのインデックスメソッドによって処理されます。「POST/posts」は新しいpostオブジェクトを作成し、PostsControllerの別のメソッドによって処理されます。

これら2つのリクエストのパスは同じであるため、ルーターはHTTPメソッドに基づいて決定を下す必要があります。

コハナのルーターはこれを行うことができますか？

PHPクラスで作業するときにself::method（）とparent :: method（）を使用することが許容される/推奨されるかどうかを知りたいです。

$ this-> method（）を使用できますが、$ this->は、クラス変数、親クラス変数、または親クラスのメソッドを参照することもできます。自己に曖昧さはありません::

自己::は減価償却されていますか、および/またはこのスタイルを使用する際の警告または短所はありますか？

self::とparent::はクラスの静的インスタンスを参照していることを理解していますが、kohanaでは、メソッドを静的として明確に定義しない限り、違いはないようです。

ありがとう。

例を追加しました：このアプリケーションが複数のWebサイトからのフォーラムを保存すると仮定します...

この例は、エラー報告を次のように設定してコハナで機能します。error_reporting（E_ALL＆〜E_STRICT）;

$ this-> site_idは、メインのController_Coreクラス（kohanaのライブラリ）で定義されています。

私の知る限り、静的な方法でself :: category（）を呼び出しているため、$ thisは使用できないはずですが、categories（）を静的として定義した場合にのみエラーがスローされます。

しかし、私が言ったように、私は自分自身を使用する方がはるかに好きです::読みやすさの観点から、あいまいさを引き起こす$ thisを使用するのではなく、この関数がどこにあるべきかを正確に知っています。