I have becommen the SocketTimeoutException, which is quite hard to replicate now, but it is not the most important here. What is troubling me is the reaction of the PrimeFaces UI on such happening. The UI got frozen, so no AJAX clicks were processed (one could click what one will but nothing happened).
I don't know the PrimeFaces internals well, but with my experience with AJAX apps, it could happen where we have the AJAX queue and the job is not released after unexpected error happens. Is it the case here?
And how to prevent such behaviour? Or if prevention is not possible, is it possible to "restart" the AJAX engine of PrimeFaces in Javascript? As the last resort I could provide the special button to "reset" the AJAX state without "refreshing" (which should be rather called destroy-all-my-changes) the site?
Related
I have a Durandal App in an asp.net mvc project. It all works great but a few people mentioned the navigation didn't work. I then noticed that they were clicking on the links BEFORE the app was ready and the router was ready.
Does anyone have any suggestions as to how I can prevent the navigation being available until the app is ready?
You can throw up a full-screen scrim (or a block UI, as some people call it) that sits at a very high z-index, covering all content. You can even put a spinner within this scrim at the same z-index.
In the compositionComplete handler of your shell's viewModel, you can then hide the scrim. This proceeds on the assumption that the completion of routing and composition should signal the availability of your app. Bear in mind, though, that if you have AJAX calls (in the form of fetching data, etc.) that could tie up your app, you may need to align hiding the scrim to the completion of those calls instead. That should happen no earlier than compositionComplete.
The last sentence is a bit a tricky. Most of the time, you're fetching data in the activate handler, which is handled earlier than compositionComplete. There's no way to know if the AJAX fetch will complete before or after 'compositionComplete'. In these cases, it might make more sense to move the AJAX fetch to the compositionComplete handler so that you can better coordinate and time the hiding of the scrim to the completion of routing, composition, and fetching.
It hadn't been doing that. Nothing seems to be triggered when the page is loading. What would trigger SSJS validation to run upon opening an xpage?
Your question is too vague to give an exact answer. I recommend watching the XPages Master Class. It will explain the JSF life cycle and show you how to use the XPages toolbox to diagnose your application to get the answer.
Check any partial refresh calls. Use firebug to view network traffic
See if any Ajax calls are being made when page loads. Also check
If you have any converters altering data that might trigger the validation
First of all I'm still learning the structure and how it works.
I searched around the web to get an suitable and easy answer to the following question:
Is there a way to regonize all other basic ajax events, like hovering and clicking on Primefaces Components?
For example, i would know the event which get invoked if you click on the previous or next button on an <p:schedule>. The documentation says there are only "dateSelect, eventMove, eventResize" and "eventSelect" as callable ajax events. But this is not enough, if you want to build an complex application and you combine an <p:calendar> with an <p:schedule>. There you need to know when the schedule switches the month or year.
I hope someone can give me an clear and understandable answer to this.
Thanks and best regards.
Since you did not specify what event you need, your answer is going to be as clear as the question.
The primefaces objects can only recognize the events they are programmed to. If you need to get a specific type of event, you can:
1) see if the primefaces support that event. put it in a <p:ajax tag, and see if it works.
2) see if the standard JSF ajax API support it.
3) If all else fails, you can try to put a jQuery script along with the page, to handle the event and make a call from the client side.
The <p:calendar and <p:schedule makes heavy use of jQuery plugins to render it, I doubt you can get the events on the month selector or anything else in the rendered interface without client-side jquery.
If you go to http://jsbin.com/ibozun/2, hit "Add Item," and then hit "Save," you will see that a second dialog is opened on top of the first one. The form in the dialog is posting to itself (no action defined) - this is by design. Because the dialog has duplicated itself, now you have to hit "Cancel" 2 times to get it to close.
The use-case for this setup is a MS MVC3 page with unobtrusive JQuery validation on it. The default scripts (in other words, I have no custom validators - the scripts are straight from MS) cause an ajax call to the server, and JQM treats that the same as a self-posting form - so you wind up with a duplicate dialog if validation fails.
A similar thing happens if the second page as a page, rather than a dialog - the form posting to itself results in a second history entry in the browser, so to get back to page 1, you have to hit back 2 times.
I believed this be a bug in JQM, but after submitting a bug on GitHub, I was told that this is the expected behavior. So, assuming this behavior that will not be changing in the framework, how do I prevent this from happening for my instance (preferring NOT to edit the framework JS)? Do I have to write my own ajax calls for validation so that I can prevent JQM from knowing that anything has happened? That seems unfortunate...
One idea I had was to detect that the nextPage and current page are the same on "pageHide", and manipulate the dialog/history myself, but have had no luck.
Thanks in advance!
First, there is no dialog duplication in the example. Second, my response and an explanation as to why solving the history issues with posting back to the same page for users of the library is hard can be found here. This example is particularly thorny because it's also in a dialog which we don't support linking to, so disabling ajax for the form (ie forcing it to reload), which would work if it were embedded in a page, won't serve.
The quick solution here is to switch the dialog to a page and add the data-ajax=false data attribute to the form. Mind you this causes a page flash/reload and requires that the form document be fully formed with a head including javascript,css, etc.
I am a beginner using ajax and I always thought that it is completely asynchronous. But I discovered that a call can be interrupted by a page reload or a page change (like clicking on a hyperlink). I was under the impression that when an ajax call is started, it is carried out no matter what the browser does afterwards. Is that wrong?
Now to the specific problem I am having: think of an online test where users answer questions (by typing into textboxes). When a textbox loses focus, an ajax call is triggered which persists the value of the textbox to a DB. That works well when changing between textboxes. However, I also have a submit button which triggeres a post action to another page (it is the submit button). When I enter something into a textbox and click on the button afterwards, the call is not carried out. Moreover, when I type into a textbox, click somewhere else (also triggering the call) and swiftly click on the submit button, the call is also not made. Is that expected behaviour?
The reason I am using ajax in the first place is to persist the values so when something unforseeable happens, like a browser crash, the already typed in text is already saved.
Is my way of thinking wrong? How would you go about solving this problem?
Thank you for your time!
AJAX is asynchronous.
When you send an AJAX request the javascript engine sends it off and sets up a handler for the response.
However, if you send an AJAX request to the server and then navigate away from the page before it is received, nothing will happen. Why? Because with each page load the entire Javascript environment is tore down and reinitialized, it has no idea what happened on the last page.
For your problem I would intercept the form submit action and do whatever you need to do with the data, and then submit the form.
Edit: In response to your comment. You are correct. If the ajax request is sent, and you're not depending on it's return value, then it should not matter.
I'd suggest debugging your problem with Firebug to see if the AJAX call is really being sent properly, and to confirm your server is properly processing it.
Unless you do something special with persistent local storage, all javascript and ajax calls are blown away when a new page is loaded over the current page. Also when a submit is done on a form.
To save things intra-page, save the data asap. Eg, perhaps save on key-up, perhaps periodically with a timer, not just on lose-focus.
Re submitting the page: change the on-click behavior to first store, then to go to a new page.
All of the effects that you are seeing are normal.
Also, be sure to test on both slow (ie 6 or 7) and fast browsers (chrome)