Other Places to Store WDDX Packets

So far, the examples in this chapter use text files as a place to store WDDX packets. But the great thing about WDDX packets (okay, one of the great things) is that they can be stored anywhere ordinary text can be stored.

Storing Packets as Client Variables

One useful place to store WDDX packets is in ColdFusion's built-in CLIENT scope.. As you probably already know, once you store a value in the CLIENT scope, that value will remain associated with the client (basically, the browser machine). Client variables are nifty because they are stored on the server side (by default), yet they follow each of your users around as they use your pages over time. In many respects, client variables are superior to session variables, because they survive between server restarts and can be shared by multiple servers in a cluster.

One of the limitations of the CLIENT scope, however, is that it can be used to store only what ColdFusion considers to be simple values (strings, dates, numbers, and booleans)because the underlying storage mechanism is only capable of storing simple strings. ColdFusion won't let you store a structure, array, or query object in the client scope because it can't be expressed as a string.

Of course, you can just convert the structure, array, or recordset to a WDDX packet and then store the packet in the CLIENT scope. Because the packet is made up of ordinary text, ColdFusion won't mind storing it as a client variable. When you want to use the value, you can just read the WDDX packet back from the client variable and deserialize it.

For instance, suppose you have a structure called UserSettings that holds information specific to each user. You can easily store the structure as a client variable using this code:

 <cfwddx action="CFML2WDDX"         input="#UserSettings#"         output="CLIENT.MySettings"> 

Later, you could read the values back from the CLIENT scope using code similar to the following. If the CLIENT.MySettings variable doesn't exist or doesn't contain a valid packet, a new and empty structure is created with StructNew().

 <cfif IsDefined("CLIENT.MySettings") and IsWDDX(Client.MySettings)>  <cfwddx action="WDDX2CFML"          input="#CLIENT.MySettings#"          output="UserSettings"> <cfelse>  <cfset UserSettings=StructNew()> </cfif> 

Alternatively, you could use the WDDXClientRead() and WDDXClientWrite() functions from Listing 16.7 (refer to Table 16.4). Using the functions, you would save the UserSettings structure like this:

 <cfset WDDXClientWrite("MySettings", UserSettings)> 

The structure could later be retrieved like this:

 <cfset UserSettings=WDDXClientRead("MySettings")> 

NOTE

If you are using the Registry to store your client variables, it's possible that a very large WDDX packet would be too large to store as a client variable.

Storing Packets in Databases

I've explained the advantages to storing user-specific information as WDDX packets in client variables. Depending on how you have configured ColdFusion, your client variables are probably being stored in a database, which means that the special database tables added by ColdFusion to your database are being used to store the packets.

You can also store WDDX packets in your own database tables. Just create a text, memo, or varchar type of column in the appropriate table. Serialize whatever data you want to store using <cfwddx>, and store the resulting WDDX packet using ordinary SQL INSERT or UPDATE syntax. To retrieve the data, just get the packet from the database using a SELECT query, and deserialize the packet.

All that said, many databases and database drivers were not necessarily designed for selecting and updating large amounts of text on a high-volume basis, so this type of solution may not scale particularly well. A related idea would be to save the WDDX packet as a separate file on the server's drive, using the database primary key as the filename.

TIP

You could easily create convenience functions (similar to the WDDXFileRead() and WDDXFileWrite() functions from Listing 16.7) that include the <cfquery> code needed to move the packets in and out of your database.