Flex, Blaze DS and storing session data
Posted by cornel | Filed under Flex, Java, LCDS/Blaze DS
One of the biggest difference between the classical web applications (HTML/JS) and the rich ones (Java applets, Flex, Silverlight) is how can you store the state of the application.
With HTML applications we are used to using different hacks to store the state – either appending all the necessary information to the requests or storing the data on the server (and using a cookie or a session id to link the user and the information). Some even use a “dirty hack” and keep a small window open where you can store/retrieve all this information by using Javascript (yes, I have seen this unusual approach in several applications).
With Flex applications (and also with the other technologies mentioned before) the things are much simpler. You do not have several pages which are loaded from the server, instead you have an application that is loaded in the browser and can store the data using its internal data structures. The application will make requests to the server but only to exchange data (and in some situations to load modules), not to load whole pages. To make an analogy – it’s like having a HTML application composed of only one page that uses AJAX and JavaScript to load and build other pages (This is doable, I have seen a project where the guys were using this approach because of some strange requests from the client, but it was a nightmare to maintain and develop the application).
So you are able to store user preferences, user actions (for example the products added to a shopping cart) and other data directly into the client – the Flex application. It is more natural (in my opinion) than storing the data on the server and it is also much cheaper than buying expensive hardware for the middleware – you are using the client machine to store data so you are not overloading the server (think about having 100000 connected clients and session replication and you will understand what I’m talking about).
However there are several situations when you have to store a minimal amount of information on the server – the user identifier for example. After a successfully login authentication I have to store the user ID into the server session. After that this ID is used to check all the requests and to filter data that is sent to the client. Below I show you how to do that in Flex and what things you need to take into account. I’m using Blaze DS on the server side.
The FlexContext class can be used to access the FlexSession class which has several useful methods to set/get/remove attributes, to configure the timeout and session listeners, and so on. Here is some code that shows how to use them.
UserRoles userRoles = userHome.logIn(userName, passwd);
if (userRoles == null)
throw LoginFailedException(“Invalid login”);
FlexContext.getFlexSession().setAttribute(“userId”, userRoles.getUserId());
public Collection fill(List fillArgs, int startIndex, int numItems){
Integer userId = (Integer) FlexContext.getFlexSession().getAttribute(“userId”);
if (userId==null)
throw AuthenticationException(“No logged user”);
ASObject map = (ASObject)fillArgs.get(1);
Integer companyId = (Integer)map.get(“companyId”);
return new CompanyService().findProducts(
companyId,
userId);
}
Note: this is just a simple example how to use FlexSession. For user authentication and securing destinations read the LCDS developer guide, specifically the chapter titled “Securing destination”.
Important things to take into account when working with session data (taken from the developer’s guide):
- when using RTMP channel after a browser refresh the content of the FlexSession is lost; also the user will have to log in again
- you will have different FlexSession objects for HTTP, RTMP and NIOHTTP channels – so consider working with only one type of channel
- if you logged in using a RTMP channel you must log in again when switching to another type of channel
- FlexSession is not cluster aware - if a client connects to a different server in the cluster, the client receives a new FlexSession and the client will have to login again
August 22nd, 2008 at 11:27 am
[...] Source [...]