I'm using the inputRichText component for composing HTML-formatted messages in a system I'm working on.
I've encountered a problem, however. It seems the session times out, even when the user is working in the editor.
I tried setting the session timeout parameter in web.xml to 1 minute and started typing in the editor. After 1 minute the "User session expired" dialog box appeared. Is there any way to make the rich text editor component keep the session alive? It's pretty annoying to work on something for a while only to loose it to a session time out, event though you haven't been inactive.
This is the code I use to display the component in the page:
<ice:inputRichText height="250" toolbar="MyToolbar" customConfigPath="/FCKconfig.js" id="messageBody" value="#{bean.messageBody}" language="sv" saveOnSubmit="true" />
Thanks!
Edit:
I solved it using a periodic JavaScript calling into a servlet implementing the stuff outlined in this IceFaces JIRA report
If there's a better way, please let me know :)
I solved it using a periodic JavaScript calling into a servlet implementing the stuff outlined in this IceFaces JIRA report.
It basically allows a servlet to "touch" the session and hence keep it alive.
If there's a better way, please let me know :)
Related
I have a Xpage that takes too long to load. So the client ask me to do a loading indicator.
I searched and found XSP.startAjaxLoading(), that I put in onClientLoad event of the Custom Control.
But now I don't know where should I put XSP.endAjaxLoading() to make the loading screen go away.
I'tried to use in afterRenderResponse and beforeRenderResponse: view.postScript("XSP.endAjaxLoading()"), since this comand is CSJS, but it doesn't work.
Thanks in advance.
I think you want to put it in the onComplete event. That can be difficult to find. You typically need to use the outline control to find it.
I have a video demo on NotesIn9 that has an example on this.
http://www.notesin9.com/2016/02/19/notesin9-188-adding-a-please-wait-to-xpages/?unique=http%3A//www.notesin9.com/2016/02/19/notesin9-188-adding-a-please-wait-to-xpages/
Your attempt (view.postscript) works only with full/partial updates and does not work for page loading.
You have used onClientLoad - which is executed when your page is finished with loading. I guess you get ajax animation after a while and it won't stop.
You should make preload screen - very simple XPage which starts animation and does not care to turn it off. In onClientLoad event redirect to your slow XPage. That will discard the animation.
I'd highly recommend using the Standby Dialog XSnippet https://openntf.org/XSnippets.nsf/snippet.xsp?id=standby-dialog-custom-control. I use it as a standard in all XPages applications.
I used this answer as solution: https://stackoverflow.com/a/35481981/5339322
I've saw it a few days ago, what made me think twice is that using this i should know what is doing my XPages to delay. I ran some tests and discovered what, and it was a call to a method in the afterRestoreView event, then I migrated it to onClientLoad event and used the solution in the answer above cited.
But I'm afraid that I have to keep an eye on it, so if someone adds some code that delays in one of the another events of XPages I have to move it again, of course, if it's possible, if it's not, I'll figure it out something diferent.
Thanks for all the answers ans comments.
I have an xpage with a bunch of controls on it. One of them is a simple label that I'm updating with a partial refresh every five seconds. (I'm implementing a document locking scheme, and the label indicates whether someone has locked the document.) A button on the page fails to execute its event handler if I press it while the partial refresh of the label is occurring. At other times, it works fine. Is this a known issue, or is there perhaps something else going on that may explain this behavior?
(I'm unable to post sample code, unfortunately.)
You need to change your approach. Instead of a partial refresh, have an independent Ajax call to an XAgent for your locking (IMHO 5 sec is way to frequent, the WebDAV standard uses 30sec).
The openNTF WebDAV project has locking code you might be able to repurpose for your needs.
The independent Ajax call frees up the jsf lifecycle to run your other events.
It has been reported from testing that it is occasionally possible to press a button more than once if the response is not rendered fast enough, causing several invocations of the back-end code, which we do not want.
Application is Java EE 6 Web Profile using JSF 2.0 inside Glassfish 3.1.1.
I was wondering how this should be properly dealt with, and have thought of a few scenarios:
Submitting should disable all buttons using javascript while response is being rendered.
A flag in the Session scope saying it is already active, so the sensitive code is skipped and just moves on to the re-rendering of the response for the previous submit.
A synchronized block delaying the processing until the previous request have finished. Then it should be detected that it has been already processed and skipped.
Using one of the "new" scopes like conversion to handle the detection?
My immediate gut feeling is that the best approach is to have sensitive code blocks atomic, but then the problem is with rendering the correct response.
How should I approach this?
Submitting should disable all buttons using javascript while response is being rendered.
This is the easiest to implement in a generic manner. If you happen to use <f:ajax> exclusively, you could use the jsf.ajax.addOnEvent() to perform the job in a generic manner. An alternative JavaScript approach is to create kind of an "Loading" overlay which blocks the UI so that the enduser won't be able to interact with the underlying page anymore. This is basically an absolutely positioned hidden <div> which spans the entire viewport with some opacity (transparency). You could show it on submit and hide it on render. The keyword for this technique is "modal dialog". UI-oriented JSF component libraries have at least such a component already in their assortiment. E.g. PrimeFaces with a <p:dialog modal="true"> inside a <p:ajaxStatus>, or the <p:blockUI>
The only disadvantage is that it won't work if the client has JS disabled or don't use it and it thus won't prevent HTTP clients from double submits.
A flag in the Session scope saying it is already active, so the sensitive code is skipped and just moves on to the re-rendering of the response for the previous submit.
This is more known as "synchronizer token pattern" and has ever been requested for JSF by spec issue 559 which is currently on the ticket targeted for 2.2, but there doesn't seem to be any activity on it. The detection and blocking part is technically easy to implement, but the synchronous response handling part is not easy to implement if you want that the enduser ultimately retrieves the response as generated by the initial request. The asynchronous response handling is easy: just don't specify any components to update, i.e. empty the collection as returned by PartialViewContext#getRenderIds(). After all, this is more robust than using JS to disable the buttons or block the UI.
As far as I know, Seam 2 was the only who offered a reuseable JSF component for this, the <s:token>. I must however admit that this is an interesting idea for a new OmniFaces component. Maybe I will personally take a look at it.
A synchronized block delaying the processing until the previous request have finished. Then it should be detected that it has been already processed and skipped.
This is not easy to implement generically, this would require a change in all action methods to check if the job is already done. It also won't work if the webapp runs on multiple servers. A synchronizer token is easier as it would be performed before the action methods are invoked. A synchronizer token is also less expensive as you don't end up with multiple requests in the queue which would only cost threads/resources.
Using one of the "new" scopes like conversion to handle the detection?
This problem cannot be solved by playing around with managed bean scopes. Managed bean scopes serve a different purpose: the lifetime of the bean instance.
As Adrian mentioned, I would also use BlockUI. There is a BlockUI component from Primefaces. When you submit your forms through ajax, you could also use an overlay during the request. See Primefaces`s Ajax Status for an example.
I'm using JSF1.2, Tomcat 6.0, RichFaces 3.3.3, and Java 6u31.
I do an action in the managed bean, and show a message to the user. That's OK.
After that, I do another action in managed, and then the messages doesn't work anymore until I refresh the page.
I can assure you that the problem isn't in the managed bean, because I just removed all the method impl, leaving it empty, and the bug still happens.
So, the problem is something in the xhtml pages. I tried to put an a4j:status, but it doenst show any error.
So, I see myself without hope. I will not post all the code here, because it's too big and complex.
I wonder if one of you ever seen something like this, or if you have one guess of whats happening. I can edit the question adding any info you want.
I solve this problem.
I has a onupload in the rich:fileupload.
I just remove it, and add a a4j:support, like this:
<a4j:support event="onupload" oncomplete="foo()" />
That's it. I just don't understand why it works that way, and doesnt in the old way.
BTW, thanks.
When i hit a link a window popup is opened.I am having a session managed bean that loads a java.util.List.It is taking few seconds to load that list.
when i click the link twice i am getting concurrent modification exception. because the page is in session mode and first request is still loading the List, before it ends the second request tries to update the list.
I have two possible solution in hand
1) introducing synchronized block
Question : Introducing synchronized block leads to performance issue in multithread environment?
2) javascript to disable the link once it clicked.
problem : Not a good option because we need to restore the state of javascript once the popup is loaded. There is a possibility that the link is disabled forever if the popup window terminated abnormally.
Is there any other solution for this issue?
I'd choose option 1. synchronise on something in the session or on the session bean it's self. In a single server environment this should be pretty safe but in a cluster which isn't using sticky sessions you will have to look for a better singleton.
The performance shouldn't be effected as you will be synchronising for each user session for that particular session bean and if there is no contention the cost isn't worth thinking about.
One alternate solution is make the POPUP window modal window means the parent window will
be blurred/ overshadowed till Pop up is closed.
search for JavaScript code.
Choose 2nd option.
if you are using rich faces you can use a4j library of rich faces and rerender the popup link
<a4j:commandButton id="popupLinkId" onlick="window.open("popupLink");return false;" reRender="popupLinkId" />
Here a4j is the ajax for jsf rich faces library. Refer to http://livedemo.exadel.com/richfaces-demo/richfaces/support.jsf;jsessionid=B9DFBAF3AFD62C96B94EEC67FC4645A5?c=support&tab=usage link for further details.