• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Putting user input into request scope

 
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Currently I have all my user input in a session scope bean, i.e sort method, current page number, and other form fields the user has entered, and this is bad for obvious reason. I now want to move to request scope, but this seems to be a little complicated. When I change managed-beans.xml to request scope, I just lose everything on the next request. First off, I have way too much user input to stick everything in the url. Second, I was thinking of putting all the input into hidden input fields so that they may be posted, and then I can pick them back up, possibly modify, then reset them again for the next request, but this seems like a lot of complex logic, especially because there are various places in the code that can modify the user input, so I would have to update my hidden input fields in various places all over my code. Finally, I was thinking of keeping everything in session scope, and keeping track of every client's browser session with some unique id. Does anybody have any alternatives / less complicated solutions?
[ September 15, 2006: Message edited by: peter black ]
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you could explain a bit more about what the app does, it would help. When I started reading your post I was thinking you just needed to store User data. Like a logged in user. Which a session is perfect for. But as I continued to read, I realized you are just talking about form data.

I keep general form data in request scope throughout all my apps, JSF or not. And I don't find it quite as complicated as you are making it out to be. What about these forms are you needing to persist the whole time a user is on your site? I am a bit confused.
 
joe black
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gregg Bolinger:
If you could explain a bit more about what the app does, it would help. When I started reading your post I was thinking you just needed to store User data. Like a logged in user. Which a session is perfect for. But as I continued to read, I realized you are just talking about form data.

I keep general form data in request scope throughout all my apps, JSF or not. And I don't find it quite as complicated as you are making it out to be. What about these forms are you needing to persist the whole time a user is on your site? I am a bit confused.



Yes, usually it is easy. However, I am working on a more complex app where there are no navigation rules, everything is handled by one class, which calls a service layer which talks to a soap web service which tells the jsf class which components to create. All the components I have are created in java code, since every aspect of the UI is generic. I have a bunch of tabs at the top of the UI, not jsf, so the first thing I need in session scope is the id of which screen I am currently on. Second, I display data in a 3rd party grid, where I have implemented custom pagination. The soap service caches data on its end and gives me a cache id. So when I go to, say, page two, I need to send the cacheId. So this is something else I need to keep through multiple requests. Also, a boolean which signals whether or not to use the cache, and which page I am currently on. Sorting is custom as well. It sends a new request to the soap service to get the sorted data. So I keep track of which sorting method to use as well, ascending or descending. The sorting is done via an ajax call, and I need to store the sorting options away so that other areas of the code may access them later. So there may be multiple requests while still on the same screen (there is not always a form submit). So as you can see it is not just form data.
[ September 15, 2006: Message edited by: peter black ]
reply
    Bookmark Topic Watch Topic
  • New Topic