Domanda

Problema: quando si richiede WSDL per un CFC , ottengo il seguente errore: FORM variabile non definito . Succede in questa riga di codice, nel metodo OnRequestStart in application.cfc

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

Se richiedo un metodo specifico, funziona benissimo. Ho preso in considerazione l'uso di cfparam per creare una struttura di form predefinita se non esiste, ma sembra un brutto hack e temo che creerà effettivamente la struttura di forma nelle variabili o in questo ambito del CFC. Forse anche questo è un bug legittimo?

Nota: Questo succede solo quando richiedo il WSDL, se invoco direttamente un metodo: il codice viene eseguito come previsto senza problemi.

Aggiornamento: Esempio di codice Application.cfc: aggiungi qualsiasi CFC alla tua app e richiedilo con ?wsdl per vedere il problema. Questo è stato testato (e fallito) su ColdFusion 7 e 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>
È stato utile?

Soluzione

Questo post di Ben Nadel fornisce un elenco dettagliato di ambiti disponibili per diversi tipi di richieste.

Leggendolo puoi facilmente scoprire che l'ambito modulo non è disponibile in un determinato contesto, ma lo è url .

Altri suggerimenti

Forse prova ad aggiungere un:

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

intorno al codice sopra?

Potresti anche cfparam la variabile che stai cercando, quindi cambiare leggermente la logica (supponendo che resetAppVars sia un valore booleano:

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

Modifica: non sono sicuro che il codice sopra possa essere considerato un hack, ma a me sembra un CF abbastanza standard.

Ho sentito che è solo una questione di opinione, ma mi sembra improprio fare riferimento al campo di applicazione del modulo all'interno di un CFC, poiché non esiste alcuna garanzia che l'ambito del modulo sarà disponibile quando viene invocato il CFC e quando viene chiamato il tuo metodo. È meglio assicurarsi che tutti i dati che devono essere disponibili per il metodo siano forniti esplicitamente al proprio oggetto. Questo può essere fatto includendo un argomento:

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

Quindi si controlla argomenti.resetAppVars ed è sempre definito, ma il valore predefinito è false.

O creando un attributo sul tuo oggetto e creando un metodo set esplicito:

(nella parte superiore del tuo 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>

Nel qual caso verificherai contro this.resetAppVars. Puoi anche applicarlo localmente usando <cfset var resetAppVars = false /> come dichiarazione, che lo rende un attributo privato del tuo oggetto, ed è probabilmente corretto, quindi il codice che invoca l'oggetto non può sovrascrivere erroneamente questa variabile con un tipo non booleano. In tal caso, faresti semplicemente riferimento a resetAppvars nel tuo test, anziché utilizzare questo ambito.

Puoi anche farlo:

<cfif NOT isSoapRequest()>...

e inserisci la tua logica rimanente all'interno di quel blocco.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top