In other languages, you'd typically store the session in memcached or the database, and then run multiple web frontends that each connect to the shared memcache instance or DB server. Can you serialize closures and store them in an external backend, assuming the existence of memcached and/or database bindings?
(I'm not asking this to prove a point or be a dick...this is a real issue in a lot of deployments. Java/JSF takes the same approach - it stores the complete state of the user interaction in a tree on the server, and then uses either a cookie or URL parameter to retrieve that state. A coworker and I spent a couple weeks digging into the JSF internals to get it to operate statelessly; the base JSF framework worked fine with a configuration change, but the AJAX framework built on top of it choked miserably.)
What did you do to get the base JSF to work on multiple servers? I am having that issue now - whenever a server switch is done, the context set up by JSF is lost and a blank page shows. Results 2 thru n on the same server are fine, result 1 being the initial page (JSP) request. Thanks.
It'll serialize the UIComponent tree and store it in a hidden input field with every interaction, then restore the view from that field. Naturally, this doesn't work if you're using GET for forms. (There's an undocumented feature of JSF where you can change the form method using JavaScript and make it submit information via GET. It tends to break though - you can easily overflow query strings, and I recall some problems when binding components to bean properties.)
You have some page with an edit box and a submit button. When you submit, the data in the box transfers to the server, which displays a new page, which relies on session data to print something to your screen.
Your challenge is to create an application where the behavior of the second page can't be manipulated by by altering the URL.
The reason I don't quite understand the question is that I don't know how the contents of the text box gets to the server in the first place. Certainly once the text is on the server, if the server relies on closures for the second page, then it cannot be manipulated. Say it's http://arclanguage.com/second/cid=3. You can't change that pages because by the time you hit that URL, the text is already in the server and it operates with closures.
OK, I get that part. The part I don't understand is... the data has to get to the server sometime. If you're making a post to http://arclanguage.com/first then you can _effectively_ change the second page by altering the data then. So perhaps it's not in URL; that is, not like http://arclanguage.com/first?text=the%20entry. It's POSTDATA or whatnot. But you can still manipulate post data.
The data is not used on the second page, but on the third.
Submit on the first page sends the data using http post. The second page just displays a link "click here", and it's when following that link the user is unable to alter the data.
