Лучшие практики для управления несколькими специализированными версиями одного приложения

Question

У меня есть веб-приложение с множеством граней, и до сих пор я реализовал это путем создания тем. Тема - это набор html, css и изображений для использования с общим бэкэндом.

Вещи выложены так:

code/
themes/theme1
themes/theme2

И каждый экземпляр веб-приложения имеет файл конфигурации, в котором указано, какую тему следует использовать. Пример:

theme="theme1"

Теперь новые бизнес-правила требуют от меня внесения изменений в определенные темы, которые не могут быть достигнуты путем простого изменения html / css / images и требуют изменения серверной части. В некоторых случаях эти изменения необходимо применить к группе тем.

Мне интересно, как лучше всего это выложить на диск, а также как справиться с этим в коде. Я уверен, что кто-то другой, должно быть, столкнулся с этим.

Одна идея состоит в том, чтобы иметь:

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

Затем мой общий код задает include_path таким образом, что сначала ищется code/theme1, затем code/common.

Тогда, если я хочу специализироваться, скажем, класс LogoutPage для theme2, я могу просто скопировать страницу из code/common по тому же пути под code/theme2, и она выберет специализированную версию.

Одна из проблем этой идеи состоит в том, что будет несколько классов с одинаковыми именами. Хотя теоретически они никогда не будут включены в одно и то же исполнение, я не смог бы расширить исходный базовый класс.

Так что, если бы я должен был сделать уникальное имя для базового класса? например Theme1LogoutPage extends LogoutPage. Одна проблема, которую я могу предвидеть, это когда какой-то общий код (скажем, Dispatcher) ссылается на LogoutPage. Я могу добавить условия диспетчеру, но мне интересно, есть ли более прозрачный способ справиться с этим?

Другой вариант, который я могу придумать, - это поддерживать отдельные ветки для каждой темы, но я думаю, что это может быть много работы.

И последнее, что нужно учитывать, это то, что функции могут возникать в одной теме, а затем требовать объединения в общую кодовую базу.

Любой вклад с благодарностью. Если это имеет какое-то значение, это среда LAMP.

Answer 1

Я бы исследовал использование шаблона «Стратегия» как средства для реализации различных функций в разных версиях сайта. Имейте Фабрику, которая принимает вашу конфигурацию и предоставляет соответствующую стратегию кода на ее основе. Каждая стратегия может реализовывать некоторый общий интерфейс, чтобы они были взаимозаменяемыми с точки зрения вызывающего класса. Это изолирует ваши изменения для реализации новых стратегий для класса 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();

Answer 2

У меня нет конкретной рекомендации. Тем не менее, я настоятельно рекомендую НЕ использовать ярлык ... Используйте решение, которое будет для вас удобным, добавить третью тему или что-то изменить в следующем году.
Дублирование - враг ремонтопригодности.

Answer 3

Я бы сделал:

[название темы] / [подпапка] по умолчанию / общие по умолчанию / общие / HTML по умолчанию / общий / CSS красный / код красный / общий красный / общий / html красный / общий / CSS красный / код зеленый / общий зеленый / общий / html

Таким образом, если код или любой другой компонент не существует, он вернется к значению по умолчанию.

Но на самом деле я бы разветвлял веб-сайт в svn, поэтому, если он будет развиваться, я смогу объединить его и т. Д., См. Subversion по адресу: http://subversion.tigris.org/

Answer 4

Вы можете иметь: / Общий / код

А: / Имя_сайта / код

Все файлы в / common / code являются абстрактными классами. Для каждого файла в / common / code, просто создайте соответствующий файл неабстрактного класса в / sitename / code, который НАСЛЕДИТ от абстрактного класса в /common/code.

Таким образом, вам нужно всего лишь реализовать ИЗМЕНЕНИЯ в / sitename / code Все остальное является основной функциональностью, которая существует только в / common / code

Здесь важно убедиться, что вы добавляете только public методы к абстрактным классам. Таким образом, методы доступны для всех сайтов, а классы со всех сайтов можно обрабатывать / обрабатывать одинаково.

Answer 5

Вам нужны шаблоны.

Отсюда вы можете отделить свой код от вашей презентации.

Я настоятельно рекомендую smarty шаблоны. Также PEAR template_it.

http://www.smarty.net/

Это также делает ваш код более удобным для сопровождения. Цель состоит в том, чтобы в вашем php не было html, а в html не было php.

тогда все, что вам нужно сделать, это изменить шаблон HTML, который используется для каждой темы. или папка шаблонов.

Answer 6

Вы используете мастер-страницы? Если вам нужны разные макеты и пользовательский интерфейс, у вас может быть свой набор главных страниц для каждого из ваших экземпляров. Если вам нужно нестандартное поведение, возможно, вы захотите изучить Dependency Injection. Spring.NET и др.