マスターページは会社のフレームワークの一部である必要があると思いますか、それとも各アプリケーションの一部である必要がありますか？あるいは、会社のフレームワークには、すべてのマスターページに最小限の機能を提供するためのインターフェイスのみが必要ですか？
現在、私たちは2つの問題に直面しています。1つは、元々のアイデアは、すべてのビジネスアプリケーションに共通のレイアウトを設定することでした。そのため、マスターページは会社のフレームワークに組み込まれています。第二に、いくつかのアプリケーションは異なるレイアウトを持つ必要がありました。メニュー、CSSクラスなどのロジック全体がフレームワークにあったため、何が問題を引き起こしました...
あなたの考えを教えてもらえますか？
ありがとう、
共通のコントロールなどのUI要素をフレームワークライブラリに移動し、アプリケーション内の各アプリケーションのマスターページを作成しようと思います。これにより、共通のコントロールを使用してアプリケーション全体で共通のUI要素を維持できるようになり、アプリケーションごとに異なるレイアウトを作成できる柔軟性が得られます。
他に考慮すべきことは、同じアプリでさまざまな目的のためにさまざまなマスターページを使用することです。たとえば、内部スタッフ用に1つ、顧客用に1つのマスターページを使用する場合があります。または、通常のブラウザー用に1つのマスターページを使用し、ブラックベリーなどのデバイス用に別のマスターページを使用する場合があります。
マスターページを共有することを考えている場合は、ロジックが多すぎることを意味している可能性があります。私の会社では、歴史的に、多くの共通機能を備えたベースマスターページとベースページを作成していました。問題は、これが非常に柔軟性がないことです。私はMVPフレームワークの使用を開始し、ページからロジックを取り出しました。共通のマスターページを用意する必要はなくなり、レイアウトロジックが追加されました。
一部のCSSとデザインライブラリ（テンプレート、画像、パレット）を共有しますが、単一の共有マスターページが十分な柔軟性を備えているとは限りません。
あなたの会社の要件にもよると思います。私は以前、それがコアフレームワークの一部である組織で働いていました。ただし、これは、すべてのWebアプリケーションが内部にあり、同じルックアンドフィールが必要だったためです。
マスター ページは、複数のページで Web サイト全体で静的になる要素を保持するように設計されています。フッター、ヘッダーなどを保持するために使用できます。
複数のアプリケーションで同じマスター ページを使用することを検討する必要さえないと思います。これにより、マスター ページでできることが大幅に制限されます。実際、必要に応じて、1 つのアプリケーション内に複数のマスター ページを用意することをお勧めします。それは何も悪いことではありません。
複数のアプリケーションで同じマスター ページを使用しようとすると、柔軟性を維持するために非常に創造的なプログラミングを行う必要があります。したがって、それは間違いなくノーノーの考えです。
それが役立つことを願っています。