I'm fairly new to JSF, and to coding itself. I'm working with JSF for 9 months now, and I noticed two ways of populating data tables:
-when pagination link is clicked, then new query is executed with given first and last record to show from results
-when user loads page query is executed and records are store in bean, so when pagination link is clicked, there is no query only giving records from stored result list (primefaces)
And here is my question :
Witch way is better?
I assume that second way need more memory, but it's used by primefaces, so I'm not sure that this is 'the right way'
First way need less memory - it gets only records needed to show, but isn't it to slow?
PS - BalusC - I hope you will take part in this discussion, since I see your answers very helpful, and explanatory:)
Personally when it comes to populating and managing a datatable. I feel the lazy-loading is the best practice. This is not a JSF specific way of loading the data, however; a few component libraries make it easy to implement (Primefaces, Icefaces, etc...).
Lazy-loading will help maintain large amounts of data, making sure the your page doesn't hang up and will keep a smooth user experience.
Primefaces LazyDataModel
Icefaces datatable(Already implemented)
Rich-faces Lazy Loading
Related
Hello World,
I'm in research mode for one of feature to be built in our software and there one new thing that we have never faced.
The thing is, on one form we have a drop down with list of items. User can select default which means all items needs to be considered or else he can selectively opt for certain list items.
Actually the form is related to filter functionality depending upon users input the data is going to get filtered and displayed on UI.
The main problem we are trying to solve is suppose user selects default, which means all list items ID's are gonna be considered in POST call of API. The list can be huge, say 1 to 1K and above too.
So under such circumstances we can build the query string but, it seems its gonna be so huge. I have also studied that certain browsers support limited query string as per their standard limits.
So currently I have following doubts in mind.
Will shortening of query string work here ?
By which technique it can be handled efficiently ?
What performance considerations I need to take care during during so ?
Any suggestions or thoughts are welcome. That would boast my software design thinking.
based on what I understand from your question, here is my opinion:[if I understood wrong, please correct me, so I can help you]
You need to send query in URL and not in body or using JSON!is that correct?
I think you don't need to send every one of the selected items one by one!
If there are selected in serial, you can perform a range in your query!
Like http://abcd/test?id=1-43,6-765(take ID as string and then export the useful data in back-end) with this approach, you can shorten your query!
And also think about the database too (if there is any).querying this much data is use a lot of IO and make query low performance.
I'm interested in displaying 1-5 model instances using forms on a page using a grid similar to something one would find in a desktop database application. I understand I would need to use multiple forms or formsets but an additional requirement is that I'd prefer it to be in more of a grid format with each model's fields being display in columns with common field labels on the y-axis.
I should have the ability to edit multiple columns (so in effect, model instances) at the same time and then commit either the single column (model instance) or commit all. I'd also like to be able to highlight the changed cells that have changed to give visual feedback to the user that there are pending changes.
Sorry for the rather long list of requirements and I'm aware this probably requires a few different technologies/techniques to achieve. I'm throwing this out there because I'm asking this kind community for guidance on what components/technologies I should look at. If luck would have it, there would be some jQuery component that can handle this for me almost out of the box. If not, some guidance on achieving the editing of multiple model instances would be of help.
I will also need to build in versioning in case the data displayed on the view page is stale and to prevent overwriting a newer commit. I'd probably achieve the latter using a versioning field in the table that will perform the check and handle it accordingly.
Also, Flask and Django are both options for the engine and WTForms look to be promising at least at first look.
Thanks
There is no such ready to use solution in Django. Just create your custom form that handles as many instances as you want and do anything that you want, or extend formset.
I'm searching for how other extjs developers work on a UI component before the json response from the backend is hooked up and working.
Feel free to be specific with code samples of how I might toggle back and forth between live data and a hard coded counterpart.
Is there one method of hard coding a datastore that can be used by every component or does each component require variations?
How would I use a remote datastore and only swap out one field value with hardcoded data?
Sorry for multiple questions, I guess what I'm really looking for is advice on what other extjs developers have found to be able to work on and test custom views without relying on the server for data.
Thanks
For the scenario you describe, I have created a store with hard-coded data and tied a component, in my case a chart and grid, to the store. Now when I get the live data from the server all I do is update my store which in turn updates the chart.
I am not sure if this is the answer you're looking? I can certainly give you some code examples if that will add value to this answer. Let me know.
An iphone app we are producing will potentially have a table with 100,000+ records (scaling wise) and I am concerned that loading all this data via a SELECT * command into an array, or an Object will either make the app very slow; or will leave me with memory issues later on.
Obviously loading 100,000+ records into an array when the viewscreen/viewport only shows 30 odd records in a go is a tad silly.
In addition, I am not sure if storing all this data in an object is the right thing to do either.
So my question is, is it possible to stagger sqlite through records, say 50 records in cache and then when you swipe down or up it loads an appropriate amount into the cache. I guess its similar to the JQuery Lazy Loading library where it only loads a little bit on the view port and then loads more as you move down.
I'm looking at JSON, but it appears to only be for Web services as it requires a URL and I am not sure if it works for files that are on the phone.
Therefore. Is there a proper way to load sqlite data into Objective C arrays/objects without causing problems when the data suddenly starts to scale?
Thanks for your help.
You definitely want to avoid loading in everything at once. Instead, you want to use a cursor and smarter queries so that you only pull data out of the database as you actually need it for display; that link points to some hints on how to do that.
Generally, you also want to avoid blindly selecting all columns. This is because you may sometime update the schema to add a column that your existing code would not always know how to extract; far better to name the explicitly columns that you expect and desire.
My members will have the ability to customise their profile page with X amount of widgets, each widget displays different data such as a list of music, list of people they are following etc.
Several widgets include:
- List of media they have uploaded
- List of people they are following
- List of people following them
- Html/Text widget
- Media Statistics (num downloads etc)
- Comments widget for other members to leave comments
Some widgets will have to page the data returned because there could be hundreds of results.
I haven't done any optimisation at the moment so it is doing lots of DB work to return all the data...what would be the most efficient way to retrieve the data...would 1 DB call per widget be acceptable? There could be around 5-20 widgets per page.
If you need more information about my situation please feel free to ask.
Paul
Short answer: It depends.
Start off from the unoptimised state, then use SQL profiler or a C# profiler like dotTrace to work out the best places to make improvements. Set a realistic goal to work towards (e.g. 'less than 800 milliseconds to load the page').
Generally I find performance starts to suffer after about 20-30 database calls in a request, but this is going to depend on your server, the location of the database etc.
There are many things that you can try: pre-caching, eager fetch using joins rather than selects etc. Nothing is going to guarantee better performance though unless it is applied intelligently.
For a page with lots of widgets, a common design pattern is to load each widget asynchronously using AJAX, rather than loading the entire page in one go.
since you've cut out out your work to widgets the proper thing to do would be for each widget to do a single query for all its required functionality. This would also be the case even if you retrieved widgets via AJAX (which as cbp noted is not a bad idea).
Secondly, i would set up some kind of mechanism for each widget to register its existence and then after all widgets have registered then i would fire a single query that would include all widget queries. (technically its again multiple queries but in a single round-trip, see MulriCriteria and MultiQueries in NH reference).
Also do not forget that lazy loads are hidden db retrievals and you could have a huge performance impact by using lazy load in a situation where an eager load is proper (for example Foo.Bar.Name where you always show the Bar.Name value when you present the Foo entity)
Performance degradation can occur even with less that 20-30 database call per request, but it depends on the size and complexity of your entities, queries, filters as well as the size of the data sets retrieved.