A Warning About Generated Code
Posted By : todd sharp Posted At : July 8, 2007 10:08 PM Posted In: Code Generation, ColdFusion
9
I was just working with a bit of code generated from Illudium when I ran into the following error:
Oops!
Message Bean creation exception in model.snippets.libs.libService
Detail Cannot declare local variable tag twice.:Local variables cannot have the same names as parameters or other local variables.
Message Bean creation exception in model.snippets.libs.libService
Detail Cannot declare local variable tag twice.:Local variables cannot have the same names as parameters or other local variables.
A quick look at the code showed me the following:
<cffunction name="createtag" access="public" output="false" returntype="model.snippets.libs.tags.tag">
<cfargument name="tagID" type="uuid" required="true" />
<cfargument name="tag" type="String" required="false" />
<cfset var tag = createObject("component","model.snippets.libs.tags.tag").init(argumentCollection=arguments) />
<cfreturn tag />
</cffunction>
<cfargument name="tagID" type="uuid" required="true" />
<cfargument name="tag" type="String" required="false" />
<cfset var tag = createObject("component","model.snippets.libs.tags.tag").init(argumentCollection=arguments) />
<cfreturn tag />
</cffunction>
My 'tag' table has a column 'tag' - so the generator does what it always does - made my bean with the arguments supplied to it. Unfortunately my decision to name both the object and the column 'tag' led to the duplicate variable naming and thus the error.
Thankfully I caught the error rather quickly (which gives me a bit of confidence that I'm starting to "get it").
Bottom line is - like many have said - don't rely on code from a code generator to work "out of the box". Make sure you fully understand what's going on before you simply plug it in to your app.
But, yes, code generators can create some very subtle, hard to figure bugs because of naming conflicts so this is a good post for others to be wary of.
The generator itself knows nothing about your app...it just applies table metadata in the form of XML against templates...so it isn't going to notice naming conflicts. It also has no idea, of course, of the intent of your app. All of that is up to you to code into there. The goal of my generator is simply to give you a head start and eliminate some of the most tedious portions of the coding.
Haven't done it yet, but I treat metadata like any other kind of data which means I can use the generic validation, transformation, ORM and other code I have to perform operations on my metadata before allowing the user to save it and passing it to the generator. Because of that, I'd just have a custom validator called MustNotMatchList with an enum of values that the name of a column property wouldn't be allowed to match (or the PropertyName property if you make the column name identical to that in your metabase). If it did, the user would be shown their form with the error if they were using the cms to enter the metadata, or an import error would be thrown if they were trying to import an XML file they'd written containing the metadata.
Make any sense at all? The only problem is that I work with metadata SO much, I have an awful lot of tooling that I take for granted . . .
:)