Как Вы организуете свой маленький допускающий повторное использование cffunctions?

Я реорганизовываю свои структуры каталогов ColdFusion и любопытен на предмет того, как опытные разработчики CF организуют библиотеки меньшего cffunctions.

Мне не так любопытно на предмет тщательно продуманных компонентов (объекты), как я о десятках небольших служебных функций, которые все мы создаем со временем.

  • Вы используете большой единственный файл с cffunctions и cfinclude это?
  • Вы используете большой единственный файл в качестве cfcomponent и называете creatobject/cfinvoke?
  • Вы помещаете каждую утилиту cffunction в ее собственный cfc и называете createobject/cfinvoke?
  • Вы используете cfimport taglib синтаксис?
  • Вы используете CustomTags или cfmodule?
  • У Вас есть лучший путь?

Так как мне не нравится подробный синтаксис, я был просто cfincluding lib.cfm, который имеет набор общего cffunctions в нем. Я могу осуществить рефакторинг их к сгруппированному cfcs, на котором я могу createobject только, чтобы иметь лучшую изоляцию на переменных объемах.

Существует ли лучший способ сделать это?

15
задан James A Mohler 22 February 2019 в 16:40
поделиться

3 ответа

Это - перепечатка сообщение в блоге, которое я сделал назад 13 июня 2007. Я использовал этот метод для вполне когда-то, и он работает отлично! YMMV.

, Кому не нравятся пользовательские функции (UDFs)? При выполнении какого-либо программирования возможности состоят в том, что Вы использовали их экстенсивно. Самая большая проблема, которую люди имеют с ними, состоит в том, как включать и организовать их в Вашем приложении.

то, Что я нашел, что большинство людей делает, создают Utils.cfc или UDFs.cfc и вырезают и вставляют их UDFs, который они хотят использовать в компонент, как продемонстрировано ниже:

<!--- UDFs.cfc --->
<cfcomponent output="false">

<cffunction name="init" access="public” returntype="Any" output="false">
  <cfreturn this>
</cffunction>

<cffunction name="myUDF1" access="public" returntype="Any" output="false">
</cffunction>

<cffunction name="myUDF2" access="public" returntype="Any" output="false">
</cffunction>

</cfcomponent>

, Как только у Вас есть весь UDFs, который Ваше приложение будет использовать вставляемый в Ваш компонент, необходимо будет сделать доступное UDFs для приложения. Почти все, которые я видел, делают эту загрузку компонентом в область действия приложения. Следующая строка помещается в onApplicationStart() при использовании Application.cfc или просто добавив его в Application.cfm при использовании этого:

<cfset application.functions = CreateObject("component", "udfs").init()>

, Какой бы ни один Вы используете, Application.cfc или Application.cfm, результатами является то же; все Ваши UDFs доступны Вашему приложению, и можно использовать их свободно повсюду. Единственная разница - то, какое имя переменной Вы используете. Я использую application.functions, некоторое использование application.utils или application.udfs; вопрос doesn’t, снова, результатами является то же.

существует одна проблема, которую я имею с этим подходом, хотя, это является громоздким, и компонент UDFs станет огромным. Проблема с наличием такого огромного файла компонента редактирует его, становится кошмаром начиная с просмотра тысячи строк кода, не очень забавно, и также я заметил, что CFEclipse срывает на огромных файлах. Верный коллапс кода действительно обеспечивает некоторое облегчение, но должен быть лучший путь.

то, Что я хотел, должно было просто иметь один файл для каждого UDF, который я использовал и путь к моему приложению для загрузки их автоматически. Причина позади этого состояла в том так, чтобы, если я должен был отредактировать myUDF1, я мог бы просто открыть файл myUDF1.cfm и отредактировать то, в чем я нуждался. Я также хотел быть в состоянии захватить UDFs от [1 110] CFLib.org и просто бросить их в мое приложение, не имея необходимость редактировать что-либо. Если бы я когда-нибудь должен был удалять UDF из своего приложения, то это было бы столь же легко как удаление файла UDF и переинициализация моего приложения.

Для выполнения, что я хотел я изменил свой UDFs.cfc к 11 строкам кода:

<!--- UDFs.cfc --->
<cfcomponent output="false">

  <cfset variables.udfdir = GetDirectoryFromPath(GetCurrentTemplatePath()) & "udfs">
  <cfset variables.q = "">

  <cffunction name="init" access="public" returntype="Any" output="false">
    <cfreturn this>
  </cffunction>

  <cfdirectory action="list" directory="#variables.udfdir#" filter="*.cfm" name="variables.q">

  <cfoutput query="variables.q">
    <cfinclude template="udfs\#name#">
  </cfoutput>

</cfcomponent>

Поэтому, что точно продолжается?

, Короче говоря вот случай what’s: у Меня есть каталог, названный udfs в том же каталоге, что у меня есть свой UDFs.cfc. Это - каталог, что я поместил все свои файлы CFM UDF. То, что делает UDFs.cfc, просканировать этот каталог, когда это называют и автоматически включает каждый файл CFM, он находит. Таким образом это автоматически загружает любой UDFs в папке UDFs в себя (обычно названный "mixin").

, Таким образом, моя цель достигнута! У меня есть каждый UDF в его собственном файле, таким образом, я не должен просматривать огромный файл компонента путем прокрутки для нахождения его. Я могу теперь открыть и отредактировать его легко. Просто смотря на каталог, я знаю, какой UDFs мое приложение использует. Я могу автоматически добавить UDF с CFLib.org, просто сохранив текст от браузера в файл в каталоге. Плюс то, если я больше не должен использовать UDF в своем приложении, я просто удаляю файл из каталога, и это удалено из моего приложения во время следующего re-init. Все это обходится без необходимость коснуться основного файла UDFs.cfc.

Ниже пример того, на что похож один из файлов CFM UDF. Файл называют fullLeft.cfm и находится в каталоге UDFs.

<!--- fullLeft --->
<cffunction name="fullLeft" access="public" displayname="fullLeft" returntype="string" output="false">
  <cfargument name="str" type="string" required="true">
  <cfargument name="count" type="numeric" required="true">
  <cfif not refind("[[:space:]]", arguments.str) or (arguments.count gte len(arguments.str))>
    <cfreturn Left(arguments.str, arguments.count)>
  <cfelseif reFind("[[:space:]]",mid(arguments.str,arguments.count+1,1))>
    <cfreturn left(arguments.str,arguments.count)>
  <cfelse>
    <cfif count-refind("[[:space:]]", reverse(mid(arguments.str,1,arguments.count)))>
      <cfreturn Left(arguments.str, (arguments.count-refind("[[:space:]]", reverse(mid(str,1,arguments.count)))))>
    <cfelse>
      <cfreturn left(arguments.str,1)>
    </cfif>
  </cfif>
</cffunction>
20
ответ дан 1 December 2019 в 03:15
поделиться

Я думаю, что это зависит от Вашего стиля программирования, пойдите с тем, какой бы ни стиль Вы являетесь самыми довольными. Я нахожу, что самый легкий путь находится в application.cfm, установите переменную в области действия приложения к cfcomponent со всеми моими служебными функциями:

<cfif not isDefined("application.utilities")>
    <cfset application.utilities = createObject("component", "Utilities")>
</cfif>

Теперь можно назвать методы в application.utitlies отовсюду. Обратите внимание, что при внесении изменений в cfcomponent необходимо обновить переменную приложения с новым экземпляром Утилит.

1
ответ дан 1 December 2019 в 03:15
поделиться

если Вы используете Application.cfc (если бы Вы не, я настоятельно рекомендовал бы мигрировать на него от Application.cfm - его очень легкое, чтобы сделать), можно создать baseComponent.cfc со всеми методами UDF и иметь Application.cfc, наследовались baseComponent. затем в onRequestStart методе, устанавливает переменную, названную запросом app=this;

для запроса entiure можно затем использовать request.app.methodname () для доступа к UDF. его очень хороший и простой способ обработать UDFs

также, если Вам нравитесь Вы, может иметь весь Ваш cfcs, наследовались тому же baseComponent так, чтобы все Ваши cfcs имели те функции util как собственные методы. делает поблочное тестирование cfcs очень легким, потому что cfcs не должны отвечать на переданной (введенной) ссылке на компонент UDf, они - покойные его!

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

hth Jon

1
ответ дан 1 December 2019 в 03:15
поделиться
Другие вопросы по тегам:

Похожие вопросы: