legacyAjax option issue

DavidHarker

Hey guys,

I'm having an issue with the legacyAjax option:

On the first load the response from the server is fine...the "data" property is populated. When editing a row (either inline or through the popup form) the "data" property is 0, the "rows" property is the one populated and the page freezes until fully refreshed. Any ideas? Find attached debug report: http://debug.datatables.net/ipanec

DavidHarker

The data DOES save by the way, so I think the actual post is fine, it's the .Data() method that looks not to be returning in the correct manner?

allan

Hi,

Could you confirm what you are using on the server-side please? Your note about the Data() method makes it sound like you might be using the .NET Editor libraries - which is fine, but the 1.5 libraries shouldn't need the legacyAjax option (and in fact won't work with it set).

Allan

DavidHarker

Hi Allan, my apologies for the lack of info!

I am using .net server-side.

Don't we need it set when we aren't immediately looking to change to the new format until our next sprint?

DavidHarker

Infact removing the legacyAjax=true option produces this error: The given key was not present in the dictionary

DavidHarker

I suppose it's also worth noting we are currently using a trial and the dataTables.dll properties product version is 1.4.2 even though the download folder indicates it should be v1.5...

aeverington

UP

DavidHarker

UP

DavidHarker

I've managed to resolve the problem. The DataTables.dll that was provided in the download was 1.4.2. I rebuilt the dll from the code that was also provided - and it built as version 1.5. Using that new dll resolved the error r: The given key was not present in the dictionary - and everything now works as before. As Allen suggested, the legacyAjax option wasn't needed.

allan

Hi,

Thanks for posting back on this - I'm just looking into what has gone wrong with the packaging. I think I built it with debug rather than release immediately prior to deploying the release which has caused the wrong dll to be inserted.

Good to hear that with the correct dll it works as expected!

I'm looking into how best to resolve this just now.

Allan

allan

I've rebuild the 1.5.0 .NET packages to include the correct dll now. Apologies for the confusion!

Allan