Prueba de la existencia del formato / estructura FORM en ColdFusion

Question

Problema: al solicitar el WSDL para un CFC , aparece el siguiente error: FORMULARIO variable no está definido . Sucede en esta línea de código, en el método OnRequestStart en application.cfc

<cfif structKeyExists(form,'resetappvars')>
    <cfset OnApplicationStart() />
</cfif>

Si solicito un método específico, funciona bien. He considerado usar cfparam para crear una estructura de formulario predeterminada si no existe, pero eso parece un truco feo y me preocupa que realmente cree la estructura de formulario en las variables o este alcance del CFC. ¿Quizás este también sea un error legítimo?

Nota: Esto solo ocurre cuando solicito el WSDL, si invoco un método directamente: el código se ejecuta como se esperaba sin problemas.

Actualización: Ejemplo de código Application.cfc: simplemente agregue cualquier CFC a su aplicación y solicítelo con ?wsdl para ver el problema. Esto ha sido probado (y falló) en ColdFusion 7 y ColdFusion 8.

<cfcomponent output="false">

    <cffunction name="OnApplicationStart" access="public" returntype="boolean" output="false" hint="Fires when the application is first created.">
        <cfset application.dsn = "my_dsn" />
        <cfreturn true />
    </cffunction>

    <cffunction name="OnRequestStart" access="public" returntype="boolean" output="false" hint="Fires at first part of page processing.">
        <cfargument name="TargetPage" type="string" required="true" />
        <cfif structKeyExists(form,'resetappvars')>
            <cfset OnApplicationStart() />
        </cfif>
        <cfreturn true />
    </cffunction>
</cfcomponent>

Answer 1

Esta publicación de Ben Nadel ofrece una lista detallada de ámbitos disponibles para diferentes tipos de solicitudes.

Al leerlo, puede descubrir fácilmente que el alcance del formulario no está disponible en un contexto dado, pero la url sí lo está.

Answer 2

Quizás intente agregar un:

 <cfif IsDefined("form")>...</cfif>

alrededor del código anterior?

Answer 3

También podría cfparam la variable que está buscando y luego cambiar su lógica un poco (suponiendo que resetAppVars sea un valor booleano:

<cfparam name="form.resetAppVars" default="false" />
...
<cfif form.resetAppVars>
  <cfset OnApplicationStart() />
</cfif>

Editar: no estoy seguro de si el código anterior podría considerarse un hack, pero me parece un CF bastante estándar.

Answer 4

He oído que es solo una cuestión de opinión, pero me parece que es incorrecto hacer referencia al alcance de su formulario dentro de un CFC, ya que no hay garantía de que el alcance del formulario estará disponible cuando se invoque su cfc y cuando se llama tu método. Es mejor asegurarse de que cualquier información que necesite estar disponible para el método se proporcione explícitamente a su objeto. Esto se puede hacer incluyendo un argumento:

<cfargument name="resetAppVars" type="boolean" required="false" default="false" />

Luego verifica argumentos.resetAppVars, y siempre está definido, pero el valor predeterminado es falso.

O creando un atributo en su objeto y creando un método de conjunto explícito:

(en la parte superior de su cfc)

<cfset this.resetAppVars = false />


<cffunction name="setResetAppVars" access="public" returnType="void" output="false">
   <cfargument name="flagValue" type="boolean" required="true" />

   <cfset this.resetAppVars = arguments.flagValue />
</cffunction>

En cuyo caso verificará contra this.resetAppVars. También puede definir esto localmente utilizando <cfset var resetAppVars = false /> como declaración, lo que lo convierte en un atributo privado de su objeto, y probablemente sea adecuado, por lo que el código que invoca el objeto no puede sobrescribir incorrectamente esta variable con un tipo no booleano. En ese caso, simplemente debería referirse directamente a resetAppvars en su prueba, en lugar de usar este alcance.

Answer 5

También puedes hacer esto:

<cfif NOT isSoapRequest()>...

y pegue la lógica restante dentro de esa porción.