In general you would want to set the session values once after the user is authenticated and simply read them back from the session afterwards. This of course assumes that the values never change after the user logs in, if they do prepareSession is a pretty good place to reload them. Also you should only load the values if they are changed, otherwise you are making a lot of unnecessary JDBC calls slowing down your app (probably not a significant amount on it's own, but it can add up, especially in prepareSession).
Personally I would not store the individual values on their own in the session but place them in a central HashMap to keep them together. Remember the session scope is shared by both the model and view and it's possible someone else will use a session variable key you've used. Also by storing the values in the session itself you don't have to worry about activation/passivation of the AM.
Using a hidden outputText is a BAD idea. While the outputText is hidden from the user it's content is still present in the page source. Basically you have exposed all those values to anyone who can right click in the browser and "View Source". A big security failure. You can easily access any session variable in a managed bean with the code below (where blah is the key you used to set the value in the AM).
Thanks for your reply..
Could you please look at these two links about session scope and global user data .. That's why I used activation/passivation..
and in the second approach , if the variables are not security - critic , could we still use hidden outputText ? I asked it if they might not be initialized or something like that..
1 person found this helpful
I can see his point of view. I guess if keeping the MVC model is high priority then his solution would be needed. Personally in all the years I have been working with ADF I never had a need to reuse the model in any meaningful way. There have always been business logic or database changes that made reuse impossible or difficult beyond common base classes. That being said I also don't consider the session scope to be a dumping ground for data. At most I store just a couple of the most important ID's that are required to access the data a user can/should see (less than 10 or so numbers basically). From these couple ID's I can always join up a bunch of tables and get the data I need.
Personally I'm not sure how I feel about relying on activation/passivation. The process of creating the XML and saving it to the database, then reading from the database and parsing the XML just feels like a lot of unnecessary work to me. If you keep the amount info reasonably small keeping things in session scope works quite well since all that needs to be done is for the web server to sync the info between cluster nodes. Personally I avoid using class level AM variables that would need to be passivated and prefer to use a couple (three in my case) numbers that I can pass into my view objects as bind variables when getting data.
Thanks Jan ...