My web application MVC View displays a grid of records, some of which the user can select and post their data back to the server. As long as the record count is in the order of multiples of dozens, the page is responsive. Problems occur when the records are in the order of a thousand and a half.
I've experienced two kinds of problems, one in chrome, one in IE 11. First of all the query to retrieve the records from the DB is kind of slow, but acceptable, let's say that after 5=10 seconds the controller will call a "return view()" passing a model which is a collection of about 1500 records.
Then this happens in Chrome: the browser renders the page quick enough considered the number of record, but after that the page becomes unresponsive in all its elements: as an example, consider the to activate a checkbox, it takes about 10 seconds before you see the check mark after you clicked.
In IE11 this happens instead: the page hangs for about three minutes between the jquery method "document.ready" and its anonymous handler function. After that the page renders all its elements and its responsiveness is acceptable.
My Application is developed in MVC2, and besides jquery, it uses datatables to display the grid, together with bootstrap for styling. Every record has about 20 fields so the page will have 20 form controls (input type=hidden) to post back for each selected record.
Considering that nothing of the above happens when I'm retrieving a few records, can you help me understand what's going on and how I can give performance to my web page?
Thanks in advance......
Related
I have a table with 100 rows which is displayed 20 rows at a time on a webpage. I can view the next 20 rows by clicking "next page" which updated the table view on my webpage. I can access the data for each batch of 20 rows via the developer/inspect browser tools. Is there anyway to get this for all 100 rows at once? The webpage is only accessible after logging in, i.e. the data is not publicly available.
It depends what the page is doing.
If the 100 rows aren't loaded on the browser at once then no you can't get them. For example the page may be calling a web service to load 20 at a time.
You would have to understand how the page acquires the rows and then replicate that with some javascript in order to pull back more at once.
You may also be able to use the console/debugging tools to edit the code on the page to make it load more at once. Really it's very dependent on the specifics of what the page is doing.
Recently I've come across the problem in Oracle Apex 4.2.0003 with saving pagination in Interactive Report. I have a page, in which there are two reports: the first one is Classic, and the second one is Interactive, at that they are working as "master-detail".
Besides, Interactive report has both data from a view and HTML-elements like icons with links to modal or pop-up windows. All in the page works fine except one thing: refreshing of it leads to resetting the pagination of "detail" Interactive report in spite of full refresh or partial (without resetting the Classic, "master" one).
I've tried to solve the problem with javascript: I've written some code, which got current pagination from page and saved it just before updating, and the updating itself went by means of function gReport.navigate.paginate. I could use this way, but it didn't take into account the cases when there were less rows than the count of them chosen in the Interactive Report panel (where also there are search bar etc.).
Another way of solving my problem I'm considering now is getting information about current row count per page from the view APEX_APPLICATION_PAGE_IR_RPT, but I don't know how to get not information from the column interactive_report_id, but from the one named report_id.
Of course, I have the way which leads through getting information by having session ID and the kind of view (which can be customized in Interactive Report panel), but I can't say I like it.
So I have the following question: how to make Interactive Report NOT to reset pagination in my case? Is it possible to make it easier than to get the information from APEX views?
This is a question which pops up from time to time and this is still an issue in apex 5, being that there is no supported way to do this, even though all it requires is opening up the api a bit so we wouldn't need to hack it.
You can use gReport.navigate.paginate for sure, and I'd recommend to go with that. Mind though: it's unsupported by Oracle (as in: undocumented) and it does not work in apex 5 (the JS for IRs has been redone). However, even in apex 5 the methodology remains similar: just "hack" it.
I would NOT query views. You still need IDs from the report and communicate with the backend, and you'll create many more problems than you actually need.
Just figure out in javascript when there is pagination or not.
HTML in the IR when there are more rows than the allowed rows per page:
<td colspan="18" class="pagination" align="left">
<span class="fielddata"> 1 - 15 of 1878
<a href="javascript:gReport.navigate.paginate('pgR_min_row=16max_rows=15rows_fetched=15')">
<img src="/i/jtfunexe.gif" title="Next" alt="Next" align="absmiddle">
</a>
</span>
</td>
HTML when there are less or equal rows than amount allowed:
<td colspan="18" class="pagination" align="left"><span class="fielddata"> 1 - 1 of 1 </span></td>
So: you can check if there is an anchortag in there or not.
If yes: perform your 'paginate' function.
If not: do a refresh.
I have developed an ASP.Net application which users use to enter their time sheets. The application is using a grid to display the days as columns and the entries as rows. Whenever the user enters values to the cells, signifying the hours spent for a particular project on a particular day, I have a JavaScript function which updates the column totals for the day. When the user focuses another row, the row total is also updated.
A strange behavior is exhibited when the number of rows of the grid exceeds 50 or so rows: when a new row is added, after the user populates the first cell, it takes up to 40 seconds for the total of the column to be updated, during which time the browser is waiting for the operation to finish. After control is returned to the browser, populating subsequent cells in the same row update the totals instantaneously. When a new row is added, the same behavior is exhibited.
Could someone please point me to where I should start troubleshooting this issue? Is this browser related (we are using IE 8), or should I look into the JavaScript code? I tried running this application using. Running the application using FF somewhow does not work, so I cannot test it that way.
Any ideas?
The problem (for anyone who's interested) was with the getRow() method of Ig2010.3. I re-wired the logic of the page and it's now reading the content of the cell otherwise. It's ok now.
I have a web application that retrieves and displays records from a database. A user's query could possibly match thousands of records; in such cases, it makes sense for the user to refine his search.
In the case that the query matches hundreds of records, it probably makes sense for the user to browse the records. The thing that bothers me is that the web application displays "pages" of records. In the context of a web application, I believe that paging is a horrible, horrible, way to display this kind of data.
Imagine the following scenario:
User runs a query: application indicates there are 20 pages and displays page 1.
User clicks on to page 2, then page 3.
User realizes that the record he was seeking is on page 2. User clicks on to page 2 again.
User thinks that he saw a similar record on page 1. User clicks back and forth between page 1 and page 2 repeatedly to compare the records.
With a web application, each page change necessitates loading an entirely new page. The end user probably thinks of it as just loading more data, but to the browser, this is just as much work as loading an entirely different page. Furthermore, when the user cycles back and forth between page 1 and page 2, the same data is being loaded from the server over and over again.
It's insane that with a modern computer equipped with billions of bytes of memory we have been conditioned to think of it as being normal for the computer to reload (over a slow connection with high latency) textual data that would take up megabytes at the very most.
I have an idea to use JavaScript to automagically load new records each time the user scrolls to the bottom of a page of records (There would be no paging links for the user to click on - the records would simply load as the user scrolls). This sounds nice; but one drawback that comes to mind is that it would be difficult to print the page without first having to click on to a "printer-friendly" view.
What other ideas are there for stuffing a database application into a web document without using a clunky paging system?
Well from the start I was going to suggest adding new records as the page is scrolled. If you are worried however about getting really long pages. The solution would be to hide the top records so there is only ever a max number of records showing. However, you would need to give the user the option of what the max is or an option for no max that way everything shows. Also, depending on their choice you may still need to offer a printer friendly version. Another note is it would probably be best to add a thing on the side telling the position like showing records 35-85 of 200.
I would go with the "automatically load new records as user scrolls to the bottom of the page." It's by far one of the most user-friendly method in my opinion.
For printing, you could rig each paginated set so that they receive a "no_print" class or something as new a set is loaded. Dynamically add/remove that class as the user scrolls back up.
So in my application, I have millions of records which the user can view seemingly all at the same time.
I load more records by requesting the same URL but changing the request headers.
Here is how you can implement something.
Let's assume that you want to list all the animals in the world in alphabetical order. You don't want to paginate by having a "< Previous 1 | 2 | 3 .. 9989 Next >" bar at the bottom.
You would start off and immediately query your "resources" route which will return a set of animals: GET /resources/animals.
Your request would include headers which say what it is exactly you are requesting. For example, add a range: 0-24 header. Related question: adding Custom HTTP Headers using Javascript
On the server side, you can figure out that the user is requesting the items 0 to 24 and you can respond back with Response Headers telling him what you are returning back like this: returned: 0-24/12000000. This tells the client that you have returned 25 items, starting from item 0 up to item 24, and there are still 12 million items left.
Render the items that you have received from the server.
As the user scrolls further down the page, query the next set of items. Using math and figuring out what is currently in view, you can calculate what "page" the user is viewing and can then request results which correspond.
You can see this working in practice here on the Dojo examples.
Read more about the subject.
I have an HTML page in which a table with innumerable no of cells are placed all over the page. In detail a employees 24 hour day schedule is divided into 30 min cell means 48 cells in row by 100 employees on average. Each cell on click opens a popup which on submit submits the whole page again.This is been in use since ages but a new client wants this should happen after all the random popups modfications are complete(means all changes should happen only once). This is mostly written in java,javascript with a custom framework.My qusetion is what is the dual approach for this kind of situation. Most generic answeres I researched is AJAX implementation but i feel some tweaking inside the javascript might fulfill the requirement.
Without AJAX, the only solution I can think of is not submitting the form every time one value is changed, but having a "Save" button that saves them all at once.
However, AJAX would be the best solution. All you do then is submit a iny amount of data to the server and that is dealt with, all while the user stays on the current page.
Mozilla's tutorial is probably the best on the subject if you're using plain Javascript. The various frameworks like jQuery have really simple built-in functions.
It's not absolutely necessary to use XML. A quick and dirty method for data for which you know the format and that is fairly similar is to just pass the data back and forth using the XMLHTTPRequest object. You could detect changes to individual cells with Javascript and events to store the cells that are modified and their new contents. Create the functions to pass the data back to a server page that updates the database.
This can be extremely fast. In one app I worked on, the HTML was 100k per refresh and this dropped to 5k or less when only the data was updated.
AJAX would definitely be the best solution for that. But seeing as you're hesitant to do a rewrite, two ways of improving come to mind:
Change the architecture of the table so that not every change requires a submit - it should be possible to change as many fields as necessary, and then save them all with one submit action. That depends on the table's structure, though, and the way the saving script works - a rework might be necessary, hard to tell without knowing more.
Create an invisible IFRAME, give it a name, and set all <form> elements' target attribute to that IFRAME. There would still be a submit action for every pop-up, but it would be submitted into the invisible Iframe, while the page does not have to be reloaded, and the user can continue working. This not really a beautiful solution but might do the job, at least as long as there are no file uploads involved.