Woe, cease fire! I, the 'original respondent', was just trying to exercise my awkward sense of humor. Kwan Suh, if I ever pick a fight, I want you on my side. You may be belligerent, but you make a good case.
I have worked on two shopping cart type applications with complex variables. On the first I used client scope and wddx, on the second I tried session variables. They both worked fine, but the session variables were more troublesome because things didn't work out as planned (and I did actually plan). My 'brilliant' idea was to use the Duplicate() function to copy all complex session variables to request scope in the application.cfm (to be 'efficient', not lazy), and then copy changed data back to the session variables as applicable in each action page. The problem was that the Duplicate() function was buggy (to put it mildly), and I finally had to resort to copying individual structure keys at the top of every page, and putting cflock tags around the queries, which, I agree, is very cumbersome. So we learn from our mistakes, but had the Duplicat() function worked correctly, I think it would have been a good plan. Perhaps when we upgrade to CF 5 it will work. The reason I spoke of hidden variables was that when using client variables, I stored the wddx in a hidden field rather than in a database. Also, before I got involved in the second appilication, it had been designed without session management, and hidden fields were used to pass data for each selected line item from one page to the next, which was was truly cumbersome to manage. We will probably never use clustered servers, but you have a very good point. Should we ever have the opportunity to work on an application that calls for it, it would be a sign of growth from a business perspective, but a perhaps a nightmare from a programmer's point of view. I hope Gyrus will be ready for his exam, now. Taking cover! Marianne -----Original Message----- From: Kwang Suh [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 7:11 PM To: CF-Talk Subject: Re: Session and Client Variables ----- Original Message ----- From: "Freddy" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, November 15, 2001 5:16 PM Subject: Re: Session and Client Variables > Kwang Suh wrote: > > > > My heart goes out to you! You sound like you've had a bad experience with > > a > > > session variable cult, or something. But if used in its proper context, > > > session variables can change your (work) life. > > > > Yeah, but what's "proper context"? Do people even bother to do enough > > analysis to say whether they should go client or session, or do people use > > session vars because that's what they've been using since they started using > > CF? > > > I would think that any application should be built with a well thought out > > plan. Utilize whatever is best in a given situation. A proerly used session > > variable works better than an inproperly used client and vice versa. Agreed. I'm saying that most people don't even create the well thought out plan. > > > > > In your darkest hour, when > > > confronted with the need to pass queries of information, the number of > > rows > > > unbeknownst to you, from one page to another, over and over again in a > > > endless, vicious cycle, you might find that session variables are your > > only > > > hope. > > > > Hardly. That's what WDDX is for. > > WDDX is great for hanling large recordsets but it is not as fast to access as a > session scoped query on a seperate page. Again the method used is depoendent on > what you need to do. > > > > > > > Yes, some people may have committed evil act in the name of session > > > variables, but don't let hypocrites turn you away from the tool that > > > delivered you from the hands of hidden form fields and time consuming > > > database calls. > > > > Why would I need hidden form fields and database calls when I'm using client > > variables? > > Take a look at your database activity. Using client variables will generate a > database call. Yes, I realize this. But I will bet you 1 million widgets that a properly configured RDBMS is _much_ better at handling locking than a properly configured CF server using session variables. Not to mention that my client app will actually scale, and your session app will not. I think the original respondent was referring to constant database calls for variables that should be persistent. > Also try holding a complex structure in a client variable. I've already mentioned this drawback. > > I would say use what works for you. Do not rely on any one method overly much. > If you do you will find that you are not going to get the full benefits that > working a rich scripting language like cf can provide. I think the overarching requirement for most, if not all, enterprise-class applications are reliability and availability. I can't see how using session vars meshes with this requirement. Hey, if all someone's making are small apps, go right ahead and use session variables. Just don't expect the application to be scalable and maintainable without some major rewrite. > > Just my 2cents worth > Frederic > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
