これは、現実の問題ではなく、おそらく学術的な問題と見なすことができますが、誰かが素晴らしいアイデアを持っているかどうかを確認するためにそれを捨てます！アプリケーションのビジネスロジックをプレゼンテーションから分離しておくことは良い考えですが（私はweb-apps atmを見ています）、HTTP変数が何を期待するか（および次に処理）およびプレゼンテーション層によって送信される変数名。
これは、テンプレートで使用する変数名を設計者に指示するだけの問題ですか？テンプレートは変数名が何であるかを知る必要がないので（JS / CSSセレクターにそれらを使用しない限り）、なぜそれらがそこに「ハードコーディング」されるべきなのか。または、ビジネスロジックは、名前を変数に入れて出力する必要がありますか？テンプレートのもう1つの複雑さの層？
Does anyone have any experience of this, or thoughts on how to deal with it?
Thanks, Allan
私の考え...開発者次第だと思います。アプリを作成するときはいつも、あなたが提案したように、ビジネス ロジックとビュー ロジックを分離し、通常は ViewModel を定義します。その後、viewModel はビジネス ロジックとビューの間のコントラクトになります。これにより、両方のチーム (UI とビジネス ロジックの開発者) が独立して開発できるようになり、もちろん簡単なテストなどが可能になります。
ロジックの分離を表示するにはさまざまなアプローチがあることを理解していますが、経験上、2 つの間のコントラクトを定義できれば (使用しているパターンに応じてどちらの形式でも)、開発が容易になります。別々のコンポーネント。
私が以前 Web 開発の仕事をしていたとき (現在は管理/サポートを担当しています)、問題は、後で置き換えられるプレースホルダーを使用するというアイデアと、いくつかの複雑なレイアウト (動的なアコーディオン型の階層ナビゲーション メニューなど) アニメーションと機能を処理するスタイルシートの部分と、フォントと色を制御する部分の設計には鶏が先か卵が先かという問題がありました。
最も有能な設計者であっても、彼らが使用するツールは問題の解決には役立ちません。
最終的に採用したアプローチは、開発者が HTML フラグメントの例を提供し、デザイナーがそれを基にページを構築し、開発者がフラグメントを動的に生成されたコンテンツに置き換え、スタイル シートをクリーンアップしてクラスをマージするというものでした。
これは、私たちが到達できる最も現実的な解決策でした。
C.