I have a ListView that I am databinding to a collection of objects something like this:
int total;
List<Client> clientList =
clientData.GetClients(criteria, pageNum, pageSize, out total);
uxClientList.DataSource = clientList;
uxClientList.DataBind();
Where the pageNum, pageSize and total parameters facilitate paging at the data access layer. So far so good.
Now I can throw a DataPager on the page, point it at the ListView and get a decent paging UX. There's a little more to it when you're binding programmatically instead of declaratively with a data source control, but the problem here is that DataPager expects that the entire result set is being retrieved each time, from which it should calculate pagination, so it sees the single page of results returned as the total available records and gets rendered as if there is only one page of results available. In other words, the above scenario works fine with DataPager if we switch to a non-paging version of GetClients:
List<Client> clientList = clientData.GetClients(criteria);
uxClientList.DataSource = clientList;
uxClientList.DataBind();
Obviously since our data access layer is kind enough to provide us with a method to retrieve a page at a time, this would be preferable to retrieving all records every time. It would be nice if we could explicitly inform DataPager of the total available records so it could still automatically create pagination output, but only require one page at a time to do so.
I haven't found an easy way to do this and I haven't turned up anything in searches. Admittedly I don't currently posses a deep understanding of the implementation of DataPager, so hopefully I'm overlooking something.
Have a look at the ListViewPagedDataSource and its AllowServerPaging property, I think that may be what you're looking for..
You haven't overlooked anything.
When dealing with large result sets you need to turn paging off and add your own paging controls.
In my experience << < > >> suffice. Nobody goes past the 3rd page anyway.
Related
So I have setup a model/table that users will use as a project task list. I would like it so that when they change the Status (a field in the model) of an item to either Completed or Cancelled it is hidden.
That way they are only dealing with active entries. But I would also like them to be able to view these hidden (archived) items if needed.
I added the following code to the onAttach option of the table
var datasource = app.datasources.Projects;
datasource.query.filters.Status._notContains = 'Completed';
datasource.load();
And then I have a button with the following code so they can see hidden/archived items:
widget.datasource.query.clearFilters();
widget.datasource.load();
app.closeDialog();
var datasource = app.datasources.Projects;
datasource.query.filters.Status._contains = 'Completed';
datasource.load();
It works, but I feel like there might be a better/more elegant way to accomplish this. Especially since it looks like the app has to load then data, THEN filter it (which results in a slower load). (I think I might have some redundant code in there as well)
Also I feel like I am missing something with my syntax, because I can't get it to filter out Completed AND Cancelled.
Thank you for your help!
If you have a single page of items in the table and there aren't many items, then you can filter on the client side. For example, you can use a binding expression to add a "projectHidden" style to the row based on some logic and then use CSS to change the visibility of the row.
For your second code block, there is no reason to clear filters, load, set the filters and then load again. Just clear the filters, set the new filter, and call load. Also if you are manually controlling the query load, then you might want to uncheck the setting in the data source to automatically load data.
var datasource = app.datasources.Projects;
datasource.query.filters.Status._notEquals = 'Completed';
datasource.query.filters.Status._notEquals = 'Cancelled';
datasource.load();
I have a simple master/details relationship where one order can have multiple revenue allocations. The order has a collection that contains these.
I want to sum a property in my revenue allocation objects and ensure that it adds up to my order total. However, if I databind on the count property of the allocations collection this gets called when you first add an empty object and not when that object has been populated. So an empty allocation is added at the time the "Add allocation" screen is created and the databind function called. That of course means that when the save button on the "Add allocation" screen is clicked, the databind function isn't called again.
Anyone got any ideas? I basically want my databind function to be called when the save button is clicked in the "add screen" and not before.
This is the HTML client - NOT Silverlight
I'm pretty sure that the solution would be to use an OData query to get your aggregate data within the databinding function of the save button - or perhaps a separate button (e.g. "Tally Order Totals"). Exactly how you do that? A bit too hard for me to answer right now, but start with a new button TallyOrderTotals and a new data field for your total. Edit the post_render event for TallyOrderTotals and lookup the allocations in the javascript in which you data bind the value of the new data field.
Somewhere you will need a piece of code that looks something like this:
myapp.activeDataWorkSpace.<datasource>.RevenueAllocations
.filter("OrderID eq " + msls._toODataString(<orderID>, ":String"))
.execute()
.then(function (result) {
// assign the result somewhere
}
I'm not saying that's something you can cut-and-paste - but definitely look at the msls.js documentation and see what you can do with querying your data inside the event context.
One quick point however - if you only need to calculate that total as a verification step, consider doing it in the SaveExecuting() event on the server side. This will allow you to throw an exception back up the tree to your HTML page which the msls.js script should render on the client side.
Hope that helps. :)
Reading through Misko's excellent answer on databinding here: How does data binding work in AngularJS?, I am wondering how Angular does it's dirt-checking behind the scenes, because:
I'm creating an app, that prints a large amount of Car objects to the DOM, each Car looking something like this:
var Car = function(settings) {
this.name = settings.name;
+ many more properties...
}
Car.prototype = {
calcPrice: function() { ... },
+ many more methods...
}
$scope.cars = [lots of Cars];
The linked answer above mentions a limit of around 2000 values that can be provided through databinding when printed in the DOM, and due to the large amount of properties on each Car object, this number could very easily be exceeded in this app when looping through the cars array.
Say you end up having 2000+ values printed in the DOM through databinding, and one of these values updates, does it affect Angular's dirt-checking performance that 2000 values are present, or does Angular somehow flag the values that change, so it only looks at the changed values when running its $digest()? In other words, does it matter that you have a lot of databound values, when only a very small number of these are likely to be updated after the initial print?
If it does matter, -- and since most of the values are read-only -- is there some way to use the databinding syntax {{car.prop}} to get the value to the DOM once and then tell Angular to not bind to them anymore
Would it make a difference to add getter-methods to the Car object and provide it's properties like this {{car.getProp()}} ?
I had the same kind of problem with an application I was working on. Having a huge data set is not a problem, the problem comes from the bindings,ng-repeats in particular killed performances.
Part of the solution was removing "dynamic" bindings with "static" bindings using this nice library: http://ngmodules.org/modules/abourget-angular.
i created web page with dropdownlist and two gridview and on selectedindex changed event i fill the both of these gridview but in the running the both of gridview take long time to be filled.
Note:one of this gridview i created its datasource by code.
here my code snippet:
protected void _ddlPLCs_SelectedIndexChanged(object sender, EventArgs e)
{
DataTable dtStatus = new DataTable();
dtStatus = DBLayer.getMachineNameIPStatusPlCByName(_ddlPLCs.SelectedValue);
dtStatus.Columns.Add("Status", typeof(String));
foreach (DataRow row in dtStatus.Rows)
{
if (LogicLayer.checkmachineStatus(row["machineIP"].ToString()))
row["Status"] = "Online";
else
row["Status"] = "offline";
}
GVStatus.DataSource = dtStatus;
GVStatus.DataBind();
if (_ddlPLCs.SelectedValue.Contains('-'))
{
_dsPLCs.SelectParameters.Clear();
_dsPLCs.SelectParameters.Add("PLCID","0");
_dsPLCs.DataBind();
}
else
{
_dsPLCs.SelectParameters.Clear();
_dsPLCs.SelectParameters.Add("PLCID", DBLayer.getPlCIDByName(_ddlPLCs.SelectedValue).ToString());
_dsPLCs.DataBind();
}
}
pleas help me
Looking at the code, I think the problem is in this method:
LogicLayer.checkmachineStatus()
I have a hunch that this actually makes a network request to remote machines/devices to determine their status. This is going to be slow, especially if you have machines that might not be online and you have to wait for them to timeout.
If this is the culprit, what you want to do instead is build a service that runs on your server. The service should continually make these checks in the background and update a database table with the results. You probably want to include a timestamp for the last check in the table. It might even be worth inserting rather than updating, so that you have history of when status's were at different values. Your ASP.Net code should then just show the database table.
Profile! Get a trial version of RedGate ANTS and run it against your code.
If you choose line level timings, it will put a number next to each line in the code that will tell you exactly how long each line takes as a % or in milliseconds. Make sure to use wall clock time not cpu time or wait time from your datasource won't be counted properly.
I'd bet your datasource is slow.
You're doing a lot of work here...
A few random thoughts
Networks can be slow -- #Joel had a good point on that one.
One thing to check would be postback -- make sure you're only databinding on selected index changed.
Why aren't you using a 'handles' caluse in your function? Might not be a problem, just curious.
If you change your "status" column header to "online", and then use checkboxes (checked = online, unchecked = off-line, or something like that, you'll just be updating a bool value for each row, instead of a string value.
Something looks odd about how you're re-binding your dropdownlist. Because... You're using the selected value as a parameter in the gridview. Then you're subsequently re-binding the dropdown list, which potentially will result in a different selected value. Which could be causing your gridview to be databound yet again in a circuit. Not sure, as I can't see all of your code.
Anyway, FWIW. Good luck.
I have a ListView control which I used to populate using an ASP ObjectDataSource control. This worked fine.
However, I wanted to implement a filter that showed items in the ListView that began with the letter A, B, C, etc. To do this, I removed the ObjectDataSource control and replaced it with some code in the Page_Load event allowing me greater control over what I was passing in as the data source, similar to this:
System.Diagnostics.Debug.Print("{0:HH:mm:ss} : GET DATA", DateTime.Now);
List<MyItem> items = GetItems("A"); // Gets a list of items with a description that
// begins with A
MyListView.Datasource = items;
System.Diagnostics.Debug.Print("{0:HH:mm:ss} : BIND DATA", DateTime.Now);
MyListView.DataBind();
System.Diagnostics.Debug.Print("{0:HH:mm:ss} : DONE", DateTime.Now);
Output (times are representative of actual results):
16:00:00 : GET DATA
16:00:00 : BIND DATA
16:00:20 : DONE
Since doing this, it takes about 20 seconds to load the page in my browser, instead of around 1 second when I used the ObjectDataSource.
To load the data into my ListView rows, I use the standard <%# Eval("Description") %> method. After some searching on SO and google, some people seem to say that Eval is inefficient.
Why does manual binding in the Page_Load event slow everything down? Is it because Eval is inefficient? How can I speed it up, and what is the correct way to do this?
It seems highly unlikely to me that the problem is the Eval statement or the the fact that you're databinding in the page load unless your returning a very very large list. Eval may be slower but not by the amount you are seeing. There is probably another cause.
I would double check the GetItems() function. It's more likely that the selection code is somehow less efficient than it could be.
Additional things to check...
Check the properties Eval is calling. Does they do something more that just return a string? Eval will run whatever code is within those properties/methods so make sure they are as fast as possible.
How many records are in your database? Do you have paging enabled? If so, the problem might be that the ObjectDataSource is using a more efficent method to retrieve only the number of objects that it intends on displaying, whereas your call to GetItems() is returning everything, even if it isn't being displayed. Given the huge disparity in the time to return, that is my guess as to what is happening.
If that is what is happening, you speed it up by limiting the number of records you are returning. This is going to depend on your implementation of GetItems(). You'd want to write something like GetItemsPaged(int firstRecord, int pageLength) that returns only a limited amount of data.