Re: Browser Back Button
The complexity of using t:saveState will probably depend on your application. I've got an application with more than 100 pages, but most of the uses of those pages are self-contained.The t:saveState needs are either self-contained in a specific page or only span a small number of pages. On 8/9/07, simon [EMAIL PROTECTED] wrote: On Wed, 2007-08-08 at 23:53 +0100, Francisco Passos wrote: Simple jsf apps can be written without session-scoped beans, but it takes some effort to avoid them in larger apps. The t:saveState tag doesn't really scale ;-) It's a shame to hear that... :( I guess this means back to the drawing board. What kind of a scale are we talking about that makes t:saveState not work as efficiently as one would like? And what is the main impact? Bandwidth? Server processing due to constant serialization / desserialization of beans being kept from previous requests? These are things important to take in consideration when deciding what to go for at application design time, because after you commit either to session or saveState, it gets hard to go back pretty quick. I didn't mean that there was a performance problem with t:saveState; there isn't one AFAIK. Although as an app gets more complex, the set of backing beans relevant to a page probably increases, and that will of course increase the amount of data that needs to be serialized and held by the t:saveState component. I guess that there is little impact when using server-side JSF state as that data needs to be held in either the session or the tree one way or another (though the JSF tree always gets serialized while the http session only gets serialized when memory is short). However if client-side state is being used then obviously that would increase bandwidth. However when an app gets up to 50 or 100 pages I expect that managing state by adding t:saveState tags all over the place will become hard to maintain. Some kind of conversation scope should be much easier to work with. Regards, Simon
Re: Browser Back Button
On Wed, 2007-08-08 at 23:53 +0100, Francisco Passos wrote: Simple jsf apps can be written without session-scoped beans, but it takes some effort to avoid them in larger apps. The t:saveState tag doesn't really scale ;-) It's a shame to hear that... :( I guess this means back to the drawing board. What kind of a scale are we talking about that makes t:saveState not work as efficiently as one would like? And what is the main impact? Bandwidth? Server processing due to constant serialization / desserialization of beans being kept from previous requests? These are things important to take in consideration when deciding what to go for at application design time, because after you commit either to session or saveState, it gets hard to go back pretty quick. I didn't mean that there was a performance problem with t:saveState; there isn't one AFAIK. Although as an app gets more complex, the set of backing beans relevant to a page probably increases, and that will of course increase the amount of data that needs to be serialized and held by the t:saveState component. I guess that there is little impact when using server-side JSF state as that data needs to be held in either the session or the tree one way or another (though the JSF tree always gets serialized while the http session only gets serialized when memory is short). However if client-side state is being used then obviously that would increase bandwidth. However when an app gets up to 50 or 100 pages I expect that managing state by adding t:saveState tags all over the place will become hard to maintain. Some kind of conversation scope should be much easier to work with. Regards, Simon
Re: Browser Back Button
Simple jsf apps can be written without session-scoped beans, but it takes some effort to avoid them in larger apps. The t:saveState tag doesn't really scale ;-) It's a shame to hear that... :( I guess this means back to the drawing board. What kind of a scale are we talking about that makes t:saveState not work as efficiently as one would like? And what is the main impact? Bandwidth? Server processing due to constant serialization / desserialization of beans being kept from previous requests? These are things important to take in consideration when deciding what to go for at application design time, because after you commit either to session or saveState, it gets hard to go back pretty quick. On 8/7/07, simon [EMAIL PROTECTED] wrote: The server-side support for back buttons in MyFaces only ensures that the data held by JSF components doesn't get confused by back-buttons. Of course this issue is irrelevant when using client-side state-saving. However in either case, if there are any session-scoped backing beans being used by the app then they get out-of-sync with the GUI when back buttons are pressed, regardless. Simple jsf apps can be written without session-scoped beans, but it takes some effort to avoid them in larger apps. The t:saveState tag doesn't really scale ;-) Regards, Simon On Tue, 2007-08-07 at 16:45 -0400, Mike Kienenberger wrote: I'm not entirely certain, but setting this parameter to 1 might solve the problem for you if you use server-side state-saving. However, I use client-side state-saving so I can't say for sure. context-param param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION /param-name param-value1/param-value descriptionOnly applicable if state saving method is server (= default). Defines the amount (default = 20) of the latest views are stored in session. /description /context-param On 8/6/07, Escalada Sergio [EMAIL PROTECTED] wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english.
Re: Browser Back Button
Escalada Sergio wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english. I'm using this solution and it works fine for me: tr:document onload=window.history.forward(1) -- Luka Šurija [EMAIL PROTECTED] +385 98 434 061 I.Y. tim d.o.o. www.iytim.hr [EMAIL PROTECTED]
Re: Browser Back Button
Hi Sergio, we use on every JSF page the following javascript code: script history.forward(); /script When the user pushes back button he is automatically forwarded again. Just a workaround though. Regards Rene On Mon, 06 Aug 2007 15:15:31 +0100 Escalada Sergio [EMAIL PROTECTED] wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english.
Re: Browser Back Button
Is this working on all browsers? 2007/8/7, Rene Guenther [EMAIL PROTECTED]: Hi Sergio, we use on every JSF page the following javascript code: script history.forward(); /script When the user pushes back button he is automatically forwarded again. Just a workaround though. Regards Rene On Mon, 06 Aug 2007 15:15:31 +0100 Escalada Sergio [EMAIL PROTECTED] wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english.
Re: Browser Back Button
Both plain script a onload fail to prevent history navigation in firefox. 2.0.0.4. The user have to manually 'reload' the previous page to activate the foward script. Once he has reloaded, it always prevent navigation. Untilm user disable javascript and goes back to that page. At that point, he can go back and forth as much as he want, reactivate javascript. It will again not work until user click the reload button. So, i won't build my application assuming user won't be able to use the back button. Not to mention users usually don't like to be forbidden the easy to use back button. En l'instant précis du 07/08/07 08:35, Rene Guenther s'exprimait en ces termes: Hi Sergio, we use on every JSF page the following javascript code: script history.forward(); /script When the user pushes back button he is automatically forwarded again. Just a workaround though. Regards Rene On Mon, 06 Aug 2007 15:15:31 +0100 Escalada Sergio [EMAIL PROTECTED] wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english. -- http://www.noooxml.org/
Re: Browser Back Button
One last suggestion do all your sbmit using a JSF based AJAX framework (like ajax4JSF). That way there is no navigation. The bad part are 1) that there is no change in url bar as user navigate 2) You can't use redirect/ in your JSF navigation 3) You can't submit files (no way to send a file using XmlHttpRequest for security reasons) En l'instant précis du 07/08/07 11:18, simon s'exprimait en ces termes: On Mon, 2007-08-06 at 15:15 +0100, Escalada Sergio wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english. There's no easy solution to this one AFAIK. A website (ie html, javascript, etc) is forbidden from modifying browser menus, etc for security reasons. The chaos that an evil website could create if this was permitted would be huge. The options are: (1) when a user clicks back, your webapp does the right thing. This is surprisingly difficult to achieve, however. For a start you should avoid all session-scoped beans. (2) when a user clicks back, you show a page saying don't do that. (3) launch your webapp in a popup window. The popup window can be created without a menubar. Note that a user can still use shortcut keys to trigger back, but that takes far more effort. (4) use an active-x control (for IE) or similar for firefox etc. to disable the back button. I don't know if this is actually feasable, and the user will certainly have to authorise the control to run. It's also browser-specific, ie you'll need to implement the equivalent for every browser type you support. The auto-forward solution proposed elsewhere in this thread is interesting. I suspect it has interesting side-effects though. You'll need to think through carefully whether this will work for your site. I don't know of any other solution. The problem is the fundamental web concept that a browser should never trust a website - and allowing a website to disable core browser functionality (back button in this case) certainly takes trust. I've always used option (3) in the end. It's not terribly pretty but it works. Regards, Simon -- http://www.noooxml.org/
Re: Browser Back Button
Sergio, Take a look at the Spring WebFlow project. One of the features of it is: Receive automatic browser button support (back, forward, refresh) with no custom coding. -Richard Escalada Sergio wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english.
Re: Browser Back Button
Ok, now that Spring has been mentioned, I'll finally mention Seam, too. Note that you'll never get fully automatic support of back button and refresh with any framework. However Seam makes it a lot easier to provide meaningful results: http://docs.jboss.com/seam/1.2.1.GA/reference/en/html/jbpm.html#d0e4952 --Stephen Sergio, Take a look at the Spring WebFlow project. One of the features of it is: Receive automatic browser button support (back, forward, refresh) with no custom coding. -Richard Escalada Sergio wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english.
Re: Browser Back Button
The disabling of JavaScript is no problem for our intranet application, since our application requires JavaScript. Maybe someone will argue now that applications should not require javascript, but as long as the clients are happy with the application, we are happy :-) But you are right with the script not working anymore in 2.0.4. I just tested it, the strange thing is, sometimes it works. I dont know why though. If disabling of back button functionallity is not possible, probably the best thing is to avoid session scoped beans as mentioned before. Rene On Tue, 07 Aug 2007 11:37:36 +0200 David Delbecq [EMAIL PROTECTED] wrote: Both plain script a onload fail to prevent history navigation in firefox. 2.0.0.4. The user have to manually 'reload' the previous page to activate the foward script. Once he has reloaded, it always prevent navigation. Untilm user disable javascript and goes back to that page. At that point, he can go back and forth as much as he want, reactivate javascript. It will again not work until user click the reload button. So, i won't build my application assuming user won't be able to use the back button. Not to mention users usually don't like to be forbidden the easy to use back button. En l'instant précis du 07/08/07 08:35, Rene Guenther s'exprimait en ces termes: Hi Sergio, we use on every JSF page the following javascript code: script history.forward(); /script When the user pushes back button he is automatically forwarded again. Just a workaround though. Regards Rene On Mon, 06 Aug 2007 15:15:31 +0100 Escalada Sergio [EMAIL PROTECTED] wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english. -- http://www.noooxml.org/
Re: Browser Back Button
It works for Mozilla Firefox and Internet Explorer. Not 100% sure about this: By using the back button the browser wont send a new request to the server. So what could happen? Rene On Tue, 7 Aug 2007 10:56:34 +0200 Michał 'Gandalf' Stawicki [EMAIL PROTECTED] wrote: But this won't prevent any actions that might happen because of rendering previous page. It just makes sure that after rendering previous page the next page will be redisplayed. On 07/08/07, Adrian Mitev [EMAIL PROTECTED] wrote: Is this working on all browsers? 2007/8/7, Rene Guenther [EMAIL PROTECTED]: Hi Sergio, we use on every JSF page the following javascript code: script history.forward(); /script When the user pushes back button he is automatically forwarded again. Just a workaround though. Regards Rene On Mon, 06 Aug 2007 15:15:31 +0100 Escalada Sergio [EMAIL PROTECTED] wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english. -- Michał Stawicki [EMAIL PROTECTED] http://stawicki.jasliska.pl
Re: Browser Back Button
But avoiding session scoped beans makes much harder to develop an application, and application will be slower then using session scoped beans (especially in combination with EJB3 session beans). Rene Guenther wrote: The disabling of JavaScript is no problem for our intranet application, since our application requires JavaScript. Maybe someone will argue now that applications should not require javascript, but as long as the clients are happy with the application, we are happy :-) But you are right with the script not working anymore in 2.0.4. I just tested it, the strange thing is, sometimes it works. I dont know why though. If disabling of back button functionallity is not possible, probably the best thing is to avoid session scoped beans as mentioned before. Rene On Tue, 07 Aug 2007 11:37:36 +0200 David Delbecq [EMAIL PROTECTED] wrote: Both plain script a onload fail to prevent history navigation in firefox. 2.0.0.4. The user have to manually 'reload' the previous page to activate the foward script. Once he has reloaded, it always prevent navigation. Untilm user disable javascript and goes back to that page. At that point, he can go back and forth as much as he want, reactivate javascript. It will again not work until user click the reload button. So, i won't build my application assuming user won't be able to use the back button. Not to mention users usually don't like to be forbidden the easy to use back button. En l'instant précis du 07/08/07 08:35, Rene Guenther s'exprimait en ces termes: Hi Sergio, we use on every JSF page the following javascript code: script history.forward(); /script When the user pushes back button he is automatically forwarded again. Just a workaround though. Regards Rene On Mon, 06 Aug 2007 15:15:31 +0100 Escalada Sergio [EMAIL PROTECTED] wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english. -- http://www.noooxml.org/
Re: Browser Back Button
I'm not entirely certain, but setting this parameter to 1 might solve the problem for you if you use server-side state-saving. However, I use client-side state-saving so I can't say for sure. context-param param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION/param-name param-value1/param-value descriptionOnly applicable if state saving method is server (= default). Defines the amount (default = 20) of the latest views are stored in session. /description /context-param On 8/6/07, Escalada Sergio [EMAIL PROTECTED] wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english.
Re: Browser Back Button
The server-side support for back buttons in MyFaces only ensures that the data held by JSF components doesn't get confused by back-buttons. Of course this issue is irrelevant when using client-side state-saving. However in either case, if there are any session-scoped backing beans being used by the app then they get out-of-sync with the GUI when back buttons are pressed, regardless. Simple jsf apps can be written without session-scoped beans, but it takes some effort to avoid them in larger apps. The t:saveState tag doesn't really scale ;-) Regards, Simon On Tue, 2007-08-07 at 16:45 -0400, Mike Kienenberger wrote: I'm not entirely certain, but setting this parameter to 1 might solve the problem for you if you use server-side state-saving. However, I use client-side state-saving so I can't say for sure. context-param param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION/param-name param-value1/param-value descriptionOnly applicable if state saving method is server (= default). Defines the amount (default = 20) of the latest views are stored in session. /description /context-param On 8/6/07, Escalada Sergio [EMAIL PROTECTED] wrote: Hello. I am using MyFaces 1.1.5, Tomahawk 1.1.6 in my WEB Aplication, and i have a requirement mandatory to disable the browser back button while the user is interacting with the aplication. The requirement is really serious and compromise the usability of the aplication, can anyone tell me if it is possible to do anything to avoid the use of the browser back button?, or at least to control the use of it trying to avoid the consecuences it carry. Thanks in advance, sorry for my english.
Re: Browser Back Button
Where does ID get set? According to your code, your avalue is getting
the value from the MyBean's ID property. Without knowing how that ID
is getting its value from, it is impossible to say what is going on.
Only the component tree is serialized into the state. The session
managed beans live on the server in the HttpSession and are never part
of the component tree (unless you use something like t:saveState).
Therefore, you have to realize that when the user clicks back, your
session state bean is still at the same state as it was, only when
they submit the form is the bean updated.
So for example:
public class MyBean
{
private int count = 0;
public void hit(ActionEvent evt) { count++; }
public int getCount() { return count; }
}
Navigation: page A goes to page B which goes to Page C
Pages A-C all look the same:
t:commandLink
value=next
actionListener=#{myBean.hit}
action=next /
t:outputText value=#{myBean.count} /
Use case: user clicks on next 2 times (A-B-C). Then user clicks back
2x (A). Then user clicks next again.
Here is the output of the output text in:
A - 0
B - 1
C - 2
(back)
(back)
A - 0
B - 3
I didn't test it, the only differnece is that the 2nd A may show 2
instead (depends on how the component and browser caching loads the
page. If the page expires, I think 2 will show, if the browser brings
back the cached page, 0 will show).
The point is that B should be 3 though, not 1. This is because the
bean is the same across all pages, it is divorced from the component
tree.
Hope that helps (please someone correct me if I am wrong)
-Andrew
On 8/2/06, Michael Heinen [EMAIL PROTECTED] wrote:
Yes, I forgot to mention.
MyBean has session scope.
The updateActionListener calls just a simple setter:
public void setAvalue(String bla) {
this.avalue = bla;
}
The action (simplified, I just don't want to post not relevant
information)
public String doIt() {
String mystring = this.getAvalue(); //just simple getter
...
}
The problem is that getAvalue returns 1 instead of 2 after clicking back
button.
getId() and setId() are also simple getters and setters without any
additional logic.
Michael
-Original Message-
From: Andrew Robinson [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 2. August 2006 17:20
To: MyFaces Discussion
Subject: Re: Browser Back Button
What is the code in the Java? What scope is MyBean?
On 8/2/06, Michael Heinen [EMAIL PROTECTED] wrote:
I have sometimes a problem with the Browser Back button.
My app runs with server side state saving and
NUMBER_OF_VIEWS_IN_SESSION is
set to 20.
I use an immediate command link with an updateActionListener that
updates an
iframe.
h:commandLink action=#{MyBean.doIt} immediate=true
target=iframe1
t:updateActionListener property=#{MyBean.avalue}
value=#{MyBean.id/
/h:commandLink
ClickFlow:
Start Page1: MyBean.avalue=1
Navigate toPage2: MyBean.avalue=2
Click doIt on Page2: MyBean.avalue=2
Click BackButton -- goes one page back in the iframe
Click BackButton -- Page1 is redisplayed (so far so good)
Click doIt on page1: MyBean.avalue=2
But MyBean.avalue should be 1 in this case!!!
I thought that the BackButton is supported with server side state
saving and
NUMBER_OF_VIEWS_IN_SESSION.
What can I do in this szenario?
Is this always working this way or is this caused by the immediate
command
link?
I cannot change to client side state saving!
I tried also to replace the iframe with an ajax update but the back
button
effect is the same.
Any help is appreciated
Michael
Re: browser back button in JSF?
No - client-side state saving IS significant slower. And it works with server-side state saving as well, at least with the nightly builds. regards, Martin On 2/6/06, Yee CN [EMAIL PROTECTED] wrote: There was a benchmark posted around a month ago - the finding was that state saving in client runs a lot slower than state saving in server. Is there any update this? Regards, Yee -Original Message- From: Dennis Byrne [mailto:[EMAIL PROTECTED] Sent: Monday, 6 February 2006 12:12 PM To: MyFaces Discussion Subject: Re: browser back button in JSF? Try changing state saving to 'client'. context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value /context-param ... or start using a nightly build, as MyFaces has fixed this. Dennis Byrne -Original Message- From: Tom Butler [mailto:[EMAIL PROTECTED] Sent: Sunday, February 5, 2006 11:06 PM To: users@myfaces.apache.org Subject: browser back button in JSF? Can anyone point me to a wiki or other to help me understand how to handle the user pressing the browser back button in a JSF application? I've read this is a weakness of JSF, and from the testing I've done it does appear to be a problem. Looking for any ways to gracefully handle this situation. Thanks! -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: browser back button in JSF?
Try changing state saving to 'client'. context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value /context-param ... or start using a nightly build, as MyFaces has fixed this. Dennis Byrne -Original Message- From: Tom Butler [mailto:[EMAIL PROTECTED] Sent: Sunday, February 5, 2006 11:06 PM To: users@myfaces.apache.org Subject: browser back button in JSF? Can anyone point me to a wiki or other to help me understand how to handle the user pressing the browser back button in a JSF application? I've read this is a weakness of JSF, and from the testing I've done it does appear to be a problem. Looking for any ways to gracefully handle this situation. Thanks!
RE: browser back button in JSF?
Thanks Dennis - I'll give this a try tomorrow.. caffeine has run out..zzz -Original Message- From: Dennis Byrne [mailto:[EMAIL PROTECTED] Sent: Sunday, February 05, 2006 11:12 PM To: MyFaces Discussion Subject: Re: browser back button in JSF? Try changing state saving to 'client'. context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value /context-param ... or start using a nightly build, as MyFaces has fixed this. Dennis Byrne -Original Message- From: Tom Butler [mailto:[EMAIL PROTECTED] Sent: Sunday, February 5, 2006 11:06 PM To: users@myfaces.apache.org Subject: browser back button in JSF? Can anyone point me to a wiki or other to help me understand how to handle the user pressing the browser back button in a JSF application? I've read this is a weakness of JSF, and from the testing I've done it does appear to be a problem. Looking for any ways to gracefully handle this situation. Thanks!
RE: browser back button in JSF?
There have been many posts on this at http://www.mail-archive.com/users%40myfaces.apache.org/ Iset the STATE_SAVING_METHOD to client and it fixed the problems context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value /context-param Balaji [Balaji Kalyansundaram]-Original Message-From: Tom Butler [mailto:[EMAIL PROTECTED]Sent: Monday, 6 February 2006 2:06 PMTo: users@myfaces.apache.orgSubject: browser back button in JSF? Can anyone point me to a wiki or other to help me understand how to handle the user pressing the browser back button in a JSF application? Ive read this is a weakness of JSF, and from the testing Ive done it does appear to be a problem. Looking for any ways to gracefully handle this situation. Thanks! This correspondence is for the named persons only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis transmission. If you receive this correspondence in error please delete it from your system immediately and notify the sender. You must not disclose, copy or relay on any part of this correspondence, if you are not the intended recipient. Any opinions expressed in this message are those of the individual sender except where the sender expressly, and with the authority, states them to be the opinions of the Department of Emergency Services, Queensland.
RE: browser back button in JSF?
There was a benchmark posted around a month ago - the finding was that state saving in client runs a lot slower than state saving in server. Is there any update this? Regards, Yee -Original Message- From: Dennis Byrne [mailto:[EMAIL PROTECTED] Sent: Monday, 6 February 2006 12:12 PM To: MyFaces Discussion Subject: Re: browser back button in JSF? Try changing state saving to 'client'. context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value /context-param ... or start using a nightly build, as MyFaces has fixed this. Dennis Byrne -Original Message- From: Tom Butler [mailto:[EMAIL PROTECTED] Sent: Sunday, February 5, 2006 11:06 PM To: users@myfaces.apache.org Subject: browser back button in JSF? Can anyone point me to a wiki or other to help me understand how to handle the user pressing the browser back button in a JSF application? I've read this is a weakness of JSF, and from the testing I've done it does appear to be a problem. Looking for any ways to gracefully handle this situation. Thanks!
Re: Browser 'Back' button problem in myfaces
Hi, I've read somewhere that you need to save the state of components in the client, not the server. try this on your web.xml: context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value description State saving method: client or server (= default) See JSF Specification 2.5.2 /description /context-param Gérard On Tuesday 12 July 2005 04:31, Gary Lin wrote: Hi there, In myfaces, when click 'back' button in browser(likes IE, firefox), it will go back to last page without problem, but when you try to click another link, it's not working at the first time. (instead of switch to that link, it will just refresh at the same page) It will only work when you click again at the second time. I remember someone discussed this before, but I cannot find it somehow. Any solution for this? Thanks. Gary
Re: Browser 'Back' button problem in myfaces
Yes, it works. Thanks Gérard. Gary On 7/12/05, Gérard COLLIN [EMAIL PROTECTED] wrote: Hi, I've read somewhere that you need to save the state of components in theclient, not the server.try this on your web.xml:context-paramparam-namejavax.faces.STATE_SAVING_METHOD /param-nameparam-valueclient/param-valuedescriptionState saving method: client or server (= default)See JSF Specification 2.5.2/description/context-param GérardOn Tuesday 12 July 2005 04:31, Gary Lin wrote: Hi there, In myfaces, when click 'back' button in browser(likes IE, firefox), it will go back to last page without problem, but when you try to click another link, it's not working at the first time. (instead of switch to that link, it will just refresh at the same page) It will only work when you click again at the second time. I remember someone discussed this before, but I cannot find it somehow. Any solution for this? Thanks. Gary
