I'm not grokking your perspective. Read this: http://www.forta.com/blog/index.cfm/2006/9/24/Flex-And-Session-State-Management
to get a general gist of where I'm coming from, and why you shouldn't need to access server sessions from a Flex app. More comments in-line. Beau Scott wrote: > > When you store information in a flex app that is also stored on the > server, it’s really not “session” information anymore, it’s your model. > > By your example, you wouldn’t store the shopping cart information > solely in your flex application, but rather store it in a session > variable in your web application and retrieve that information into your > flex app for display. You're interpretation of my example is incorrect. I'd store it in the Flex application until such time as it was about to commit to the database. The code on the server would need to validate the data, yes, but it doesn't need session information on the server to do so. > If you stored it entirely in your Flex > application, you have no validation of the data in the client against > what the server would expect. It’s just not good practice. > What I was mainly cautioning against is storing authentication > information in a web app. Remember that values in memory can be easily > modified using memory hack apps without your Flex app’s knowledge, which > could provide a back door into your web application because you’d be > dealing with unchecked data. Data validation is a good thing to do, and I would always recommend it. Trying to protect authentication information from being hacked is good point also. Neither of these things are unique to the use of sessions, though. > Best practice (using your shopping cart example): > > 1: User clicks to add item to cart > > 2: Service command is issued saying to add the item to the server’s cart > session > > 3: (and this can either be a subsequent action or the result of the > first call) A list is retrieved of the current cart items according to > the server > > 4: rinse and repeat till cart is complete > > 5: on checkout, the items in the cart are not sent from the client up, > since the server is already aware of what it has (means you can’t inject > unchecked data into the cart, or if you do, it has no impact on the > application). Only new information is sent up, like customer addresses, etc. I view Flex development differently: 1) User clicks to add item to cart 2) Command is issued saying to add item to the cart. This needs no access to to a service. We just take the user's Cart object (an instance of an AS class) and adds a Product Object (also an AS class) to it. 3) Rinse and repeat until cart is complete 4) on checkout send the whole cart and customer info to the backend, validate it, and do whatever else you need. In both procedures, all the same data is being sent to and from the server. You'd actually generating more traffic if you're sending the cart details back to the client after each call (as you stated in step 3). It sounds like you're trying to approach a Flex application using the same request response paradigm of traditional web pages. I'm not yet convinced that is a good idea. -- Jeffry Houser, Technical Entrepreneur, Software Developer, Author, Recording Engineer AIM: Reboog711 | Phone: 1-203-379-0773 -- My Company: <http://www.dot-com-it.com> My Podcast: <http://www.theflexshow.com> My Blog: <http://www.jeffryhouser.com> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcomponents/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcomponents/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
