8

実際には、Symfony2PHPフレームワークとTwigをテンプレートエンジンとして使用しています。ビューレイヤーのコードの重複を回避し、プログレッシブエンハンスメント（p-jax）の恩恵を受けることができると考えています。

現在のステータス：

PJAXは、ルートに基づくページレイアウトの部分的な更新を処理しません。私たちの目標は、ナビゲーションがY.App（ルーティング）によって処理されるときに、一部のページの「フラグメント」（HTMLノード）のみが更新されるシステムを実装することです。

この点で、POCの実装を開始しました：https ：//github.com/benjamindulau/PocSfYui/ Javascriptはここにあります：https ：//github.com/benjamindulau/PocSfYui/tree/master/src/Acme/PocBundle / Resources / public / js およびY.Appの初期構成：https ：//github.com/benjamindulau/PocSfYui/blob/master/src/Acme/PocBundle/Resources/views/layout.html.twig#L66

アイデアは、最初にページをロードするときに、すべてがサーバー側で処理される（プログレッシブエンハンスメント）ということです。つまり、ページ全体とページフラグメントがサーバーによってレンダリングされます。Y.Appによって実行される必要がある次のリクエストでは、次のようなJSON形式を定義しました（/ photos path response）：

{
    "title": "MyAwesomeWebsite - Photos", // page <title>,
    "fragments": {
        "sidebar": "<h2>Sidebar Menu<\/h2><!-- etc.... -->", // ..... maybe an updated menu for active page
        "main": "<h2>Photos<\/h2><div id=\"photo-list-container\"><ul id=\"photo-list\"><!-- photo items.... --></ul></div>", // Pre-rendered photo list
    },
    "templates": {
        "photo_item_tpl": "<li data-id=\"{{index}}\"><img src=\"{{url}}\" alt=\"{{title}}\" \/><\/li>" // template used later by Y.App for adding new photos
    }
}

これは基本的に、現在のビューコンテンツ（ルート）の「JSON化」バージョンです。

サーバー側では、リクエストがY.Appからのものであることを検出し、Twigテンプレートをレンダリングする代わりに、そこから「ブロック」を抽出し、更新が必要なページフラグメントとクライアントが必要とするハンドルバーテンプレートを含むこのJSONレスポンスを構築しますこの特定のページ。

クライアント側（Y.App）：

ブラウザに「/photos」パスを直接ロードするとします。1。サーバーは写真リストを含むページ全体をレンダリングします2.YUIアプリはPageCompositeViewを作成し、各サブビューをコンテナに再接続します3.YUIアプリはそれを認識しています「MainView」ビュー（メインコンテンツに対応）には、「PhotoModelList」モデルリストにバインドされた「PhotoListView」サブビューが含まれている必要があります。したがって、「/ photos」パスのコールバックは「PhotoView」インスタンスを作成し、それをそのコンテナ（サーバーによってレンダリングされる）に再接続します。

2と3（特に3）は手動で行われます。

POCは実際に機能します。

しかし、先に進む前に、私たちはあなたのアドバイスを得たいと思います。

まず最初に、このPOCについてどう思いますか？

私たちは実際にこのアプローチの賛否両論を見ています。

私たちの主な関心事は、Y.Appを微調整して目的を達成する方法です。-単一の複合ビュー-最初のロード時に、既存のDOMを読み取ることによってモデルが再水和されます（つまり、写真リストがサーバーによってレンダリングされるとき） -前進すればするほど、Y.Appについて何かが欠けていて、間違った方向に進んだと思います;-)

しかし、これらすべての良い面は、それほど多くの作業をしなくても完全な非同期Webサイトを構築できることです。

私たちの主な目標は、「ほぼ完全な」汎用ソリューションを提供することにより、すべてを保守可能に保つことです。

たぶん、そのメッセージから浮かび上がる主な質問は次のようになります。

「Y.Appを正しい方法で使用していますか？」;-)

それで、あなたはどう思いますか ？

ありがとう、Cya

4

1 に答える 1

0

CMS 管理の POC の場合、ほとんど同じことを行いましたが、2 つの違いがあります。PJAX 応答は依然として HTML フラグメントであり、JSON でエンコードされたデータを含むスクリプト タグが含まれているため、モデル/モデルを再水和するために DOM をクエリする代わりにリストには、すでに含まれているデータを使用します。これにより、適切なモデルを取得するためにマークアップに依存する必要がなくなりますが、一方で、応答のサイズが少し大きくなります (ただし、ページ全体の読み込みよりもはるかに軽くなります)。

さらに、JSON でエンコードされたデータには、たとえば、使用するビュー、対応する DOM の場所、テンプレートなどを Y.App に伝えるための設定が含まれている場合があります。

これは YUILibrary フォーラム ( http://yulibrary.com/forum/viewtopic.php?t=11877 ) で議論されたので、ここで他の詳細を見つけることができます。

「Y.Appの使い方は正しいですか？」質問、本当の答えはないと思います。つまり、YUI App フレームワークは、やりたいことを何でもできるフレームワークのようなものです。それは、制約が与えられた場合のトレードオフの問題にすぎません。YUI アプリのいくつかの例を見ると、それらはすべて非常に異なる戦略を持っています。

しかし、いずれにせよ、あなたのソリューションは私には非常に問題ないように思えますし、漸進的に強化されたアプリケーションを構築している人がまだいることを嬉しく思います:-)

于 2013-03-21T09:48:29.013 に答える