Yes, it makes sense. My point was simply that if you serialize the entire "Variables" scope you will get much more than just your instance data because the "Variables" scope inside a CFC contains a key called "THIS" (which contains the entire "THIS" scope) as well as keys for all methods of the CFC. Thus, if you serialize all of "Variables" you will end up with a WDDX packet much larger than it needs to be -- and if you rewrite all of that to "Variables" you will likely mess up your CFC because the methods won't deserialize into methods (I think that's true, haven't checked).
Thus, one simple solution is to use something like Variables.instance and then use "instance.myDataX", so your serialize() method can just serialize "instance" and your deserialize method can just load your data into "instance". The alternative I suggested was to do some work to make sure you only serialize the parts of "Variables" that aren't "THIS" and aren't methods (using the isCustomFunction built-in function). Hope that clarifies. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Justin Balog > Sent: Wednesday, September 24, 2003 7:47 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [CFCDev] Serialize? > > > > Nathan, > > I don't quite understand what you mean. I set my cfcs up using > > variables.myData1 > variables.myData2 > > > Then an init() > > Then getter() and setter() for the instance vars. > > Are you saying that this will present a problem for serialization. The > reason I want to serialize is when an ODBC connection failture occurs, I > want to serialize the object, write to file, then generate a UUID ref for > that object, and capture the 'mach-ii event' that was going to > occur. That > way I can just put the UUID into a form or something (some maintenance > interface) rebuild the object and execute the event, thus recovering the > event. > > Does that make sense? > > Thanks, > > Justin > > -----Original Message----- > From: Nathan Dintenfass [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 23, 2003 9:54 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Serialize? > > > Keep in mind that Variables scope inside a CFC contains not only your > "instance" data but also the "THIS" scope and all the methods of the CFC. > It's one of the reasons I have continued to use > "variables.instance" for my > instance data (I too use a similar method to the one Barney talks about to > serialize and store the information I need to remake a component) -- I can > then just serialize "instance" instead of worrying about the > other "junk" in > "Variables". > > The reason this matters in your case is that if you just serialize > "Variables" your packets could end up being quite a bit larger > than you want > them to be (or than they need to be). > > If you don't want to use "instance" (or whatever name) you can always loop > through "Variables" and only store things that aren't "THIS" or methods. > > > > > > From: "Barney Boisvert" <[EMAIL PROTECTED]> > > Reply-To: [EMAIL PROTECTED] > > Date: Tue, 23 Sep 2003 16:28:55 -0700 > > To: <[EMAIL PROTECTED]> > > Subject: RE: [CFCDev] Serialize? > > > > You'll have to searialize the sub-CFCs indivudually. > > > > So you'll actually want something like this (forgive the mixed syntax, > > typing tags for everything takes too long): > > > > function serialize() { > > result = structNew(); > > result.CFC = structNew(); > > result.nonCFC = structNew(); > > for (i in variables) { > > if (isObject(variables[i], "WEB-INF.cftags.component")) { > > result.CFC[i] = variables[i].serialize(); > > } else { > > result.nonCFC[i] = variables[i]; > > } > > } > > <cfwddx action="cfml2wddx" input="#result#" output="temp" /> > > return temp; > > } > > > > Your deserialize() function would have to change as well, of course, but > > would follow a similar pattern. > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> Behalf Of Justin Balog > >> Sent: Tuesday, September 23, 2003 4:14 PM > >> To: '[EMAIL PROTECTED]' > >> Subject: RE: [CFCDev] Serialize? > >> > >> > >> That's a cool idea, will the variable ref work if your cfc is > composed of > >> cfcs? Or will I have to serialize them individually? > >> > >> > >> Thanks, > >> > >> Justin > >> > >> -----Original Message----- > >> From: Barney Boisvert [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, September 23, 2003 4:58 PM > >> To: [EMAIL PROTECTED] > >> Subject: RE: [CFCDev] Serialize? > >> > >> > >> You can't serialize an entire CFC directly, because it's made > up of more > >> than just data. The way I'd do it is to have a serialize() and > >> deserialize() method in your CFC. The first will take the > CFC's internal > >> state, wrap it up in whatever way you deem fit, and return a WDDX > >> packet of > >> that data, which can be stored however. The deserialize() method > >> would take > >> that WDDX packet, and revert the CFC to the stored state. If you're > using > >> 6.1, you should be able to just do the whole variables scope. > >> > >> <cfcomponent name="Serializer"> > >> <cffunction name="serialize" ...> > >> <cfset var result = "" /> > >> <cfwddx action="cfml2wddx" input="#variables#" output="result" /> > >> <cfreturn result /> > >> </cffunction> > >> > >> <cffunction name="deserialize" ...> > >> <cfargument name="data" ... /> > >> <cfset var temp = "" /> > >> <cfset var i = "" /> > >> <cfwddx action="wddx2cfml" input="#arguments.data#" > output="temp" /> > >> <cfloop collection="#temp#" item="i"> > >> <cfset variables[i] = temp[i] /> > >> </cfloop> > >> </cffunction> > >> > >> <!--- other methods ---> > >> </cfcomponent> > >> > >> To use it, you'd do something like this: > >> > >> <cfscript> > >> one = createObject("component", "Serializer"); > >> one.init(); > >> one.doSomething(); > >> wddx = one.serialize(); > >> > >> two = createObject("component", "Serializer"); > >> two.deserialize(wddx); > >> > >> // now 'two' has the exact same state as 'one' > >> </cfscript> > >> > >> > >> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >>> Behalf Of Justin Balog > >>> Sent: Tuesday, September 23, 2003 3:34 PM > >>> To: '[EMAIL PROTECTED]' > >>> Subject: [CFCDev] Serialize? > >>> > >>> > >>> > >>> I don't even know if I am using the correct term? Is there a > >> quick way to > >>> serialize a cfc, say in to a WDDX packet? Basically, I want > to take an > >>> instance of a cfc and write it to a file in a meaningful way > >> (i.e. WDDX or > >>> XML) in case there is a dB error or ODBC connection failure. > >> Any thoughts > >>> on how to do this without having to call all the > getters/setters of the > >>> object itself. > >>> > >>> > >>> Thanks, > >>> > >>> Justin > >>> ---------------------------------------------------------- > >>> You are subscribed to cfcdev. To unsubscribe, send an email > >>> to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > >>> in the message of the email. > >>> > >>> CFCDev is run by CFCZone (www.cfczone.org) and supported > >>> by Mindtool, Corporation (www.mindtool.com). > >>> > >>> An archive of the CFCDev list is available at > >> www.mail-archive.com/[EMAIL PROTECTED] > >> > >> ---------------------------------------------------------- > >> You are subscribed to cfcdev. To unsubscribe, send an email > >> to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > >> in the message of the email. > >> > >> CFCDev is run by CFCZone (www.cfczone.org) and supported > >> by Mindtool, Corporation (www.mindtool.com). > >> > >> An archive of the CFCDev list is available at > >> www.mail-archive.com/[EMAIL PROTECTED] > >> ---------------------------------------------------------- > >> You are subscribed to cfcdev. To unsubscribe, send an email > >> to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > >> in the message of the email. > >> > >> CFCDev is run by CFCZone (www.cfczone.org) and supported > >> by Mindtool, Corporation (www.mindtool.com). > >> > >> An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email > > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > > in the message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
