ホームページ >バックエンド開発 >PHPチュートリアル >symfony フォームとページの実装スキル、symfony フォームスキル_PHP チュートリアル
この記事の例では、symfony のフォームとページの実装テクニックについて説明します。皆さんの参考に共有してください。詳細は以下の通りです
Symfony の開発は非常にシンプルですが、機能の数はまだ不足しています。次に、askeek サイトとユーザーの間で何らかの対話を行います。リンク以外の HTML インタラクションの基礎はフォームです。
ここでの目標は、ユーザーがログインして、ホームページ上の質問リストを参照できるようにすることです。これにより開発が迅速になり、以前のコンテンツを思い出すことができます。
ログインフォーム
テストデータにはユーザーが含まれていますが、プログラムにはそれを検証する方法がありません。次に、プログラムのすべてのページにログイン フォームを追加します。グローバル レイアウト ファイル askeet/apps/frontend/templates/layout.php を開き、about への接続の前に次のコード行を追加します。
現在のレイアウトでは、これらのリンクが Web デバッグ ツールバーの直後に配置されます。これらのリンクを表示するには、「Sf」アイコンをクリックしてデバッグ ツールバーを折りたたみます。
次に、ユーザーモジュールを作成する必要があります。質問モジュールは翌日に生成されました。今回は symfony にモジュール フレームワークの作成を依頼しただけで、コードは自分たちで書きます。
このフレームワークには、デフォルトのインデックスアクションとindexSuccess.phpテンプレートが含まれています。必要ないので削除してください。
ユーザー/ログインアクションの作成
パブリック関数executeLogin()
{
$this->getRequest()->setAttribute('referer', $this->getRequest()->getReferer());
sfView::SUCCESS;
を返します
}
このアクションにより、リファラーがリクエスト属性に保存されます。この属性は、モジュールで使用するために非表示領域に保存できるため、ログイン成功後にフォームの意図したアクションを元のリファラーにリダイレクトできます。
ステートメント return sfView::SUCCESS は、アクションの実行結果を loginSuccess.php モジュールに渡します。このステートメントは、return ステートメントを含まないアクションに実装されます。そのため、アクションのデフォルト モジュールは actionnameSuccess.php と呼ばれます。
アクションについてさらに作業を始める前に、モジュールを見てみましょう。
loginSuccess.phpモジュールを作成する
Web 上での人間とコンピューターのやり取りの多くはフォームを使用しており、Symfony はフォーム ヘルパーのコレクションを提供することでフォームの作成と管理を組織化します。
askeet/apps/frontend/modules/user/templates/ ディレクトリに、次の loginSuccess.php モジュールを作成します。
このモジュールはフォームヘルパーを初めて使用するものです。これらの Symfony 関数は、フォームタグを自動的に作成するのに役立ちます。 form_tag() はタグを開き、デフォルトのアクションとして POST を使用し、引数として渡されたアクションを指します。 input_tag() ヘルパーは タグを生成し、渡された最初の引数に基づいて id 属性を自動的に追加します。デフォルト値は 2 番目の引数から取得されます。フォームヘルパーとそれが生成する HTML コードの詳細については、Symfony ブックの関連する章を参照してください。
ここでの本質は、フォームが送信されたときにこのアクションが呼び出されるということです。それでは、戻ってこのアクションを見てみましょう。
フォームの送信を処理する
先ほど書いたログインアクションを次のコードに置き換えます:
ログインアクションを使用すると、ログインフォームの表示と処理を同時に行うことができます。したがって、彼は自分が呼ばれる環境を知らなければなりません。アクションが POST モードで呼び出されない場合 (リンクによって要求されたため): これは、まさに上で説明した状況です。 POST モードで要求された場合、このアクションはフォームによって呼び出され、それに応じて処理されます。
このアクションは、リクエスト パラメーターからニックネーム フィールドの値を取得し、User テーブルをクエリして、このユーザーがデータベースに存在するかどうかを確認します。
将来的には、パスワード制御によりユーザーに資格情報が割り当てられるようになります。ただし、このアクションで実行されるのは、ユーザーの ID 属性とニックネーム属性をセッション属性に保存することだけです。最後に、アクションはフォーム内に隠されている元のリファラー フィールドにリダイレクトされ、リクエスト パラメーターとして渡されます。このフィールドが空の場合は、デフォルト値が使用されます。
ここで、この例の 2 種類の属性セットの違いに注意する必要があります。リクエスト属性 ($this->getRequest()->setAttribute()) はテンプレート用に保存され、回答は参照者に送信され、忘れられます。セッション属性 ($this->getUser()->setAttribute()) はユーザー セッションの存続期間全体にわたって保存され、将来他のアクションによってアクセスできます。プロパティについてさらに詳しく知りたい場合は、Symfony ブックの「パラメータ セーバー」セクションを参照してください。
権限を割り当てる
ユーザーがaskeek Webサイトにログインできるのは良いことですが、ユーザーはただ楽しむためにログインしているわけではありません。新しい質問を投稿したり、特定の質問に関心を示したり、コメントを評価したりするには、ログインする必要があります。他のアクションは、ログインしていないユーザーにも公開されます。
ユーザーを認証済みとして設定するには、sfUser オブジェクトの ->setAuthenticated() メソッドを呼び出す必要があります。このオブジェクトは、構成を通じてアクセスを制限するための証明書メカニズム (->addCredential()) も提供します。これについては、Symfony ブックの「ユーザー証明書」セクションで詳しく説明されています。
これが次の 2 行の目的です:
ニックネームが認識されると、ユーザーデータがセッション属性に保存されるだけでなく、Web サイトの制限された部分へのアクセス権もユーザーに割り当てられます。明日は、プログラムへのアクセスを認証されたユーザーに制限する方法について説明します。
ユーザー/ログアウトアクションを追加
->setAttribute() メソッドに関する最後のヒントが 1 つあります。最後のパラメーター (上記の例ではサブスクライバー) は、属性が保存される名前空間を定義します。名前空間を使用すると、別の名前空間に存在する名前を属性に割り当てることができるだけでなく、そのような属性をすべて 1 つのコマンドで素早く削除することもできます:
名前空間を使用すると、これらの属性を 1 つずつ削除する手間が省けます。これは 1 行のステートメントだけです。
レイアウトを更新しました
現在のレイアウトでは、ユーザーがログインしている場合でも「ログイン」リンクが表示されます。これを修正しましょう。 askeet/apps/frontend/templates/layout.php ファイルで、今日のガイドの冒頭で変更したコードを変更します。
いよいよテストです。プログラムの任意のページを表示し、「ログイン」リンクをクリックし、使用可能なニックネーム (「匿名」など) を入力して確認します。ウィンドウの上部にある「ログイン」が「サインアウト」に変わったら、これまでの操作はすべて正しいことになります。最後に、ログアウトして「ログイン」リンクが再度表示されるかどうかを確認してください。
質問組織
何千人もの Symfony 愛好家が askeet の Web サイトにアクセスするにつれて、ホームページにはますます多くの質問が表示されます。リクエスト速度の低下を避けるためには、質問リストのランダムな閲覧が解決すべき問題となる。
Symfony は、この目的のためにオブジェクト sfPropelPager を提供します。データのリクエストがカプセル化されるため、現在のページに表示されているレコードのみがクエリされます。たとえば、ページあたり 10 個の質問のみでページが初期化されている場合、データへのリクエストは 10 個の結果のみに制限され、オフセットはページ内で一致するように設定されます。
質問/リストのアクションを変更する
前の演習では、質問モジュールの表示アクションを見ました:
配列を渡す代わりに sfPropelPager をテンプレートに渡すようにこのアクションを変更します。同時に、興味のある量に応じて質問を並べ替えます:
sfPropelPager オブジェクトの初期化は、それに含まれるオブジェクト クラスと、ページ上に配置できるオブジェクトの最大数 (この例では 2) を示します。 -> setPage() メソッドは、リクエスト パラメータを使用して現在のページを設定します。たとえば、このページ パラメータの値が 2 の場合、sfPropelPager は 3 から 5 までの結果を返します。ページ リクエスト パラメータの値が 1 に変更されると、ページはデフォルトで 1 から 2 までの結果を返します。 sfPropelPager オブジェクトとそのメソッドについて詳しくは、Symfony ブックの Pages の章を参照してください。
デフォルトパラメータを使用する
使用する設定ファイルに定数を入れることをお勧めします。たとえば、ページごとの結果の数 (この例では 2) は、カスタム プログラム構成のパラメーターに置き換えることができます。上記の sfPropelPager 行を次のコードで変更します:
ここでの pager キーワードは名前空間として使用されているため、パラメーター名に表示されます。カスタム設定とカスタムパラメータルールの命名について詳しくは、Symfony ブックの「設定」セクションを参照してください。
listSuccess.php テンプレートを変更する
listSuccess.php テンプレートに、次のコード行を追加します。
を
に置き換えました
このようにして、ページには、ページに保存されている結果のリストが表示されます。
ページビューを追加
このテンプレートで行う必要があることがもう 1 つあります。それはページビューです。ここで、テンプレートは最初の 2 つの質問を表示するだけですが、次のページへの機能と前のページに戻る機能を追加する必要があります。これらの機能の追加を完了するには、テンプレートの後に次のコードを追加する必要があります:
このコードは、sfPropelPager オブジェクトのさまざまなメソッドと ->haveToPaginate() を使用します。この関数は、要求された結果の数がページ サイズを超えた場合にのみ true を返します。 ()、->getLastPage() はすべて明示的な意味を持っています。->getLinks() 関数はページ番号の配列を提供し、->getCurrentMaxLink() 関数は最後のページ番号を返します。
この例では、Symfony リンク ヘルパーも示しています。 link_to_unless() は、最初の引数としてのテストが false の場合は通常の link_to() を出力します。そうでない場合は、非リンク テキストを出力し、単純な < ;span>パッケージ化を使用します。
このページはテストしましたか?テストする必要があります。この修正は自分の目で確認するまでは完了しません。テストするには、3 日目に作成したテスト データ ファイルを開き、表示されるページ ビューにいくつかの質問を追加します。インポート データ バッチ ファイルを再実行し、ホームページを再度リクエストします。
サブページのルーティングルールを追加する
デフォルトでは、ページのルールは次のとおりです:
http://askeet/frontend_dev.php/question/list/page/XX
ここで、ルーティング ルールを使用して、これらのページを使用して理解を容易にします:
http://askeet/frontend_dev.php/index/XX
apps/frontend/config/routing.yml ファイルを開き、次の内容を先頭に追加します:
さらに、ログイン ページにルーティング ルールを追加します:
リファクタリング
モデル
質問/リスト アクションはモデルに関連するコードを実行します。そのため、このコードをモジュールに移動する必要があります。次のコードを使用して、質問/リスト アクションを置き換えます:
question/templates/listSuccess.phpに示されている質問リストは、将来いくつかの場所で使用される予定です。そこで、問題リストを表示するテンプレート コードを _list.php フラグメントに配置し、listSuccess.php の内容を次の単純なコードに置き換えます。
http://www.bkjia.com/PHPjc/947922.html