7

ウィジェットでフロントエンドコードをセグメント化/モジュール化するための正しいクライアント側フレームワークの選択について読んでいます。

基本的に私が持っている/欲しいものは：

  • 複数のページタイプを持つ複雑なWebサイトであるため、単一ページのアプリケーションはありません。
  • すべてのページは、JavaScriptを使用せずに完全なページをレンダリングできます。IOW：javascriptはエンリッチメントとしてのみ使用されます。
  • 多くのページには、ウィジェットを画面に表示できる非常に動的な方法があります。サーバー側の複雑さを克服するために、コードをウィジェット（複合パターン）にモジュール化しました。各ウィジェットは、それ自体に責任があります。
    • サーバー側コントローラーコード
    • サーバー側のテンプレート（hogan / mustacheを使用）
    • ルーティングエンドポイント、クライアントから呼び出す必要がある場合
    • 構造CSS（ルックアンドフィールではなくウィジェットの構造を変換するCSS）
  • サーバー側のRegionManagerは、最終的に、レンダリングされるウィジェットと画面上のどこにレンダリングされるかを決定します。最終結果は、RegionManagerがすべてのウィジェットのレンダリングの合成としてhtml全体（サーバー生成）を吐き出すことです。

現在、これらのウィジェットの一部にはクライアント側のロジックがあり、クライアントで再レンダリングする必要があります。たとえば、検索ページを取り上げます。これは、ajaxを介して更新できる必要があります。（ここでは、クライアントとサーバーでDRYテンプレートを使用するこのプロセスについて説明しまし た）

私が最終的に望んでいるのは、サーバーで複合パターンをすでに使用している場合、これを何らかの方法でクライアントに拡張して、ウィジェット（画面上の1つの特定のロジックブロック）に、言及されたすべてのサーバー側コードと必要なすべてのクライアントが含まれるようにすることです。 -サイドコード。

これが理にかなっていることを願っています。

マリオネットは、このシナリオでクライアント側のフレームワークとして使用するのに適していますか？マリオネットモジュールの概念が、上記のシナリオでウィジェットであると私が説明しているものであるかどうかは100％わからないので、私は尋ねています。（私の質問ではTwitter Flightについて言及していますが、これは適切だと思うので、現在は非常に新しいため、現時点ではそれを使用することを躊躇しています_

基本的に私が求めているのは、誰かがこれらの線に沿って何かをした経験があるかどうかだと思います。

4

1 に答える 1

2

あなたが説明しているこのタイプのアプリケーションには、Backbone.jsを使用するだけで完璧だと思います。おそらくすでにこれを読んでいますが、バックボーンの文献のほとんどは、サーバーで生成されたJSONモデルとコレクションを関連付け、ビューのレンダリング関数を使用してモデル/コレクションを表すHTML UIを（クライアントで）生成するビューに焦点を当てています。

ただし、このように使用する必要はありません。実際、すでにコンテンツを含む既存の要素にビューをアタッチすることを妨げるものは何もありません。これにより、Backboneのモジュール性、イベントシステムなどのすべての利点が得られます。私は、スタイルの適合性が好きであるという理由だけで、モデルやコレクションのないビューをよく使用します。また、REST APIをまだ取得していない、または提供する予定のない古い既存のアプリケーションを使用する必要がある場合に、以下で説明するようなアプローチを使用しましたが、HTMLでコンテンツを提供します。

まず、次のHTMLがウィジェットの1つを表すと仮定します。

<div id="widget">
    <div class="widget-title"></div>
    <div class="widget-body">
        <!-- assume lots more html is in here -->
        <a href="/Controller/DoWidgetStuff">Do something!</a>
    </div>
</div>

この場合、単一のWidgetモデルでバックボーンを使用できます。これは、次のような非常に単純なモデルになります。

App.WidgetModel = Backbone.Model.extend({
    intialize: function () {
        this.url = this.options.url;
    }
});

ウィジェットがコンストラクター/初期化関数へのパラメーターとしてURLを受け取るという事実に注意してください。このウィジェットモデルは、ウィジェットの多くを表します（もちろん、より複雑なモデルでこの一般的なアプローチを採用し、レンダリングされたHTMLからさまざまなデータを取得することもできます）。それでは、次はあなたの意見です。ご存知かもしれませんが、通常、インスタンス化するときに、ほとんどのビューをモデルまたはコレクションに渡します。ただし、この場合、ビューの初期化関数でウィジェットモデルを作成し、次のように事前にレンダリングされたHTMLからURLを渡すことができます。

App.WidgetView = App.View.ComboboxView = Backbone.View.extend({

    initialize: function () {

        this.model = new App.WidgetModel({}, { url: this.$("a").attr("href") });

    }

    // rest of the view code

});

したがって、ビューのインスタンス化は次のようになります。

new App.WidgetView({el: $("#widget")})'

上記のすべてを実行することにより、バックボーンが提供する他のほとんどすべてを実行でき、モジュール式で適切にカプセル化されます。これが、あなたが求めていることです。

このアプローチ全体の最終結果は次のとおりです。

  1. ウィジェットUIを純粋なHTMLとしてレンダリングしました。これは（私が思うに）JavaScriptなしで機能します。
  2. ビューを既存のHTMLに添付します。
  3. jQueryを使用してレンダリングされたHTMLから抽出されたコンテンツ（URLなど）をオプションとしてビューに渡します。
  4. ビューは、モデルが必要とする関連オプション（URLなど）を渡すモデルをインスタンス化する役割を果たします。
  5. これは、すべての動的サーバー側コンテンツが最初にレンダリングされたHTMLに含まれ、ビューがモジュール式のJavaScriptコンポーネントであり、それに対して何かを実行できることを意味します。これが最終結果だと思います。

ですから、ウィジェットにAJAX機能を持たせたいとおっしゃいましたが、このアプローチでも問題ありません。このアプローチを使用すると、モデルの標準のバックボーンfetchとsave関数を使用Widgetして新しいコンテンツを取得できるようになります。この例では、レンダリングされたHTMLから取得したURLからのものです。応答を受け取ったら、ビュー、レンダリング関数、またはその他のより細かい関数を使用して、必要に応じてページ上のHTMLを更新できます。

いくつかのポイント：

fetchサーバーが提供しているものである場合は、 andsave関数のコンテンツタイプを「text/html」に変更する必要があることに注意してください。例えば：

this.model.fetch({
    type: "POST",
    contentType: "text/html"
});

最後に、私が提案したモデルは、コンテンツなしでインスタンス化されます。ただし、ajax呼び出しが「text / html」のコンテンツタイプである場合は、このコンテンツを属性コレクションに適切に格納できるように、モデルをいじくり回す必要がある場合があります。詳細については、この回答を参照してください。

于 2013-07-03T07:43:46.103 に答える