Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaks when bProcessing: true and bServerSide: false #7

Closed
GoogleCodeExporter opened this issue May 24, 2015 · 5 comments
Closed

Breaks when bProcessing: true and bServerSide: false #7

GoogleCodeExporter opened this issue May 24, 2015 · 5 comments

Comments

@GoogleCodeExporter
Copy link

Using the plugin with dataTables bProcessing set to true, and bServerSide set 
to false (for ajax data sources), breaks it.

_fnAppyEditable gets called immediately, instead of being pushed onto the 
aoDrawCallback stack.

Fixed by changing line #406:
BEFORE:
if (oTable.fnSettings().oFeatures.bServerSide) {

AFTER:
if (oTable.fnSettings().oFeatures.bProcessing) {


Original issue reported on code.google.com by lars.d...@gmail.com on 20 Apr 2011 at 9:14

@GoogleCodeExporter
Copy link
Author

Hi,

 I don't understand what is the error you have notices. For ajax datasources you should set bServerSide to true and in this case is pushed _fnAppyEditable the aoDrawCallback stack. In any oher case it should not be used.
bProcessing is used only to show processing message and it do not have to be 
reated to ajax data source. As example on the page 
http://jquery-datatables-editable.googlecode.com/svn/trunk/customization.html 
is set bProcessing to true although DataTables is not used with ajax data 
source (It is just used to show procesing dialog while the row is deleted). I 
cannot see any error in this example (original code is still there).
If I apply you patch in the customization page should be applied 
_fnApplyEditable each time page is refreshed and this should not happen if 
table works with static data (or I'm wrong?).
Could you please clarify me what was the problem in your example?

Thanks,
Jovan

Original comment by joc...@gmail.com on 4 May 2011 at 4:56

@GoogleCodeExporter
Copy link
Author

Hey,

I get your point about bProcessing, so nevermind that.

But should one use bServerSide when using a regular JSON ajax source? As far
as I can tell, one should only use bServerSide when using the server for
processing the data, which is not my case with just the json source.

I think in that case, the table needs to be redrawn, and _fnApplyEditable
should be pushed onto the aoDrawCallback stack. That's what I've found on
the datatables forums atleast.

But yes, using bProcessing to check for that is stupid. Perhaps if
bServerSide == true or sAjaxSource == true is better, depending on
sAjaxSource's initial value.

Lars Kristian Dahl

On Wed, May 4, 2011 at 6:57 PM,
<jquery-datatables-editable@googlecode.com>wrote:

Original comment by lars.d...@gmail.com on 4 May 2011 at 5:07

@GoogleCodeExporter
Copy link
Author

I'm referring to a situation like this:
http://www.datatables.net/examples/data_sources/ajax.html

<http://www.datatables.net/examples/data_sources/ajax.html>Where data is
fetched asynch from an ajax source, but all processing is still client-side.
:)

Original comment by lars.d...@gmail.com on 4 May 2011 at 5:12

@GoogleCodeExporter
Copy link
Author

You are right editable does not work in ajax source mode when bServerSide is 
not set. I have created this example on the 
http://jquery-datatables-editable.googlecode.com/svn/trunk/ajax.html and cells 
are not editable.
I will add if(sAjaxSource == null) or something similar because both in the 
serverside mode and plain ajax source mode this variable is set.

Thank you for noticin this I completetly missed this case of usage for 
dataTable.

Regards,
Jovan

Original comment by joc...@gmail.com on 4 May 2011 at 9:02

  • Changed state: Started

@GoogleCodeExporter
Copy link
Author

In the version 1.1.5. this is changed. You can check it on the 
http://jquery-datatables-editable.googlecode.com/svn/trunk/ajax.html.

Thanks,
Jovan

Original comment by joc...@gmail.com on 4 May 2011 at 10:37

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant