Re: [OpenBD] Post your CFC's. Looking for best practices.

[Alan Holden]

Well I'll bet that great discussions on CFC practices have happened before, but I'll bite. Here's a rudimentary example from my ancient vault of templates. It won't run because it extends some other hypothetical objects. But you get the general idea. HTH, Alan Holden <cfcomponent displayname="Method_Template" extends="security" output="false" hint="Here's a template.">     <cffunction name="getAPIdemo" returntype="struct" access="remote" hint="This method returns foo from foo by email">         <cfargument name="appKey" type="string" required="true" hint="Optional license of calling server">         <cfargument name="sessionID" type="string" required="true" hint="Token representing the user - that the server is representing with this call. Usually granted by some login method">         <cfargument name="email" type="string" required="true" hint="Needed to locate foo record from foo table">         <!--- This will be the master structure we return to caller. All our results will wind up in here. --->         <cfset var struReturn = structNew()>         <!--- This request sub structure will list back whatever was passed in, very handy to have! --->         <cfset var struRequest = arguments>         <!--- Set a standard message structure from an extended method. For example, the structure could hold two strings (messageLog and messageUser). 'messageUser' contains words intended for the end user to read, while 'messageLog' is designed to be placed in an application log file, sent to a development email address, etc. --->         <cfset var struMessage = initMessage()>         <!--- Our methods always have global indicator of whether or not things worked as expected. At each step in the         function, we'll check this to see if everything's OK, and perhaps change it to zero if it's not. --->         <cfset struReturn.success = 1>                 <!--- METHOD-SPECIFIC VALIDATION - START --->             <cfif NOT isValid('email',struRequest.email)>                 <cfset struReturn.success = 0>                 <!---  The extended method below will update our messageUser string for us --->                 <cfset struMessage = setMessage(struMessage,"user","This email address is no good")>             </cfif>         <!--- METHOD-SPECIFIC VALIDATION - END --->         <!--- If the above checks out, then get security approval for this request. --->         <cfif struReturn.success>             <!---  you should extend some security method which can insure the requesting server & user is valid, and that he/she has some role or privilege needed to proceed, even what database to use  --->             <cfset struRequest.methodName = "getAPIdemo" />             <cfset struReturn.VRS = validateRequestSecurity(argumentCollection=struRequest)>             <cfif NOT struReturn.VRS.success>                 <!--- VRS was NOT successful. --->                 <cfset struReturn.success = 0>                 <!--- Just bubble up user message from validateRequestSecurity method to this one. Use a stock message setter that handles logging, emailing, whatever  --->                 <cfset struMessage = setMessage(struMessage,"user",struReturn.VRS.message.messageUser)>                 <cfset struMessage = setMessage(struMessage,"log","VRS just logged an error of its own")>             </cfif>         </cfif>         <!--- ACTIONS SPECIFIC TO THIS METHOD - START --->         <cfif struReturn.success>             <!--- At this point, a trap for any procedural errors is suggested  --->             <cftry>                                 <!--- Now let's do this method's ACTUAL business (run a query, store some values, etc) --->                 <cfquery name="struReturn.qResult1" datasource="#struReturn.VRS.userDSN#">                     SELECT foo FROM foo WHERE email = '#struRequest.email#'                 </cfquery>               <cfcatch type="any">                 <!--- something exclusive to this method failed --->                 <cfset struReturn.success = 0>                 <!--- set a pretty message for the user --->                 <cfset struMessage = setMessage(struMessage,"user","Unable to search database. Please try again later.")>                 <!--- I have a special version of setMessage accepts the entire cfcatch structure as an argument. --->                 <cfset struMessage = setCatchMessage(struMessage,cfcatch,"#getMetaData(this).name#.#struReturn.VRS.request.methodName#",#application.logFile#)>               </cfcatch>             </cftry>             <!--- ACTIONS SPECIFIC TO THIS METHOD - END --->         </cfif>         <!--- add these individual structures to the master return structure now --->         <cfset struReturn.message = struMessage>         <cfset struReturn.request = struRequest>         <!--- return master structure to caller --->         <cfreturn struReturn>     </cffunction> </cfcomponent> On 11/13/2013 8:05 AM, Jason Allen wrote: Hey Guys,  I'm curious if anybody would be willing to post some CFC files they've created, especially those that contain some best practices you feel other developers should know about.  Any takers? I think this could lead to a great discussion.  -Jason -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en   --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to openbd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en   --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to openbd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.