Рекомендации по управлению несколькими специализированными версиями одного приложения

Question

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

Вещи раскладывают так:

code/ 
themes/theme1 
themes/theme2 

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

theme="theme1" 

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

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

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

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. Одна из проблем, которую я могу предвидеть, - это когда некоторый общий код (скажем, диспетчер) ссылается на LogoutPage. Я могу добавить условия для диспетчера, но мне интересно, есть ли более прозрачный способ справиться с этим?

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

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

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

Answer 1

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

Answer 2

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

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

Answer 4

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

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

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

http://www.smarty.net/

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

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

Answer 5

Вы могли бы иметь: /общие/код

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

Все файлы в/общий/код абстрактные классы. Для каждого файла в/common/code просто создайте соответствующий не-абстрактный файл класса в/sitename/code, который INHERITS из абстрактного класса в/common/code.

Таким образом, вам нужно только внести изменения в/имя_сайта/код Все остальное ядро ​​функциональность, которая существует только в/общий/код

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

Answer 6

Я хотел бы сделать:

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

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

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