Better way of Initializing from CFEclipse Bean Wizard

Posted At : March 13, 2009 10:35 AM | Posted By : Tami
Related Categories: CFCs, CF Debugger, Application Framework, CFEclipse

I have been using the CFEclipse to create the Bean, DAO, and Gateway CFCs. Not because it is a perfect tool, but while I am still learning how to manage working in a Framework better (and faster), the CFEclipse provides a nice foundation to start from.

Also, in the Lynda.com tutorials, David Gassner uses these wizards and customizes get/set bean cfc to be able to reinitialize the bean variables from a form. This is great and has helped me wrap my head around the easily confusing method of setter and getters. BUT! When the form doesn't have a variable that wants to be set by the bean, I have to pad cfif statements everywhere.... Not good and with large tables a real PITA. So I came up with a better way of doing it using StructKeyArrays....

Here is an example of a simple event table Bean created by CFEclipse:

David customizes the code a bit to accept a form structure and reset the values:

This is great... except in real practice, if the form variable doesn't exists, like for checkboxes that are unchecked, or pulldowns now selected, an error gets thrown, wanting each instance of a form variable to be checked for existence first. Not good with large tables or complex forms.

So to fix it, instead of manually picking through and adding cfif isdefined's for each variable that may not be there, I used the form structures "FIELDNAMES" to pick out the columns that exist and assign them.

<cfcomponent alias="blahblah.cfc.events">
    <cfproperty name="eventid" type="numeric" default="0">
    <cfproperty name="event" type="string" default="">
    <cfproperty name="eventdesc" type="string" default="">
    <cfproperty name="eventtime" type="string" default="">
    <cfproperty name="displayme" type="string" default="">
    <cfscript>
    //Initialize the CFC with the default properties values.
    this.eventid = 0;
    this.event = "";
    this.eventdesc = "";
    this.eventtime = "";
    this.displayme = "";
    </cfscript>

<cffunction name="init" output="false" returntype="events">
<cfargument name="stValues" required="no" type="struct">
    <cfset var fieldarray = arraynew(1)> 

    <cfif isdefined('arguments.stValues')>

     <cfif arraylen(structkeyarray(arguments.stValues) ) gt 0>
<cfset fieldarray = structkeyarray(arguments.stValues)>
<cfloop from='1' to='#arraylen(fieldarray)#' index='i'>

<cfif findnocase('fieldnames',fieldarray[i]) eq 0 and findnocase('submit',fieldarray[i]) eq 0>
<cfset "this.#fieldarray[i]#" = evaluate(fieldarray[i]) >
</cfif>
</cfloop>
</cfif>
     </cfif>
    <cfreturn this>
    </cffunction>

The results is a concise package that eliminates the need to re-evaluate each form field for existance.

Comments (0) |

Print |

Send |

del.icio.us |

Digg It! |

Linking Blogs | 1128 Views

CFCs When you must use explicit naming -- Frameworks Potential Gotcha

Posted At : February 19, 2009 11:24 AM | Posted By : Tami
Related Categories: CFCs, Application Framework

Since HHWD often uses test databases and testing areas for internal development servers, and online client sandboxes, we set up our application.cfc to refer to many items by reference.

Instead of using datasource='databasefoo'

We will have an application.cfc entry:

<cfset application.dsn = 'databasefoo'>

then in the CFC cfquery use

<cfquery datasource='#application.dsn#'...


since the testing database and sandbox database aren't our production databases, we want to be able to quickly update just the application.cfc and have it point to the correct database without having to do  perform a find/replace across our site.
Similarly, We do the similar setups for CFCs. Since the testing server and sandboxes a different directory structure than our production area, we normally use:
and then refer to it in our code as:
This all works great .... EXCEPT when your framework/OO needs and wants an explicit reference. This would be cases where you are establishing a bean or using a returntype:
in DAOs:
 
<cffunction name="read" output="false" access="public" returntype="datafoo.cfc.data">

You must enter the explicit returntype. Putting the #application.cfc# in the returntype field throws a generic 500 "Server busy or starting" error. Cryptic and not particularly useful in the measure. 
The same situation occurs when you declare a bean argument with the cfc as its type:
<cfargument name="bean" required="true" type="datafoo.cfc.data">
You must use the explicit reference here as well.
As you can tell, I just spent a few hours in the school of head-bangers figuring out the issue... after I did a sitewide replacement of all "datafoo.cfc." with "#application.cfc#".


		
		
		 Comments (0) |  Print |  Send | 
    	 del.icio.us
		|  Digg It!
	    |  Linking Blogs 
	    | 791 Views


		
		From the Fields:  Framework Newbie.... WOW!
		
		Posted At : November 19, 2008 5:01 PM | Posted By : Tami

		Related Categories:
		CFCs, Application Framework, ColdFusion, CFEclipse
		
				
		
		WOW! My head is exploding AND I am impressed, motivated, and hungry for more. After watching Peter Bell's Business Object meetup, downloading ColdSpring, and reading the (cough) somewhat sterile and dry getting started guide, I feel overwhelmed. I understand beans and encapsulation, but I find that the code examples there over my head. Even .... Bruce Phillips Grade School Blog, which is geared towards "Coldspring 3rd graders" was too much. (I must still be in 1st grade).
Before I gave up however, I logged back into the Lynda site and watched David Gassner's tutorial on the CFEclipse. A kindergarten version. Using the CFEclipse's RDS Dataview, a right-click > Coldfusion Wizard > Create CFC creates a CFC, DAO, and Gateway components. I was able to use these and compare them to the setup in my own CFC to see just how it worked. 
Now, as I completed the tutorial and tested how the get and set methods work, I am amazed. The complexity is kindergarten level, the objects are encapsulated, and the code generated was fast and very effecient, without me having to do anything extra.  Granted, the sample code I was working with is very elementary, but now I am beginning to see how it fits together and how versatile it will be.
Thanks to David Gassner, Bruce Phillips, Peter Bell, and to Dan Wilson (for his posts and tutes, which I will be working through as well, when I get past the first grade)! 
		
		
		
		 Comments (0) |  Print |  Send | 
    	 del.icio.us
		|  Digg It!
	    |  Linking Blogs 
	    | 955 Views   
		
		
		
		
		Framework CRUD vs. Dynamic SQL
		
		Posted At : November 19, 2008 6:32 AM | Posted By : Tami

		Related Categories:
		CFCs, Application Framework, ColdFusion
		
				
		
		Day 2 of Framework learning curve and I want to throw out this question.
Historically, I have passed arguments to a CFC function that performs a read based on a variety of conditions and created a dynamic SQL query inside my 'READ' or sometimes inside my 'get' object. 
Here is an example:

<cfquery name='getFoo' datasource='#...#'>
select * from Foo where true
<cfif len(arguments.id)>
   and id=<cfqueryparam... value='#arguments.id#'>
</cfif>
<cfif isdefined('arguments.activeonly')>
   and isactive=<cfqueryparm... value='#argument.activeonly#')>
</cfif>
<cfif  .....
  and ....condition....
</cfif> <!--- you get the picture --->
</cfquery>
Can I continue to create a  'read'ish query that is fluid in nature and be able to retrieve data on a variety of conditions or... would it be better form to have different objects created and called for each different instance of needing to retrieve information? 
		
		
		
		 Comments (0) |  Print |  Send | 
    	 del.icio.us
		|  Digg It!
	    |  Linking Blogs 
	    | 907 Views   
		
		
		
		
		
		More Entries

Sun	Mon	Tue	Wed	Thu	Fri	Sat
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31