Client Callbacks are probably the less known (and I dare say, less loved) of all the AJAX options in ASP.NET, which also include the UpdatePanel, Page Methods and Web Services. The reason for that, I believe, is it’s relative complexity:
- Dynamically register function that calls the above reference;
So, here’s what I want to do:
- Have a DOM element which exposes a method that is executed server side, passing it a string and returning a string;
- Have a server-side event that handles the client-side call;
- Have two client-side user-supplied callback functions for handling the success and error results.
The control itself looks like this:
And the event argument class:
You will notice two properties on the CallbackControl:
Async: indicates if the call should be made asynchronously or synchronously (the default);
SendAllData: indicates if the callback call will include the view and control state of all of the controls on the page, so that, on the server side, they will have their properties set when the Callback event is fired.
The CallbackEventArgs class exposes two properties:
Argument: the read-only argument passed to the client-side function;
Result: the result to return to the client-side callback function, set from the Callback event handler.
An example of an handler for the Callback event would be:
Finally, in order to fire the Callback event from the client, you only need this:
The syntax of the callback function is:
arg: some string argument;
context: some context that will be passed to the callback functions (success or failure);
callbackSuccessFunction: some function that will be called when the callback succeeds;
callbackFailureFunction: some function that will be called if the callback fails for some reason.
Give it a try and see if it helps!
Following my last post, I decided to publish the whole set of expression builders that I use with SharePoint. For all who don’t know about expression builders, they allow us to employ a declarative approach, so that we don’t have to write code for “gluing” things together, like getting a value from the query string, the page’s underlying SPListItem or the current SPContext and assigning it to a control’s property.
These expression builders are for some quite common scenarios, I use them quite often, and I hope you find them useful as well.
This expression builder allows us to specify an expression to be processed on the SPContext.Current property object. For example:
It is identical to having the following code:
Returns a property stored on the farm level:
Returns the value of a selected page’s list item field:
Does the same as:
Checks if the current user belongs to an audience:
Checks if the current user belongs to a group:
The equivalent C# code is:
Returns the value of a user profile property for the current user:
Where the same code in C# would be:
Returns a value passed on the query string:
Is equivalent to (no SharePoint code this time):
Returns the value of a property stored at the site level:
You can get the same result as:
OK, let’s move to the code. First, a common abstract base class, mainly for inheriting the conversion method:
Next, the code for each expression builder:
You probably know how to register them, but here it goes again: add this following snippet to your Web.config file, inside the configuration/system.web/compilation/expressionBuilders section:
I’ll leave it up to you to figure out the best way to deploy this to your server!
OK, you already know about the ObjectDataSource control, so what’s wrong with it? Well, for once, it doesn’t pass any context to the SelectMethod, you only get the parameters supplied on the SelectParameters plus the desired ordering, starting page and maximum number of rows to display. Also, you must have two separate methods, one for actually retrieving the data, and the other for getting the total number of records (SelectCountMethod). Finally, you don’t get a chance to alter the supplied data before you bind it to the target control.
I wanted something simple to use, and more similar to ASP.NET 4.5, where you can have the select method on the page itself, so I came up with CustomDataSource. Here’s how to use it (I chose a GridView, but it works equally well with any regular data-bound control):
The OnData event handler receives a DataEventArgs instance, which contains some properties that describe the desired paging location and size, and it’s where you return the data plus the total record count. Here’s a quick example:
Here’s the code for the DataEventArgs:
As you can guess, the StartRowIndex and PageSize receive the starting row and the desired page size, where the page size comes from the PageSize property on the markup. There’s also a SortExpression, which gets passed the sorted-by column and direction (if descending) and a dictionary containing all the values coming from the SelectParameters collection, if any. All of these are read only, and it is your responsibility to fill in the Data and TotalRowCount.
The code for the CustomDataSource is very simple:
Also, the code for the accompanying internal – as there is no need to use it from outside of its declaring assembly - data source view:
As always, looking forward to hearing from you!