Discussions

Web tier: servlets, JSP, Web frameworks: Saving State inbetween Session and Request scope

  1. After using STRUTS, and looking at JSF (Java Server Faces), both these models are based on keeping user state either at page, request, session or application level. In a typical application you could create your form beans as session scoped so all your data is saved between round trips to the web server.

    My problem is we have many cases where we what to maintain session state in a formbean (used by a set of JSPs - imagine a typical multiple screen on-line order form), but this screen can be run multiple times by the same user in the same session (while in the middle of one of these orders, the user starts a second order in a spawed window). In this case we need a new instance of the formbean.

    To address this we leave the data in another class, and keep a map of these classes in the session. The formbean acts as a deligate for this data class, and we make the form bean request scope. When it gets constructed we get it to point to the correct deligate data class in the session map. This implies we also use some kind of unique key for the data bean, and that we store this key in a hidden field on the JSP, which the form bean can then use.

    My question is am i alone in this kind of problem / requirement? and if not is there any kind of consensus on how this should be achieved? I've already implemented this solution on top of STRUTS (as part of the Jaffa http://jaffa.sf.net project) and now i'm looking at moving this consept to JSF.

    Thanks for any input

    PaulE
  2. Continuations[ Go to top ]

    It sounds like continuations are exactly what you need. You can get more information about them at:

    RIFE Wiki : Web continuations

    and:

    RIFE lightning talk at Fosdem with a focus on Web Continuations


    This might also be interesting:

    Acceptable session support
  3. Continuations[ Go to top ]

    Looks like interesting work...How could i take bits of this code (i don't need a whole framework), and use it in my current open source project (http://jaffa.sf.net) which is under a LGPL license?
  4. Yep, I did exactly the same as you in my project. Reasons:

    1. Form classes correspond to Struts input/output protocol, so I did not want to abandon them
    2. Like you said, I might want to create several instances of UI object of the same type
    3. I did not want to manage form clasess manually
    4. If I did not need multiple UI objects, I could use session-scoped form classes as UI objects, but...
    5. These form classes would sit in the memory, I do not have control over their lifecycle
    6. I would need to remove large objects from form classes manually
    7. It would be hard to distinguish new request data from the old
    8. I wanted to have better abstraction from presentation layer
    9. So, I use form classes as transport objects only, and store my stuff in my own objects.
     
    Sometimes I think that Noosphere really exists ;)
  5. Yep, I did exactly the same as you in my project.
    It your project open source? I'd be interested in taking a look...
    5. These form classes would sit in the memory, I do not have control over their lifecycle
    We addressed this in Jaffa by having a thread that garbage collects idle (ie time since last request that used it) data beans (we call these data beans 'Components'), as a component may become zombied / idle well before the http session ever times out.

    How exactly did you tie the form bean for request back to the correct underlying UI object? I presume your form beans in this case were request or page scope? We hid the creation / posting of the hidden field in a <jaffa:Form> tag, which extends the basic Struts <html:form> tag, we then extended the form bean base class (ActionForm), and in the reset() method, associate the form bean to the correct delegate class.

    Any thoughts on how you'd do the same with JSF? Would you consider the same approach?
  6. Yep, I did exactly the same as you in my project.
    It your project open source? I'd be interested in taking a look...
    Well, it is not a PROJECT, it is just a small proof of concept. Which is already proved, as I can see ;)
    How exactly did you tie the form bean for request back to the correct underlying UI object? I presume your form beans in this case were request or page scope? We hid the creation / posting of the hidden field in a <jaffa:Form> tag, which extends the basic Struts <html:form> tag, we then extended the form bean base class (ActionForm), and in the reset() method, associate the form bean to the correct delegate class.Any thoughts on how you'd do the same with JSF? Would you consider the same approach?
    I do not do any of this. I prefer not to hide object IDs and other plumbing stuff. Here is what I do:

    * UI object aggregate business object. If business object was just created, it is not tied to database and can be safely abandoned. If it is existing business object, than UI object contains _copy_ of real business object, which can be edited as one like. Again, if update is aborted, database is not affected.

    * Obviously, each business object must have ID aka primary key. This ID is passed back and forth from action to form to JSP and back to form and to action.

    * Form beans are just pure transport objects. Each page which shows or inputs dynamic data is supposed to display an object. So, each page contains object ID. For example, when HTML FORM is submitted object ID is passed to form bean. UI objects (there can be several of them instantiated, but usually not a lot) are identified by ID of aggregated business object.

    * when data is posted to the server, I take ID from the form bean and locate UI object with that ID in the session. If it is not in the session, I can read it from the database, because object ID is a row primary key. Then I store the changes in the database. Object can be reloaded from database again, because everything is done using PK.

    Yes, I use request-scoped form beans, so I do not need to care about lifecycle, about overwriting of current bean values by new values from request, about contents of reset() method and about using this method at all.

    I finished an article about this stuff, which is hopefully be posted here on TSS :)
  7. problem with jaffa dropdown[ Go to top ]

    I am very new to jaffa .Can anyone tell me how can i populate the jaffa dropdown with the distinct records from database ?
  8. Oracle offers something called "processScope" which allows data to be passed between pages.

    It's currently Oracle-specific, but hopefully it'll be incorporated into the JSF spec at some point.

    More info at: http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/devguide/communicatingBetweenPages.html