Comet Rehydration vs Early Redirect

[Dylan Halperin]

Hi all,

I recently upgraded my project's Lift dependency to 3.2, and am quite happy with the new Comet Rehydration feature, but I've run into an odd situation and am hoping for some advice.

The scenario is as follows:

My app has three main states; normal operation, needs install, needs update. If either of the two "needs" states are active, there's a redirect to the respective install/update page, both of which have a comet component for triggering and watching the progress of said install/update.

If I have one of the pages in my app open, then I restart the webapp into the "needs update" state, the comet on the page I had open will try to "rehydrate" itself. To my knowledge, the rehydration process involves reloading the current page in an iframe, then stealing the comet logic out of it. But due to the redirect logic, reloading that page instead loads my update page, and I get undesired comet content in a normal page.

My first thought is to add a JS call to the update/install comet, along the lines of `if(currentPage != updatePage) redirectToUpdatePage()`, so that when the normal page's comet rehydrates and gets the updater comet, it'll still be redirected as intended.

But I'm hoping there's a way to deal with this situation that is (or can be) built in to Lift itself. Perhaps some kind of check in the rehydration process to guard against a redirect response? If not a built-in solution, if there are any better ideas that my initial JS-based redirect, I'd be glad to hear them.

Thanks,

~Dylan

[Matt Farmer]

Hmmm. This is an interesting problem.

I (think) we may have enough information to check the type of the comet and do something different if it has changed. Joe would know best though. I think in the short term, your JS solution is what I would do. :)

--
--
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.

[Joe Barnes]

Yeah, I definitely did not anticipate a page refresh to result in getting a different page due to redirect logic on the server. As you've discovered, the rehydration assumes that the page can be refreshed at any time to find a replacement for all of the comets on the page. Hence dynamically created comets, server state changing the page returned, etc aren't handled out of the box.

Your idea for the JS page check sounds good to me. As for Lift handling this situation automatically, I imagine this page check (or some form of it) would work. I'll have to think about it some more (I might have to review the code too, that's been a while!). Because of other challenges like the aforementioned dynamic comets, code changes, etc, it might be best if Lift's rehydration also makes sure that all of the expected comets exist. If not, refresh the page. This should theoretically handle the redirect problem too (unless perhaps IDs happen to line up exactly...) anyway, just some thinking aloud here...

Let me know what you think. I'm happy to hear someone else is finding the feature useful!

Joe

/**

 * Joe Barnes

 * Owner/Principal Consultant, joescii, llc

 * 256.541.0377

 * j...@joescii.com

 */

[Dylan Halperin]

Thanks for your responses guys!

Something that crossed my mind for the framework-level solution was for the comet initialization and rehydration code to have some kind of identifier for the comet class. So if you load a page with a comet actor of class A, then when it rehydrates and you end up with a comet actor of class B, you know something's fishy.

"Make sure all of the expected comets exist" seems like a good idea to me. If you had the class tagging thing for the comet types, you could compare the set of comet types before and after rehydration. If the sets are equal, then rehydration is ready to go, otherwise, you may have been redirected. I suppose that approach could cause problems if there was conditional initialization of comet things - a contrived scenario could be "if the current minute is divisible by 2, don't render this comet". Not sure if that's something worth worrying about or not...

As far as automatically refreshing the page, if you do go that direction I hope it will be configurable. Prior to comet rehydration I had wired my app to pop up a notification that prompted a refresh, rather than simply auto-refreshing. The auto-refresh ended up being confusing to our users.

~Dylan

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.

--
--
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.

--
--
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 a topic in the Google Groups "Lift" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/liftweb/2h5UFC5moho/unsubscribe.
To unsubscribe from this group and all its topics, send an email to liftweb+u...@googlegroups.com.

[Antonio Salazar Cardozo]

I thought we did try to do some basic identification of comets in the really poor rehydration thing

Joe based his work on… I forget what the current stuff looks like unfortunately <_<

Antonio

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.

--
--
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 a topic in the Google Groups "Lift" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/liftweb/2h5UFC5moho/unsubscribe.

To unsubscribe from this group and all its topics, send an email to liftweb+unsubscribe@googlegroups.com.