storeStructIntoSession

gistfile1.cfm

<cffunction	name=	"storeStructIntoSession"
			output=	"false"
			hint=	"I store a form into the session scope">
			
	<cfargument	name=		"stTarget"
				required=	"true"
				hint=		"I am the target struct for storage." />
			
	<cfargument	name=		"sSessionKey"
				required=	"false"
				default=	"#createUUID()#"
				hint=		"I am the session key for the struct." />
				
	<cfargument	name=		"bIgnoreEmptyFields"
				required=	"false"
				default=	"false"
				hint=		"I am a toggle that will ignore empty keys." />
	
	<cfargument	name=		"lsKeysToIgnore"
				required=	"false"
				default=	""
				hint=		"I am a list of struct keys to ignore." />
	
	<cfset	var	stCopy=	duplicate( stTarget ) />
	<cfset	var	sKey=	"" />
	
	<cfloop	collection=	"#stCopy#"	
			item=		"sKey">			
		<cfif	listFindNoCase( lsKeysToIgnore , sKey )
				or ( bIgnoreEmptyFields and len( stCopy[ sKey ] ) eq 0 )>
			<cfset	StructDelete( stCopy , sKey ) />
		
		</cfif>
		
	</cfloop>
	
	<cflock	scope=		"session"
			type=		"exclusive"
			timeout=	"15">
		<cfset	session[ sSessionKey ]=	stCopy />

	</cflock>
	
	<cfreturn	sSessionKey />
</cffunction>

<!--- Store Form scope into session.plansearch --->
<cfif	structKeyExists( form , "fieldnames" )>
	<cfset	storeStructIntoSession(	stTarget=			form ,
									sSessionKey=		"plansearch" ,
									bIgnoreEmptyFields=	true ,
									lsKeysToIgnore=		"fieldnames,submit" ) />
									
</cfif>

I get where you're coming from. I've run a similar spacing setup before.

Like you, I have my own reasons for doing what I do. I use multiple machines and IDEs and this coding style displays fine in each. Github decided to change the tab default to 8 spaces, which is wonky no matter how you look at it.

My coding style is constantly evolving. I change my style when I find a better way, either through experimentation or reviewing code. If I think my way is better than the team standard, then I'll attempt to show them why and update the standard.

If the team standard was different from the default of 4 spaces for 1 tab, then I would adapt to fit for team code.

I figure if a team member wants to change the style, then they're welcome to do so. Some IDEs allow you to change formatting in a button press. Otherwise, you can do a simple find and replacements to change the spacing. The whole process shouldn't take more than a few minutes. (I have some replacement scripts if you're interested.) If you're coding differently from the team standard, then you get to live with the consequences of your choice.

I'll probably do a whole post on my coding style, but that's the gist of it (couldn't resist).

Yeah, most developers I hire use tabs, so I will too usually. Except for anything where HTML is output. In that case I stick with the standard that almost all CSS developers use and out dbl spaces. ## Jeff Coughlin

…

On Nov 14, 2011, at 14:33, Bradley Moore ***@***.*** wrote: I get where you're coming from. I've run a similar spacing setup before. Like you, I have my own reasons for doing what I do. I use multiple machines and IDEs and this coding style displays fine in each. Github decided to change the tab default to 8 spaces, which is wonky no matter how you look at it. My coding style is constantly evolving. I change my style when I find a better way, either through experimentation or reviewing code. If I think my way is better than the team standard, then I'll attempt to show them why and update the standard. If the team standard was different from the default of 4 spaces for 1 tab, then I would adapt to fit for team code. I figure if a team member wants to change the style, then they're welcome to do so. Some IDEs allow you to change formatting in a button press. Otherwise, you can do a simple find and replacements to change the spacing. The whole process shouldn't take more than a few minutes. (I have some replacement scripts if you're interested.) If you're coding differently from the team standard, then you get to live with the consequences of your choice. I'll probably do a whole post on my coding style, but that's the gist of it (couldn't resist). --- Reply to this email directly or view it on GitHub: https://gist.github.com/1284209