My approach to development can best be described as “results-driven”. I like theoretical techniques, I like knowing why things work the way they work and I always like to hear about other (and perhaps better) ways to accomplish what I have done but absolutely first and foremost for me when I am developing is “getting it done” and “making it always work”. Consequently my code is often pretty brute force.
Case in point…the documentation says I should be able to pass a requestScope value between pages but, alas, no.
I want the benefits of shorter lifespan scopes so whenever I want to pass something from one page to another in the “requestScope”, I put it in the sessionScope first, move to the next page, read the sessionScope value in the next page, place it into a viewScope value then set the sessionScope value to null.
I don’t like it but it works for now until passing values on the requestScope actually works.
The lifespan of a request scope is a bit unknown.
I have been using the same method, due to the fact that a user can open the same page twice and what happends then if you store data in the sessionscope, you will get strange results. 😉
/Fredrik
Yeah in earlier apps I used a lot of sessionScope vars but found that managing them was quite a chore.
My guess is that the XSP library actually performs a request before doing what you asked it to do and since a request was already executed, anything on the requestScope is now gone.
Dunno. Just know I can't use it and I wish I could. Thought it was only me that had this problem until the other day somebody really strong with the XPages Force asked if anyone had gotten the requestScope thing to work like in the help.
Same here, I tried to pass a requestScope variable from one page to another, as described in the help. It doesn't work. It works only when you stay within the same page, unfortunately…
I'm probably talking over my head here… but I don't THINK that setting a scope variable to null is the same as "removing" it. Don't you want to do varName.remove? Again – I might be wrong.
I would just add… and this might be a preference also I realize… but for scoped vars i really like using the .get and .put methods. It's a little more to type.. But it's a good habit for Java isn't it? And lord knows what might happen if they added a method to a scope variable that happened to be the same as a var name.
Just my 1 cent. 🙂
David,
You may be right on the null thing but memory management was not the point here. The point is I do not want there to be a value after this page navigation. I thought by setting it to null that garbage collection would then remove the variable from memory but if that is not the case I am still fine with it.
If you duplicate scoped variable names with other variables-things may not work the way you want them to. Other people are using objects and functions in scoped variables so there is definitely a possibility for conflict there but no more than any other shared coding space I suppose.
I'll leave the good habit call to others. Scoped variables are Java Maps and, as such, their entrys can be accessed as map.keyname just as easily as using the put/get methods.
Hi,
the requestScope works as designed. Only the behaviour of a redirection via SSJS (by sending a response to the client and the client sends a *new* request to the server) in the default configuration of XPages are causing the "loss" of the requestScope data.
If you add a "xsp.redirect=false" to the xsp.properties-File, the requestScope will work as expected.
Sven
Hi Sven,
First, your blog is awesome!
Second, nice to know that switch is there. It confirms what I suspected (request within a request kind of thing). As you mentioned on your blog, there is a tradeoff for using this setting and that tradeoff may not be acceptable in some situations but, as I like to make people know all the options, I am glad you pointed this out. Thanks!
Sven,
Doesn't that cause other issues as enumerated by this post:
http://blog.intrellise.com/that-darn-requestscope-part-2-implications
Hi John,
yes it will cause other issues. But this why a clientside redirection was implemented – it is just a tribute to update the location bar in the client. The problem then is the loosing of the request scope-functionality.
To fix this, with JSF 2.0 a flash scope was introduced:
http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/#scopes-flash
Here is a implementation for XPages:
http://www.bleedyellow.com/blogs/andyc/entry/a_flash_scope_for_xpages?lang=en
Sven
Hello!
I'm trying this out, using an ApplicationLayout and a Navigator control, both from the ExtLib. I create them as basic nodes, and set the sessionScope to "xpPage1.xsp", then a context.redirectToPage("xpPage1.xsp"). After doing this for three different navigator items, I ended up with the following error when trying to open any page with the ApplicationLayout, using Chrome:
Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.
I've deleted the cache, and even tried this on two computers. Still no go. Searches for XPages, and still no go. Any ideas?
Thanks, in advance!
Steve in NYC
That indicates the redirects are all trying to execute over and over when you load the page. Have you tried this with a single node?
I'll give it a whirl. Thanks!