As with the CardsArray.cfm file, we don't produce any output with ShuffleDeck.cfm. We test it with another test harness called testShuffleDeck.cfm. It's shown in Listing 4 and just includes CardsArray.cfm and ShuffleDeck.cfm, and then uses <cfdump> to show the shuffledDeckArray variable after the shuffling process. Its output is shown in Figure 2.

Okay, now that the deck is shuffled, may I deal the cards? Thank you; I'm glad this is such a friendly table. Listing 5 shows DealCards.cfm. It creates a two-dimensioned array named handsArray. The two dimensions represent hands and cards in each hand.

To deal, we use another nested loop (lines 34-40). For each hand, we create a new element in handsArray and initialize it as an empty array. Then for the number of cards per hand we just append the first element from the shuffledDeckArray to the hand and delete that first element from the shuffledDeckArray. The result of this process is the handsArray with the specified number of hands and cards per hand, and the shuffledDeckArray, which now holds the remainder of the deck. We use another test harness to set the parameters for the hands and cards per hand, run DealCards.cfm, and display the resulting arrays (Listing 6). Figure 3 shows those arrays.

So the deck has been shuffled and the cards have been dealt. But so far all we have to show for it are these lousy <cfdump> outputs. Not a very attractive game, is it? So now we want to build a way to make the dealt hands look like dealt hands. For that, we can use a set of images - one for each card, with the names matching the notation we used for cards in the arrays. Then it's just a matter of writing a nested loop to output the handsArray. That code from ShowHands.cfm is shown in Listing 7. It uses two nested counting loops, and their indices are i and j like the common practice we looked at earlier.

Since we need all the previous non-test code to make ShowHands.cfm work, we once again use a test harness as shown in Listing 8. It just includes the necessary files and doesn't set values for the number of hands or the number of cards per hand. We're just allowing ShowHands.cfm to use its default values for those variables. The final output is shown in Figure 4.

Arrays provide a powerful way to handle data that has a common purpose, like the cards in a deck; and whose elements aren't identified by name or idea. But until we've used them a few times, they aren't really a natural concept. So how do we decide an array would be a good idea? If you find yourself tempted to create variables with names like item1, item2, item3, etc., it's probably a good case for an array. On the other hand, if there seems to be related sets of variables - like firstName1, firstName2 and lastName1, lastName2 - it's probably a good case for a structure. Fortunately, you can find information on structures in this issue as well.

CFML also offers several array functions we haven't seen in this article, including ArrayIsEmpty, ArrayPrepend, ArrayAvg, ArrayResize, ArrayToList, ArrayClear, ArrayMax, IsArray, ArrayMin, ArraySort, ListToArray, ArrayInsertAt, and ArraySum. The names of these functions provide a pretty good indication of their purposes, so feel free to experiment with them on your own. I highly recommend the use of a test directory on your development box. You can create little CFML templates to test your ideas and play with code before you try it in a "real" environment.

If you're interested in a more complete discussion of complex datatypes in ColdFusion, you might be interested in my book ColdFusion Lists, Arrays & Structures. It can be ordered online at www.ProtonArts.com.