Title: Re: [Reactor for CF] Serializing Reactor Records
And of course, I didn’t mention it, but you’ll want to store created and last updated information for all records and write a script to delete all old records based on some kind of business rules (anything from not updated for an hour if you’re looking to provide a session like experience to not updated for 2 months if you want to associate this to persistent login credentials – I have one system where users can log back in and see their most recent cart).

Best Wishes
Peter


On 9/8/06 3:04 PM, "Peter Bell" <[EMAIL PROTECTED]> wrote:

Hi Kyle,

It depends what kind of information you’re trying to persist and how secure it needs to be. A couple of common examples are persisting a shopping cart or persisting answers to a multi-screen wizard based form. Lets say you’re persisting a shopping cart, then you create a cart table and a cart_item table in your db with the appropriate fields. Every time someone does something to their cart you persist it to the database (add item, create cart, update quantities, etc.). To associate the user to the cart you could either use client variables (it’s been a REALLY long time since I even looked at those, but I’m actually pretty sure they depend on sessions, so I’m not sure they will solve your problem. Anyone who’s actually looked at them since 1999 please chime in here!) or using an ID you concatenate to all of your URLs and forms. Typically you’ll get your framework to just add a CartID to all URLs and to add a hidden CartID field to all forms.

Of course, if I want to have fun, I can change my CartID in the URL and have a look at other peoples carts, so typically in a real world scenario you’ll use the ID along with a seed and some encryption function to create a nice long string (or you could just use UUIDs) which you use to associate the user to the appropriate ID.

Feel free to let me know offline if you have more questions, we’re getting a little off topic here!

Best Wishes,
Peter  


On 9/8/06 2:50 PM, "Hayes, Kyle D" <[EMAIL PROTECTED]> wrote:

Peter,

I appreciate your 2c, that is what I am looking for. And yes, we are switching to servers that are load balanced and the adminstrators would rather not do sticky sessions (which creates a sticky situation). Would you mind exanding on the specifics of persisting the objects in a database please? Thanks for your help!
Kyle Hayes
Web Developer / Programmer
WebAID - Anaheim
Boeing Information Technology
714.762.2894
[EMAIL PROTECTED]

 


From: Peter Bell [mailto:[EMAIL PROTECTED]
Sent: Friday, September 08, 2006 11:41 AM
To: [email protected]
Subject: Re: [Reactor for CF] Serializing Reactor Records

Hey Kyle,

Are you SURE you really want to do that?!  I would consider using some kind of client key and just persisting the objects in a database. I know there is the performance cost of the db call for each page request, but compared to serializing and persisting objects (possibly with relationships) using client variables, I’d at least consider it.

Can I ask why you’re getting rid of session variables? I’m guessing it’s to move to a multi-server load balanced solution that doesn’t have sticky sessions, but if it is another reason and you’re using a single server, I might even consider persisting the data in application scope (with the appropriate garbage cleaning routines you’d need to write) before I serialized everything to client vars.

Just my 2c.

Best Wishes,
Peter    


On 9/8/06 2:14 PM, "Hayes, Kyle D" <[EMAIL PROTECTED]> wrote:

Hey  All,

I just got news that in my new project I am not going to be able to  store data in session variables anymore and have to resort to using client  variables. My question to you all, since I cannot store my reactor record  objects inside a client variable, is there a serialize function or similar  available to me to serialize the data inside an object and then eventually  convert to wddx etc? Thanks.

Kyle  Hayes
Web Developer / Programmer
WebAID -  Anaheim
Boeing Information Technology
714.762.2894  
[EMAIL PROTECTED]

 

-- -- -- -- -- -- --  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for  ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
--  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  --


-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --


-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --


-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Reply via email to