2013-03-19 9 views
8

実際には、Symfony 2 PHPフレームワークとTwigをテンプレートエンジンとして使用しています。 Viewレイヤのコードの重複を避け、プログレッシブエンハンスメント(p-jax)の恩恵を受けることができると考えています。YUI3(Y.App)とSymfony2のプログレッシブエンハンス

現状:

PJAXルートに基づいて、ページレイアウトの一部の更新を処理しません。 私たちの目標は、ナビゲーションがY.App(ルーティング)によって処理されるときに、一部のページ「フラグメント」(HTMLノード)のみが更新されるシステムを実装することです。 https://github.com/benjamindulau/PocSfYui/ Javascriptがここで見つけることができます:この点で

は、我々は、POCを実装するために始めた 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

考えであること、我々は最初のページをロードし、すべてのものサーバサイド(プログレッシブエンハンスメント)で処理されます。つまり、ページ全体とページフラグメントがサーバによってレンダリングされます。

{ 
    "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 
    } 
} 

基本的には現在のビューの内容の「JSONified」バージョンです:Y.Appによって実行されるべき次の要求について は、我々は以下の(/写真路応答)のようなJSON形式を定義しました(ルート)。

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

は、我々が直接私たちのブラウザに「/写真」のパスを読み込む言う: は、サーバが 2. YUIのAppは、そのPageCompositeViewを作成し、各サブビューを再接続フォトリストを含むページ全体をレンダリング1.そのcontainer 3. YUIアプリケーションは、 "MainView"ビュー(メインコンテンツに対応)に "PhotoModelList"モデルリストにバインドされた "PhotoListView"サブビューが含まれている必要があることを認識しています。したがって、 "/ photos"パス上のコールバックは "PhotoView"インスタンスを作成し、それをコンテナに再接続します(サーバーによってレンダリングされます)。

2と3(特に3)は手動で行われます。

POCは実際に動作します。

さらに進む前に、アドバイスを受けたいと思います。

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

私たちは実際にこのアプローチで賛否両論&を見ています。 - 単一のコンポジットビュー - 最初のロード時に、モデルは既存のDOMを読み取ることによって再水和されます(例:写真リストサーバーによってレンダリングされます) - 私たちが進むほど、Y.Appについて何か不足していると思っており、間違った方法を取ったと思います.-)

しかし、多くの作業をせずに完全な非同期Webサイトを構築できるということです。

私たちの主な目標は、「ほぼ完全な」一般的なソリューションを提供することによって、すべてを維持できるようにすることです。

たぶん、そのメッセージから出てくる主な質問は次のようになります。

「我々はY.App正しい方法を使用していますか?」 ;-)

あなたはどう思いますか? CMSの管理のPOCのために

おかげで、 CYA

答えて

0

は、私はかなり同じことをやったが、2違いがあります。PJAX応答はまだHTMLフラグメントであり、それはJSONエンコードされたデータをスクリプトタグが含まれています私のモデル/モデルリストを再水和するためにDOMを照会するのではなく、既にそこにあるデータを使用します。これは、適切なモデルを得るためにマークアップに頼ることはできませんが、これは応答のサイズを少し大きくします(ただし、ページ全体の負荷よりもずっと軽い)。

また、JSONエンコードされたデータも

...どこ対応するDOM、テンプレート、または何を検索するには、ビュー(s)は、使用するあなたのY.Appを伝えるために、インスタンスのためのいくつかの設定が含まれている場合があります

これはYUILibraryフォーラムで議論されました:http://yuilibrary.com/forum/viewtopic.php?t=11877です。

「私たちはY.Appを正しい方法で使用していますか?質問、私は本当の反応がないと思う。私は、YUI Appフレームワークは、あなたが望むものを何でもできるようにするフレームワークの一種だということです。あなたの制約を考えると、トレードオフの問題に過ぎません。いくつかのYUI Appの例を見ると、それらはすべて非常に異なる戦略を持っています。

いずれにしても、あなたの解決策は私にとって非常にうまく感じられます。まだ徐々に強化されたアプリケーションを構築している人がいることを嬉しく思います:-)