Session GUID with Ajax

[Christ Taylor]

Starting with Lift and I was wondering.
I have worked extensibly with Apple WebObjects and I see that lift is built with the same principles in mind. The good thing about Lift is that Lift can do comet very easily because it can use non-blocking from the underlying container. Here is my question:
Correct me if I am wrong: when a user is on a page and execute a lot of Ajax calls.Doesn't the session get out of sync with the rest of the page that is not taking part in the Ajax call? If thats the case, how does Lift solve it without having problems with the back-button support?
Thanks.

[Matt Farmer]

Hi!

Happy to hear you're getting started with Lift! Welcome to the community. 

I'm not sure I understand your question. Can you describe a sequence of events that illustrate what you're walking about?

—
Matt Farmer | Blog | Twitter

GPG: CD57 2E26 F60C 0A61 E6D8  FC72 4493 8917 D667 4D07

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Diego Medina]

Hi,

is the problem you are trying to solve what is described here https://blog.fmpwizard.com/2011/06/15/back-button-and-bookmark-meet-lift-comet/ ?

If that is the case, then this updated post may be what you are looking for

https://blog.fmpwizard.com/2011/07/13/back-button-and-bookmark-meet-lift-comet---revisited/

Regards,

Diego

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
http://blog.fmpwizard.com/

[Christ Taylor]

Sure, I am just exploring for now and enjoying it. Hopefully, I might be able find a job doing Lift since I am tired with the alternatives out there.
Here is my problem:
Lift is a stateful web-framework.
For the back-button to work, It means that the framework has to cache each page in a Map  to be able to  return the same page without having to regenerate all the dynamic stuff. Correct?
Since I am a Lift newbie, pardon my ignorance. I assume that there is also a limit regarding the number of pages that the back-button can reach?
Lets say that the number is 30 and I clicked 31 times on the Ajax link. How is Lift going to react?

Thanks

[Antonio Salazar Cardozo]

No, page state is independent on each page load, but it's also independent of

the URL. You use SiteMap to map a URL to a particular template, which template

in turn can invoke snippets, and those snippets can preserve request state. Request

state is typically used more to enable rich on-page interactions that update the

backing system state. So if you hit the back button, you'll get a fresh load of the

page, but your actions from before should have been persisted and should therefore

be available for the initial page load (which is done from scratch).

As an example, say you have a site with companies and users.

You land at /. This is mapped to index.html, and there's a button there to add a company.

Let's say this, via AJAX, adds the company to the company list without a page load.

You then navigate to the company page, /companies/1, by clicking on its name.

Then you hit the back button.

At this point, index.html will get rerendered, but it will be looking up data from your

persistant storage, which should have the company in it. So it will render the page

afresh, but with the latest data, thus the new company will be added.

Hope this clarifies things a little. Not sure if that answers all your questions yet.

Thanks,

Antonio

[Christ Taylor]

Oh, I see. So it is not really a back-button. A back button will want you to have the page show as it was before you change the database state. Thats one of the reason why people use a redirect when a database state has been modified. Anyway, I think I now understand how it works in Lift.
Thanks.
Time to start experimenting.

[Antonio Salazar Cardozo]

A back button that unwinds server-side state is either a client-side optimization (some

browsers preserve the previous page in-memory for a time so going back can be

instantaneous), or requires the server to maintain significant portions of prior system state

in memory (or that you be using a database that allows you to view a snapshot of its

state like datomic, of course). You can, of course, do this, but it's not the standard way

that the back button works on the web as far as I know. You can also achieve this in Lift,

but you'd be tracking that kind of stuff in session state rather than request state, and

session state is governed by a cookie.

Thanks,

Antonio

[Christ Taylor]

Correct.
That was my initial question. It was to know whether the server maintain already rendered page in memory to support real back-button functionality?
Thank you for clarifying.

[Antonio Salazar Cardozo]

I don't want to argue semantics too much, but I will mention that I don't think there

is anything any less “real” about the back button behaving as it currently does—indeed,

I think this is the most expected behavior of the back button on the web as it exists today,

because it is far and away the most common behavior and has been for some time. I'm

not saying it's the *only* behavior, of course :)

Something else that came to mind while I was thinking of this—the client doesn't send the

server any indicator that a page render is related to a back button press vs a fresh page

load, so there is, in fact, no way to tell that someone hit back to get back to the list of

companies (per my example above), vs typing /companies directly into the URL bar, or

clicked on the Companies List button from the page that was rendered after a new

company was added. I've seen sites try to implement per-page-render ids in the URL

to deal with this, but at that point you break all sorts of other expectations about the

browser experience. However, it is doable :)

To which end, Lift provides enough hooks around the rendering pipeline that it probably

wouldn't be difficult to capture the rendered output of a page and store it for future re-serving;

the only complicated part would be figuring out when to re-serve what, and when to discard

that rendered output for a given client/session.

Thanks,

Antonio