Архитектура сайта для приложений white label

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

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

Я решил использовать Railo, Coldbox и AngularJs, используя mysql. Но это не предмет обсуждения, это скорее к вашему сведению.

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

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

У меня хорошие знания основ Coldbox (т.е. одна кодовая база — один сайт), но этого недостаточно для достижения моей цели.

Это базовая структура приложения Coldbox, и именно так я бы увидел структуру каталогов клиента.

+ApplicationRoot
|---+ config
|---+ framework
|---+ обработчики
|---+ плагины
|--- + макеты
|---+ представления
|---+ включает
|---+ перехватчики
|---+ модель
|--- + модули
|---+ Application.cfc
|---+ index.cfm

Если приведенное выше является базовой структурой одного клиентского приложения, как она будет распространяться на основной код? Имея в виду, что я думаю, что основной код будет содержать модули dao, service, gateway, bean. Где они будут жить и будет ли основной код иметь аналогичную структуру в какой-то другой папке?

+ApplicationRoot
|---+ Основной код
|-----+ фреймворк
|-----+ плагины
|-----+ перехватчики< br/> |-----+ просмотры
|-----+ модель
|-----+ модули

---+ Клиент один
|-----+ в соответствии с приведенной выше структурой каталога клиента

---+ Второй клиент
|-----+ в соответствии с приведенной выше структурой каталога клиента

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


angularjs railo coldbox
person david-l    schedule 24.07.2014    source источник
comment
Это кажется безумно широким, но я надеюсь, что некоторые из архитекторов здесь оценят хорошую архитектуру.   -  person Prescott    schedule 24.07.2014
comment
По сути, вы просите здесь бесплатную консультацию, которая на самом деле не входит в сферу компетенции StackOverflow. Имейте в виду, что это сайт вопросов и ответов, поэтому вам нужно задать вопрос, на который есть ответ, а не призывать к обсуждению. Вам лучше задать этот вопрос на форуме. Поскольку это Railo-центрично, группа Railo oogle была бы разумным местом. Тем не менее, это так расплывчато, интересно, чего вы ожидаете от обратной связи? Я бы также подумал о том, чтобы не изобретать велосипед, а вместо этого посмотреть, есть ли что-то, что уже делает все это. Возможно PresideCMS?   -  person Adam Cameron    schedule 24.07.2014
comment
Нет, я не прошу халявы или долгого обсуждения передового опыта, поскольку я сказал: «Надеюсь, вы сможете направить меня в правильном направлении». Я считаю, что вопрос ясен, я высказал свои мысли о том, чего я хочу достичь и как я себе это представляю, и основывал свой вопрос на этой мысли. Я не хочу ничего изобретать, поэтому я здесь. Что касается обратной связи, то было бы более конструктивно указать, является ли то, что я предполагаю, абсолютно неверным, может быть, указать мне на что-то, что может помочь выполнить эту задачу, или просто указать мне какой-нибудь открытый исходный код (спасибо PresideCMS).   -  person david-l    schedule 24.07.2014

Ответы (1)


arrow_upward
2
arrow_downward

Что вам нужно, так это папка для общих объектов ColdBox, которые будут совместно использоваться клиентами. Вы можете настроить эти расположения в ColdBox.cfc.

coldbox = {
    // .. settings above

    //Extension Points
    UDFLibraryFile              = "includes/helpers/ApplicationHelper.cfm",
    coldboxExtensionsLocation   = "",
    modulesExternalLocation     = ["/common/modules/"],
    pluginsExternalLocation     = "",
    viewsExternalLocation       = "",
    layoutsExternalLocation     = "",
    handlersExternalLocation    = "",
    requestContextDecorator     = "",

    // .. more settings below
};

Ваш веб-корень может выглядеть так:

- clientA
    - skeleton
- clientB
    - skeleton
- clientN
    - skeleton
- common
    - extensions
    - handlers
    - layouts
    - modules
    - plugins
    - requestContextDecorator
    - views

Вы также можете заменять макеты и представления стандартными соглашениями ColdBox, но не что будет в вашем коде AngularJS?

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

Надеюсь это поможет.

person Adrian J. Moreno    schedule 24.07.2014
comment
re.AngularJs, насколько я понимаю, привязка, фильтрация, директива, очевидно, будут в представлениях, которые я могу переопределить из того, что вы предлагаете. Модуль, контроллер и службы будут в моих папках include/javascript, которые я намереваюсь вызвать из общей папки или переопределить в папке clientX/include. Я не думал об этом в деталях, но, как вы сейчас упомянули, я думаю, что мне нужно будет исследовать это раньше, чем позже. Я очень благодарен за ваш положительный и бесценный отзыв - person david-l; 25.07.2014