[jfim]

Can you elaborate a little more on the server-side statefulness of Lift and the issues you encountered?

I was reticent about statefulness on the server-side, until I read an article about statefulness in Lift[1], which does mention how having session affinity helps with it.

Mostly, my questions are: does it scale and how do you handle state loss (due to servers catching on fire or other hardware/software failures)?

[1] http://lift.la/lift-state-and-scaling

[shadowfiend]

State loss is something I've been doing a great deal of thinking about. Right now a page reload is necessary, and I've written code in the past to essentially store any modified fields before running the page reload and restore them when the reload completes.

However, I'm still working through the conceptual aspects of restoring a page without a reload, over AJAX, provided I can figure out a good way to do it without compromising Lift's basic built-in XSS resistance.

[jfim]

I don't know much about how Lift works, but would doing something akin to PJAX[1] (reloading the entire page via AJAX) work in your case?

With regards to state loss, the only way I can see it working is if you save everything to a system of reference, just like you'd do in Play. Unfortunately, that's also a major pain in the ass, as we've found out, especially in the case of multi-step forms in Play.

[1] http://pjax.heroku.com/

[shadowfiend]

But we have a system of reference in Lift—CSS selector transforms refer to an element by its location in the DOM, rather than by a given name. I think there's room there for a creative solution.