再利用性と抽象化は私を殺しています。私は明らかに多くのクライアントサイド開発を行ってきました。CoffeeScript、Backbone、およびMarionetteが役立ちました。それでも、完全に再利用可能なモジュール式の「テンプレート」をサーバー側から上に構築することはできませんでした。問題を上から下に説明させてください。そうすれば、おそらくあなたは最良のスタックを説明するのを手伝うことができます。
同じフレームワークを使用して、バージョン管理して複数のアプリケーション間で再利用できるログインウィジェットを作成したいと思います（これは基本的な気まぐれな例です。数粒の塩を使用してください）。1つの大きなアプリケーションは悪い考えであり、とにかく別々にホストされます。個別のアプリケーションはすべて同じAPIを使用し、他の場所でホストされており、JSONPは受け入れられません。
クライアント側
ログインフォームは、Marionette ItemView、すべての派手な相互作用を処理するいくつかのjQuery関数、POST、GET、DELETEのさまざまな側面を処理するバックボーン「アカウント」モデル、およびビューがバインドされているいくつかの基本的なhtmlで構成されます。 。通常、AJAXインタラクションのurlRootを明示的に設定する必要があります（以下を参照）が、ルートが何であるかは関係ないので、「/」+@attributes.emailと言うことができるようにしたいと思います。 、すべてが一緒にバンドルされているため。
class Account extends Backbone.Model
# Normal
create: () ->
@urlRoot = () ->
'/account/' + @attributes.email
@save()
# Ideal
create: () ->
@urlRoot = () ->
'/' + @attributes.email
@save()
サーバ側
これは、クライアント側（できればScala）に従って構築されており、どこかでROUTEを明示的に定義する代わりに次のようになります。
POST /account/:email controllers.Account.create(password: String) # Play 2.0 syntax
私は単に言うことができるでしょう：
@POST(/:email?password=[String]) # Made up syntax
create(email, password) = {
# Hit external API
val json = WS.url('https://someapi/v1/account').withQueryParams('email=' + email + '&password=' + password).get()
# Return some response
Ok(json)
}
アプリケーションフレームワークは、おそらくこのモジュールまたはテンプレートを認識します。@account()ログイン機能を備えたホームページを作成したい場合は、次のようにします。
<html>
Oh hey cool stuffz, sign up or login please
<right column>
@account()
<end right column>
@social() <!-- perhaps another template -->
<html>
私が想像しているのは、モジュールからのクライアントからサーバーへの呼び出しをGUIDに抽象化するアプリケーション層です。したがって、「アカウントの作成」呼び出しを行うと、実際には次のようになります。
POST /35395235/:email account.create(password: String)
これは必ずしも存在するわけではないことは理解していますが、Liftに出くわしました。比較的有望なようですが、期待したほど抽象化されていません。考え？