I have developed a jsom page where once we submit data it get save to an custom list(10 columns). When submitting minimum 50 items and can have maximum of 150 items will be save to the list. the problem is that I'm getting Page unresponsive alert and page freezes till the process gets completed.
Please suggest how to avoid this un-responsive issue in the browsers
You can get better answers if you post your code as well.
But it sounds like you are using "ExecuteQuery()" which waits for Sharepoint to respond.
You should use "ExecuteQueryAsync()" which uses asynchronous call in which code continues to execute and does not wait for SharePoint’s response.
Related
I need to scroll blog-posts/latest news infinitely on a browser.
The way it should work is I get first 20 posts from server in a list. I render first one on browser. After I am close to x height from end of browser - that should load next post from list. While loading next post I need to make a call to analytics, advertisements and also change browser url with new title. Once I reach 20th post, I need to make a call to server to get next 20 posts and this continues.
My question is: what libraries are available to me to make a POC on this?
How do I compare them and which one to choose?
I need to make this project in nodejs and I am new to nodejs. Any available demos might help too
Since you are interested in crunching latest data so this can be achieved by server side pagination, say you'll have to query latest blog-post limited to 20 and also will have to keep track of page-cursor (means from where next query will fetch next 20 blog-posts). You are building in Nodejs so I assume your database to be Mongodb (Assuming MEAN Stack), you can write your own pagination logic but why to re-invent wheel? solutions are available to be used such as mongoose-paginate. This completes back-end part.
On front-end there are various plug-ins available for various frameworks such as:
1 - Don't want to use any plugin:
$(window).scroll(function () {
if ($(window).scrollTop() >= $(document).height() - $(window).height() - 10) {
//Add newly-crunched data at the end of the page
}
});
2 - In Angular use angular-ui pagination or ngInfiniteScroll
3 - In jQuery use infinite-scroll or jScroll
Here is tuts+ How to Create Infinite Scroll Pagination
Happy Helping!
Just for reference before mentioning the problem I would like to say that I have asked to same question on IBM Lotus forum(http://www-10.lotus.com/ldd/ndseforum.nsf/xpTopicThread.xsp?documentId=2AD7C8F89D8930E685257BD50022A9E9) and I have not received any reply for the same in last 2 weeks.
So, I have a typical xpage dropdown menu with say around 40-50 leaf nodes, Every leaf node submits a specific value (using submitValue property) which is then evaluated and action is performed. However, the problem is that, after the action is performed if I try to refresh the page i get the browser notification for re-submission (I believe that it is some kind of programming error by me, however I don't know how to resolve it.)
One example to make it more clear:
I have a delete node inside the dropdown. It basically deletes the selected entries from the view(generated using repeat control) and then refreshes the view content. But at this point of time if I try to refresh the page then I get the notification of re-submission by the browser. If I accept it, then it tries to delete it again (which I prevent it but still this shouldn't happen) and if I don't accept it, it just doesn't refresh the page.
Any reply would be appreciated.
Thank you in advance. Hoping to hear some suggestions. (Please let me know if event he code is required)
I believe you need to implement the Post/Redirect/Get pattern to avoid re-posting on refresh.
Here's a solution by Tommy Valand for XPages for that pattern: http://dontpanic82.blogspot.dk/2010/06/xpages-avoid-saving-duplicate-documents.html
i have build a tabbed application with XPages.
My problem is, when i open to fast to much tabs, every serverside script stop working.
I get still a partial refresh but he did not execute any serverside script. After a full refresh every think works again. I can reproduce this an every server.
Any ideas how to solve this problem?
UPDATE (more details)
I work with iframes and in every tab i create a complex view (with a repeater)
I've i open the tabs not to fast everything works just perfect, but if i open the tabs to fast nothing will work, it affects to every script.
I got no clientside script error and i got also no serverside scipt error.
Some of these scripts are simple like document.replaceItemValue("fieldname", "value");
I've set just a print statement in the function but it also won't execute.
It seems that the server deletes the xpages session if he comes in memory trouble
You need to check carefully. It sounds less than a "heavy" usage and more like a concurrency problem. Be aware that any variable you define in a script library is application scoped. If multiple calls update the same value you might experience such a behavior. The scope variables are there to keep values.
The solution for the problem is, i have to increase the number for the xsp.persistence.file.maxviews property
I've started to develop a Chrome extension to navigate and perform actions on a website. Until now the extension is able to receive a couple of parameters and check a set of radio-buttons, fill in a few inputs of a form and then submit it.
What I want to do now is to repeat the process, but I'm stuck when the page is reloaded. And I don't know how can I do to make the script react to the finish of the request.
The workflow I want to achieve is the following (is for automatically copying a certain object):
Popup side
Enter the number of the Master object to copy
Enter the base name of the copies (example Mod, so the I can iterate and add mod1, mod2, modn)
Enter the number of copies
Background side
Select master
Select standard options
Fill in inputs
Submit form
Wait for the page to complete the request and continue to the next copy. (here I need help)
The problem is on the repetition, the rest is taking care of. I assume that must be a way of dealing with requests. Any ideas?
By the way I'm doing it all with the extension and tabs methods of Google Chrome plus JavaScript and jQuery.
Ok, i´m going to answer the question myself based on Matthew Getner´s comment. The chrome.webRequest.onCompleted was the solution to the problem. With this method I was able to wait for the request to be completed and start over with the process. And with the messegaes methods I´ve achieved the comunication between the background and the extension itself. So I finally was able to filled a form, send it, and repeat. This way I´ve made a kind of robot to help a co-worker with a lame repetitive task on a aged web plataform.
One of our most common error situations in a web application is that a user executes a GET request where the form should have submitted a POST.
I realize that the most likely case is that they got to the page (by way of a POST) and then clicked in the address bar and hit enter.
The question is, are there other less obvious ways that this could happen (print previews/back button, etc)?
We have never been able to consistently repeat the problems. The problems for different users and different pages nor do they happen very often (maybe once a week).
EDIT:
There is no data submitted with the GET request and therefore the processing page crashes out.
I was having a similar issue, although it doesn't sound like this was exactly yours. I had a form that was being submitted via ajax and shouldn't ever use the default submit. Now and then I was receiving errors from a GET done on the form. It shouldn't be possible to submit this form; however, certain versions of Safari for Mac were submitting it on enter. I just added a jquery form.submit() catch on it to prevent the default functionality. I also set the action to a page that wouldn't result in error (in case of lack of javascript).
As you said your problem is intermittent, so having a problem in form method set as get instead of post can be overruled but yes you are right, that if user presses enter in address bar it would be a get request and back button request always depends upon the last request made, if it was a post then any good browser will prompt you about resubmission and if it was get then no prompt, page will be bought back(may be from cache).
May be you can use Firebug (track requests in .net tab)or Fiddler and do some tests with different users/pages if you can reproduce it, its simply pressing enter in address bar.
Edit:
And also get is always supposed to 'retrieve information' so if browser is missing something or need something it will be a get but again check in IIS log for those get requests and try them in browser,if they contains query string for viewstate and eventvalidation, then they are really mis-formed request from post to get, if form method is not explicitly set to get.
I believe that an answer to the question "what are reasons for a browser executing GET rather than POST" does not help to solve the problem of receiving a GET on a form where you expect the a GET. But: To answer that question I would simply say that you receive an GET because the browser sends an GET and you can send a GET on any page where you can send a POST. On the other hand, if the user uses the form the browser sends a POST. Thus your server has to be prepared to handle the GET and it should handle the GET in the same manner as a POST with invalid parameters. My suggestion:
If you receive a GET, display the form again.
If you receive a POST with invalid data, display the form again and notify the user that he has to enter the data in a specific way.
Maybe a trivial answer, but that's what I would do. Don't know if it adds to the discussion.
Wrong, the most obvious reason why you get a GET instead of a POST is that because you're doing a GET instead of a POST.
A less obvious reason is you forgot to specify method="post" in one of your forms. The HTML standard specifies that the default method is GET, so if you want to POST, you must specify method="post" explicitly.
Scrutinize all of your tags and make sure all of them explicitly specify method="post".
EDIT: When you click on the address bar and pressed enter, yes it's true that the browser will GET a page, but your form wouldn't be submitted that way since the browser treats the URL similar to how a copy-pasted URL would be: a new session without any additional information sent to the server (except cookies).