$(function () {
// Replace the builtin US date validation with UK date validation
$.validator.addMethod(
"date",
function (value, element) {
var bits = value.match(/([0-9]+)/gi), str;
if (!bits)
return this.optional(element) || false;
str = bits[1] + '/' + bits[0] + '/' + bits[2];
return this.optional(element) || !/Invalid|NaN/.test(new Date(str));
},
"Please enter a date in the format dd/mm/yyyy"
);
});
Monday, April 8, 2013
Override Jquery client validation on date format
Jquery Unobtrusive validation on hidden field
<script type="text/javascript">
$(function () {
var form = $('#[formID]);
form.data('validator').settings.ignore = ''; // default is ":hidden".
});
</script>
Thursday, March 7, 2013
Change the object graph or increase the MaxItemsInObjectGraph quota. '. Please see InnerException for more details.
Original Article
When you start with WCF, you will certainly need to adjust the limits of the service. By default they are kind of low. So in my case we did. Especially the maxrecievedmessagesize.
Setting up the service, configuring you’re limits and start to use. Sounds really great and simple. But sometimes when you are working with development data and start doing stress tests, you will encounter even more limits. One of these will generate this really nice error:
The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://tempuri.org/:GetCountriesResult. The InnerException message was 'Maximum number of items that can be serialized or deserialized in an object graph is '65536'. Change the object graph or increase the MaxItemsInObjectGraph quota. '. Please see InnerException for more details.
What this really means is that the number of objects send through the wire is higher than the default limit or the limit you have specified. To send more large number of records (objects) over the wire you’ll need to adjust the following:
On the server (raise the maxitemsinobjectgraph):
On the client (raise the maxitemsinobjectgraph for the clients endpoint behavior):
The maximum size of the maxItemsInObjectGraph is: 2147483646.
Now you can get those long lists of data and sent it over the wire. Although I strongly believe you should reconsider when a lot of these exceptions occur and split up data in chunks or rethink the way the data is shown to the user.
When you start with WCF, you will certainly need to adjust the limits of the service. By default they are kind of low. So in my case we did. Especially the maxrecievedmessagesize.
Setting up the service, configuring you’re limits and start to use. Sounds really great and simple. But sometimes when you are working with development data and start doing stress tests, you will encounter even more limits. One of these will generate this really nice error:
The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://tempuri.org/:GetCountriesResult. The InnerException message was 'Maximum number of items that can be serialized or deserialized in an object graph is '65536'. Change the object graph or increase the MaxItemsInObjectGraph quota. '. Please see InnerException for more details.
What this really means is that the number of objects send through the wire is higher than the default limit or the limit you have specified. To send more large number of records (objects) over the wire you’ll need to adjust the following:
On the server (raise the maxitemsinobjectgraph):
1 2 3 4 5 6 7 8 | <behaviors> <serviceBehaviors> <behavior> … <dataContractSerializer maxItemsInObjectGraph="10000000"/> </behavior> </serviceBehaviors> </behaviors> |
On the client (raise the maxitemsinobjectgraph for the clients endpoint behavior):
1 2 3 4 5 6 7 | <behaviors> <endpointBehaviors> <behavior > <dataContractSerializer maxItemsInObjectGraph="10000000"/> </behavior> </endpointBehaviors> </behaviors> |
The maximum size of the maxItemsInObjectGraph is: 2147483646.
Now you can get those long lists of data and sent it over the wire. Although I strongly believe you should reconsider when a lot of these exceptions occur and split up data in chunks or rethink the way the data is shown to the user.
Thursday, October 4, 2012
tkglaser.net: Waiting spinner for long-running form submits in A...
tkglaser.net: Waiting spinner for long-running form submits in A...: In the application I'm currently working on, I have a search form, where you can specify a number of parameters, press the search button, an...
Wednesday, September 5, 2012
Configure log4net to read config from web.config
// Tell log4net to watch the following file for modifications: [assembly: log4net.Config.XmlConfigurator(ConfigFile = "Web.config", Watch = true)]
For App.Config:
[assembly: log4net.Config.XmlConfigurator(Watch = true)]
Add above code inside AssemblyInfo.cs!!
Wednesday, June 13, 2012
postback twice when submitting-an-mvc-ajax-beginform-using-javascript-and-jquery
Solution
I applied onsubmit = "return false;" on the htmlattribute of the ajax.beginform.
I applied onsubmit = "return false;" on the htmlattribute of the ajax.beginform.
Subscribe to:
Posts (Atom)