We are using an older character based version of QAD's MFG/PRO running on Progress version 10.1. On one of the shipping tables, I've to create a browse that will display all records in a scrollable browse (sort of infinite scroll browse). It will display first 10 records initially, but user will be able to scroll up or down in the browse, which should load previous or next record (up or down arrow key).
I was wondering how something like this can be achieved. Preloading a temp-table with millions of records doesn't seem like a good idea, querying the database for every up or down arrow key press sounds equally bad. Does DEFINE BROWSE provides a way to achieve this? Is there a way to code lazy loading type scenario?
Also, how the scenario would change if instead of a browse showing data from a single table, will combine data from multiple tables?
Any help/pointers in this regard will be helpful. Also, if some best practices can be shared.
You can look at the END and OFF-END events in the browse widget. This will alert you when the user wants to scroll forward/backward. The query associated with the browse also has an OFF-END event that you could look into using for this.
Doc at https://docs.progress.com/bundle/abl-reference/page/High-level-widget-events.html#High-level-widget-events
Related
I need to view data with expanded sub-data in a continuous view. I have a query with subdatasheets that does the job, except it keeps asking to save changes to layout.
My query is not in a form. I'm just opening and closing the query, without making any changes. But if the "Subdatasheet Expanded" property is set to Yes it always asks if I want to save changes to the layout. If I change the property to NO, it doesn't ask.
Is there any way I can get the query to expand all subdatasheets without asking to save changes to layout?
I would prefer to place the query in a form, but I can't find a way to get expanded subdatasheets that works with continuous forms layout.
I know I could use a subform showing the subdatasheet, but then I can't get continuous forms, and that is an essential requirement.
Any help/advice appreciated.
I'm working on identifying accessibility issues with a database-driven web application. One of the features of this web application is that the user can open up a modal window and filter by data columns. I included a couple of images to show what this looks like.
This is incredibly hard to use with a screen reader, mainly because I can't figure out how to associate the relationship dropdown with the input field. If a user selects a relationship (equal to, not equal to, greater than, etc...) I need to let the user know that it's associated with the input field to the right of it. But, I don't even know what this would be called or what I would wrap it in. Can anyone point me in the right direction?
I am using Asp.NET MVC4 with Razor.
I want to show a list of items/entries (coming from a database) over several pages where the user can navigate to the next page or a specific page and each page shows e.g. 30 entries. It should be similar to the way the questions are structured in stackoverflow with this little page navigator at the bottom. How would I do that? I would guess that an example already exists but I have not found any.
Right now I show all my items on one page using a partial view in my index-view:
#foreach (var item in Model) {
#Html.Partial("_ItemInList",item)
I could probably only show the first 30 items but how do I store on which page I am and make the links so that the user can navigate to the other pages?
You could use a pagination control. There are many such components. For example you may take a look at MvcPaging hosted on GitHub.
There's an awful lot of ready made pagination controls available if you're looking for a quick result... but you're probably better off rolling your own. You can restrict your result set to a given page size in your data access layer using Linq and populate your model with single page (plus totals, page number etc...).
Depending on how you've structured your application though, you may want to push paging down to the database level and limit the result set size there rather than higher up the stack.
I have this GUI that shows, let's say Customer Orders. When my client nailed down the requirements, he asked me to keep pagination like this,
Show Items Per Page : 10/50/150
For each customer there could be thousands of orders and each order will have atleast 50 attributes to show up in the screen. So, assume a 50 column html table with 2000 or 3000 records associated with it spanning across multiple database tables (anyway, this is a different story)
Things were breeze until yesterday, now my client has come up with new change requests, in that he specified Show Items like this,
Show Items Per Page : 10/50/150/All
Yes, he wanted to see 2000 or 3000 records by just select "All" option. Internally, this is not a big change, I would go back and remove the filters I apply on rowcount etc., but when it is loaded in GUI it really sucks ... view state was huge etc., etc.,
I know, this is a standard problem. How you guys deal with it? I cannot convince my client to remove this "All" option, he got stick to it. (the reason is simple, he got a big 42" screen where he can easily see 1000 items in one page)
I also tried to use javacript to prepare DOM in a ajax call .. but still, inserting 2000 TDs is really slow.
Any help is greatly appreciated.
Some Extra Info
This application is a intranet application or else accessed through VPN connection
This problem is about browser performance.
I suppose you can do two things.
1) you can use <div> instead of <table> (this is possible with CSS) because browser do not render table until closed tag. So it will take long to load page but it will render first results faster.
2) If you use Ajax+Json and render every <tr> piece by piece, you can render whole thing and only than put it in DOM. That will be faster because browser will not render every time you put another row
If you want you can load the data in sort of installments. Sort of like how pagination works but it is not quite pagination to be precise. You can label your installments/pages with a proper ID. Load the page one after another via ajax calls. You can even show a progress bar to show how much data is actually loaded. Append this data to the table you are displaying the data in. I would not go about using server controls for this...you have to handle this via javascript or jquery.
You might want to append table rows incrementally.
When client scrolls close to page bottom - fire an ajax call, return next page and render it.
But best solution would be to convince your client - this is not how web applications works. We had similar situation - pure nightmare.
Instead of an ASP.NET GridView, you'd be better to use a DataRepeater.
Better yet, if you are not constrained by technology, you can use Microsoft Ajax Preview 4 with WCF REST Services. You would just need to find some hacks to "stream" data from the service and display it.
Also there is JQuery Grid (if you don't want to use Microsoft Ajax Preview 4) that supports JSON serialization.
I have a grid with several thousand rows that can be filtered and sorted. On each row you can click a details button, which will bring you a new page with detailed information about the page. Because this is a button, you can't middle click or right click and open in a new tab. In addition, when clicking back you lose your filters and search results.
To solve this problem, I considered the following: Switch the buttons to links, and when filtering and searching, use get instead of post requests. This way, you could switch to new pages with a right click or middle click, and if you did follow a link normally, back would work properly.
This change was not made however. We were asked add a 'next result / previous result' set of buttons on the details page, that would allow you to navigate. While not an elegant solution, it would at least work.
I proposed adding querystring parameters to the details page, that would regenerate the search query based on filter, and allow you to get the next and previous results in code.
A team member took issue with this solution. He believes that it is a waste of server resources to re-query the database. Instead, a solution was proposed to add session variable that included a list of results. You could then use that to navigate.
I took issue with that because you can't have multiple tabs open without breaking navigation, and new results aren't appended to the list in real time. Also, if you worried about optimization, session would be the last thing to use since it eats memory and prevents server replication... unless you store the results back in the database.
What's the best solution?
Session doesn't sound like a winner, won't scale with lots of users.
Hitting the database repeatedly does seem unnecessary, but it depends on the cost - how many users, how often would they refresh/filter and what is the cost of that query?
If you do use querystrings you could cache the pages by parameter.
What about some AJAX code on that button to retrieve details - leave the underlying grid in place and display details in a div/panel or a new window/tab.