CFC расширяет родную папку

Я видел все виды решений для расширения cfcs в родительских папках с доступом к родительским файлам или администрированию CF, но я не видел работоспособного решения по расширению cfc в папке "shared"/sibling без доступа к родительским папкам.

Это решение требует доступа к родительским папкам? (Не уверен, что это за отображения, но у меня нет доступа к Application.cfc в любом случае)

Это решение требует возможности создания application.cfc, который не работает для меня (создание одного в myApp ничего не делает, потому что среда, в которой я нахожусь, включает в себя страницу индекса в myApp и создает оттуда... клиент никогда напрямую не работает вызывает его для распознавания Application.cfc)

Например:

  • Wwwroot/ некоторые / путь / MYAPP /Shared/Base.cfc
  • Wwwroot/ некоторые / путь / MYAPP / Функция /Function.cfc

Я ищу возможность вызывать функциональность в Base.cfc (который содержит общие методы, используемые в приложении) из Function.cfc через super и extension.

У меня есть доступ ко всем файлам в myApp, но не "wwwroot", "some" или "path".

Чтобы расширить Base.cfc в Function.cfc, мне нужно расширить полный путь к "some.path.myApp.Shared.Base". Это может вызвать проблемы, если кто-то переименует папку myApp, поскольку мне придется вручную редактировать каждую функцию. CFC, который расширяет этот Base.cfc

То, что я пытаюсь сделать, это создать специфический "барьер" для приложения, поэтому, если имя папки приложения изменится, это не вызовет массового хаоса, требующего отредактировать все CFC-файлы, которые используют функциональность из Base.cfc.

Поскольку я не могу использовать относительные пути к базе ("..Shared.Base"), мне интересно, есть ли способ создать CFC в папке myApp, из которого я могу расширять и облегчать головную боль при переименовании, если бы это было произойти или способ дать ему общее имя, например, "myApp" и расширить его оттуда. (MyApp.Shared.Base)

У меня нет доступа ни к Application.cfm, ни к администрации Coldfusion.

5 ответов

Решение

Лично я бы пошел более простым путем: инкапсулировать базу в функцию.

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

Пути к объектам могут быть построены динамически, например (пошаговый процесс для облегчения чтения):

<cfscript>

    path1 = GetDirectoryFromPath(cgi.SCRIPT_NAME);
    path2 = ListToArray(path1, "/");
    path3 = path2;
    path3[ArrayLen(path3)] = "shared";
    path4 = ArrayToList(path3, ".");
    path5 = ArrayToList(path2, ".");

    myBase = CreateObject("component", "#path4#.Base");

    myFunction = CreateObject("component", "#path5#.Function").init(myBase);

</cfscript>

в Function создать функцию init:

<cffunction name="init">
    <cfargument name="base">
    <cfset variables.Base = arguments.base />
    <cfreturn this />
</cffunction>

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

Если Base.cfc не расширяет другой cfc, то вы можете включить файл Base.cfc в другой файл cfc в вашей папке функций.

Например, создайте файл cfc в папке функций с содержимым:

<cfinclude template="../shared/base.cfc" />

Затем расширьте новый файл вместо cfc в общей папке.

Самый простой способ сделать это - создать символическую ссылку или точку соединения с базовым каталогом в каталоге функций расширений.

К сожалению, это не чисто CF-решение и не переносимое, если вам нужно переместить код. Надеюсь, у кого-то будет лучший ответ, но это может стать запасной точкой, если ничего не будет представлено.

Зачем помещать общий код в отдельную папку? Если вы просто поместите его в ту же папку, что и ваши cfcs "функции", то все они могут расширить его, используя относительный путь.

Так что вместо:

  • Wwwroot / некоторые / путь / MYAPP / Shared / Base.cfc
  • Wwwroot / некоторые / путь / MYAPP / Функция / Function.cfc

Использование:

  • Wwwroot / некоторые / путь / MYAPP / Функция / Base.cfc
  • Wwwroot / некоторые / путь / MYAPP / Функция / Function.cfc

а также:

<cfcomponent extends="Base"></cfcomponent>

Однако, если у вас есть / нужно несколько папок "функционального" уровня, вы можете сделать что-то подобное. Положить Proxy.cfc внутри каждой папки "function" -level, с этим кодом:

<cfcomponent extends="some.path.myApp.shared.Base"></cfcomponent>

И тогда каждый cfc в папках "function" -level будет расширять свои локальные Proxy.cfc (extends="proxy"). Это дает вам 1 прокси на каждую папку, что все еще не идеально, но меньше хлопот, чем обновление каждого cfc.

Сгенерировать код при запуске / сбросе приложения...

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

<cfabort>
<cfcomponent extends="{sharedpath}.Base">
...

затем в функции в или вызванный из application.cfc сделать что-то вроде этого...

<cfdirectory name="codetemplates" action="list" directory="wwwroot/some/path/myApp/codetemplates" />
<cfloop query="codetemplates">
    <cffile name="temp" action="read" path="#tempfilepath##filename#" />
    <cfset newfilecontent = replace(temp.filecontent, '{sharedpath}', configvarwithrightpath) />
    <cfset filecontent = replace(newfilecontent , '<cfabort>', '') />
    <cffile name="temp" action="write" path="#livefilepath##filename#" />
</cfloop>

Другой подход заключается в локальном процессе сборки, который вы запускаете для создания необходимого кода, но мой пример, приведенный выше, позволит вам обновить переменную конфигурации и обновлять cfc по мере необходимости в реальной среде.

Другие вопросы по тегам