3

私は多くの顔を持つ Web アプリケーションを持っており、これまでテーマを作成することでこれを実装してきました。テーマは、共通のバックエンドで使用される html、css、およびイメージのセットです。

物事は次のようにレイアウトされています：

code/
themes/theme1
themes/theme2

また、Web アプリケーションの各インスタンスには、使用するテーマを記述した構成ファイルがあります。例：

theme="theme1"

現在、新しいビジネス ルールにより、単に html/css/images を変更し、バックエンドを変更する必要があるだけでは達成できない特定のテーマを変更するよう求められています。場合によっては、これらの変更をテーマのグループに適用する必要があります。

これをディスクに最適に配置する方法と、コードで処理する方法を考えています。きっと他の誰かがこれに反対したに違いない。

1つのアイデアは次のとおりです。

code/common
code/theme1
code/theme2
themes/theme1
themes/theme2

次に、共通のコードで、最初に検索されるinclude_pathものを設定し、次に.code/theme1code/common

LogoutPage次に、たとえば のクラスを特殊化したい場合は、ページを下の同じパスにtheme2コピーするだけで、特殊化されたバージョンが取得されます。code/commoncode/theme2

この考え方の問題点の 1 つは、同じ名前のクラスが複数存在することです。理論的には、それらが同じ実行に含まれることはありませんが、元の基本クラスを拡張することはできません。

では、基本クラスに一意の名前を付けたらどうなるでしょうか? 例えばTheme1LogoutPage extends LogoutPage。私が予見できる問題の 1 つは、いくつかの一般的なコード (Dispatcher など) が を参照する場合LogoutPageです。ディスパッチャーに条件を追加することはできますが、これを処理するためのより透過的な方法があるのだろうか?

私が考えることができる別のオプションは、テーマごとに別々のブランチを維持することですが、これは大変な作業になる可能性があると思います.

最後に考慮すべきことは、機能が 1 つのテーマに由来し、共通のコードベースにマージする必要がある場合があるということです。

任意の入力をいただければ幸いです。違いがあれば、それは LAMP 環境です。

4

6 に答える 6

1

さまざまなバージョンのサイトにさまざまな機能を実装する手段として、戦略パターンを使用することを検討したいと思います。構成を取り込み、それに基づいて適切なコード戦略を提供する Factory を用意します。各戦略は、呼び出し側クラスの観点から交換可能であるように、いくつかの共通インターフェースを実装できます。これにより、新しい戦略を Factory クラス、Configuration クラス、および変更を行うために実装する必要があるすべての新しい戦略クラスに実装するための変更が分離されます。異なるバージョン間で異なる必要があるユーザー コントロールで同じ (または同様の) ことを行うことができます。

疑似コードで説明します (C# のように見えるかもしれません)。

public interface ILogoutStrategy
{
   void Logout();
}

public abstract class AbstractLogoutStrategy : ILogoutStrategy
{
   public virtual void Logout()
   {
      // kill the sesssion
   }
}

public class SingleSiteLogoutStrategy : AbstractLogoutStrategy
{
   public void Logout()
   {
      base.Logout();
      // redirect somewhere
   }
}

public class CentralAuthenticationSystemLogoutStrategy : AbstractLogoutStrategy
{
   public void Logout()
   {
      base.Logout();
      // send a logout request to the CAS
      // redirect somewhere
   }
}

public static class StrategyFactory
{
   public ILogoutStrategy GetLogoutStrategy(Configuration config)
   {
      switch (config.Mode)
      {
         case Mode.CAS:
            return new CentralAuthenticationSystemLogoutStrategy();
            break;
         default:
         case Mode.SingleSite:
           return new SingleSiteLogoutStrategy();
           break;

      }
   }
}

使用例:

ILogoutStrategy logoutStrategy = StrategyFactory.GetLogoutStrategy( config );
logoutStrategy.Logout();
于 2008-10-29T03:33:16.413 に答える
1

特におすすめはありません。ただし、近道をしないことを強くお勧めします... 3 番目のテーマを追加したり、来年何かを変更したりするのに快適なソリューションを使用してください。
重複は保守性の敵です。

于 2008-10-29T02:41:42.620 に答える
0

必要なのはテンプレートです。

したがって、コードをプレゼンテーションから分離することができます。

Smartyテンプレートを強くお勧めします。また、PEARtemplate_it。

http://www.smarty.net/

これにより、コードの保守性も大幅に向上します。目的は、phpにhtmlを含めず、htmlにphpを含めないことです。

次に、各テーマに使用されているhtmlテンプレートを変更するだけです。またはテンプレートのフォルダ。

于 2008-11-11T03:02:26.610 に答える
0

私はするだろう：

[テーマ名]/[サブフォルダー] default/common default/common/html default/common/css red/code red/common red/common/html red/common/css red/code green/common green/common/html

したがって、コードまたはその他のコンポーネントが存在しない場合は、デフォルトに戻ります。

しかし、実際には、svn で Web サイトを分岐するので、一般的なコードが進化した場合はマージすることができます。

于 2009-05-09T02:14:52.897 に答える
0

マスター ページを使用していますか? 異なるレイアウトや UI が必要な場合は、インスタンスごとに異なるマスター ページのセットを使用できます。カスタムの動作が必要な場合は、依存性注入を検討することをお勧めします。Spring.NET など

于 2008-10-29T04:05:29.737 に答える
0

次のようにすることができます: /common/code

そして: /sitename/code

/common/code 内のすべてのファイルは抽象クラスです。/common/code 内のすべてのファイルについて、/common/code 内の抽象クラスから継承する対応する非抽象クラス ファイルを /sitename/code 内に作成するだけです。

この方法では、CHANGES を /sitename/code に実装するだけで済みます。それ以外はすべて、/common/code にのみ存在するコア機能です。

ここで重要なことは、パブリックメソッドのみを抽象クラスに追加することです。このようにして、すべてのサイトでメソッドを使用でき、すべてのサイトのクラスを同じように処理/操作できます。

于 2009-05-08T16:58:02.687 に答える