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

Custom delete dialogs #22

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

Custom delete dialogs #22

GoogleCodeExporter opened this issue May 24, 2015 · 7 comments

Comments

@GoogleCodeExporter
Copy link

The default way to confirm the deletion of a row is to pop up the 'confirm' 
dialog (which is synchronous, blocks the rest of the page).
This looks like poo.

We could try to pop a jquery dialog instead of the 'confirm' dialog, but that 
won't work because the jquery dialog is asynchronous.

The way we got around the issue is to copy the events away from your delete 
button to a hidden button, pop up a jquery ok/cancel dialog and if ok was 
clicked, then call .click() on the hidden button.
This will then send your plugin into action.
We also just do a return true for fnOnDeleting (since we have already asked the 
user to confirm/deny).

That works, but seems to be quite a bit of hacking.
It also has a fairly serious drawback.
We would like to populate the jquery dialog with information from an ajax call. 
That will notify users about what other data is about to be affected. In order 
to make that call we need the ID of the item about to be deleted. The only 
place you provide that ID is during fnOnDeleting (which is too late).

So I'm asking for an enhancement.
I can think of a couple of options.
1) Just like for add dialog, can we get a custom delete dialog. This dialog can 
then have a callback to actually start the deleting process (_fnOnRowDelete) 
when the OK button is clicked.

2) Give us another method that will be called even before the fnOnDeleting().
It can still give us the row ID that we can then store in a hidden field.  This 
one is more 'hackish' to me.. but the easiest for you to implement.

What version of the product are you using? On what operating system?
jquery.datatables.editable: 1.2.1
jquery: 1.6.1



Original issue reported on code.google.com by kenneth....@gmail.com on 2 Jun 2011 at 7:38

@GoogleCodeExporter
Copy link
Author

Hi,

Regarding the standard confirmaiton I agree it is not really nice. However, if 
you have any other modal/synchronous dialog, you can use it instead of standard 
one in the fnOnDeleting function e.g.: 

fnOnDeleting: function(tr, id) {
     return MyCustomConfirm("Do you want to delete a record with an id " + id); ;
}

In this method you will have id of the record that will be deleted end row. 
this function is called on the beginning of the delete event so I cannot add 
anything before.

If you can create any function that open e.g. modal UI dialog and syncronously 
return true/false you cna inject it into this function and it will work.

Regards,
Jovan

Original comment by joc...@gmail.com on 2 Jun 2011 at 8:36

@GoogleCodeExporter
Copy link
Author

Thanks for the reply.

To my knowledge, other than the one built into the browser, there are no other 
truly synchronous dialogs.

The 'modal' ones from jquery-ui are still asynchronous and operate off of 
callbacks.
This means that even tho they are modal and prevent users from acessing other 
parts of the page while being shown, they don't pause the javascript at that 
point. They open the dialog, and return immediately. 


Haven't fully thought this out.. but would this work.
When the delete button is pressed, you still fire off a method that calls us 
(just like the fnOnDeleting). It will pass the tr, id, but also a function that 
we are to execute on someone clicking OK.

That function is really just a handle to _fnOnRowDelete.

We then will make the call to that depending on ok/cancel.. etc.. 

At that point you can remove this line from _fnOnRowDelete:
if (properties.fnOnDeleting($('tr.' + properties.sSelectedRowClass, oTable), 
id)) {

The only thing you have to figure out is how to gracefully degrade (if someone 
doesn't want to provide their own custom dialog).. 

-k

Original comment by kenneth....@gmail.com on 2 Jun 2011 at 9:07

@GoogleCodeExporter
Copy link
Author

i did the change and it works just fine.. 

in your code i make fnOnDeleting take the next couple of lines as a callback:

        //Called when user deletes a row
        function _fnOnRowDelete(event) {
            iDisplayStart = _fnGetDisplayStart();
            if ($('tr.' + properties.sSelectedRowClass + ' td', oTable).length == 0) {
                //oDeleteRowButton.attr("disabled", "true");
                _fnDisableDeleteButton();
                return;
            }
            var id = fnGetCellID($('tr.' + properties.sSelectedRowClass + ' td', oTable)[0]);
            properties.fnOnDeleting($('tr.' + properties.sSelectedRowClass, oTable), id, function (){ 
                properties.fnStartProcessingMode();
                $.ajax({ 'url': properties.sDeleteURL,
                    'type': properties.sDeleteHttpMethod,
                    'data': 'id=' + id,
                    "success": _fnOnRowDeleted,
                    "dataType": "text",
                    "error": function (response) {
                        properties.fnEndProcessingMode();
                        properties.fnShowError(response.responseText, "delete");
                        properties.fnOnDeleted("failure");

                    }
                });                 

                }
            );
        }


In our code (already have a dialog created earlier in the code, not shown here 
for brevity) i use the fnOnDeleting to dynamically set the buttons, the "Delete 
Service" is now set to call your code, and then i open the dialog:

            }).makeEditable({
                sUpdateURL: "updateServiceName.htm",
                sAddURL: "addServiceName.htm",
                sDeleteURL: "deleteServiceName.htm",
                sDeleteRowButtonId: "deleteServiceButton",
                fnOnDeleting : function (tr, id, deleteCallback) { 
                        $deleteServiceDialog.dialog("option", "buttons",
                        {
                        "Delete Service": function() {
                            deleteCallback();
                            $( this ).dialog( "close" );
                        },
                        Cancel: function() {
                            $( this ).dialog( "close" );
                        }
                    }
                );
                $deleteServiceDialog.dialog('open');

                },


Hopefully that helps illustrate what I was getting at... 

Original comment by kenneth....@gmail.com on 2 Jun 2011 at 9:35

@GoogleCodeExporter
Copy link
Author

Ok,

That makes sense. Please take the version 1.2.4 and see how this is implemented 
in the 
http://jquery-datatables-editable.googlecode.com/svn/trunk/custom-messages.html 
page.

Regards,
Jovan 

Original comment by joc...@gmail.com on 2 Jun 2011 at 9:43

@GoogleCodeExporter
Copy link
Author

Yep.. that works like a champ.

You can update your custom-messages page to remove the return false;
It is unecessary.
By default fnOnDeleting will return undefined, which evaluates to false and 
thus you don't get a second call to _fnDeleteRow.

                    fnOnDeleting: function (tr, id, fnDeleteRow) {
                        jConfirm('Please confirm that you want to delete row with id ' + id, 'Confirm Delete', function (r) {
                            if (r) {
                                fnDeleteRow(id);
                            }
                        });
//                        return false;   <-- safe to strike this one out.
                    }


Thanks again for your quick responses.. nice to see someone dedicated to their 
projects.

-k

Original comment by kenneth....@gmail.com on 2 Jun 2011 at 11:56

@GoogleCodeExporter
Copy link
Author

Thanks for your suggestion now it really looks better.

returning false instead of default - yes you are right but this is a 
programming style. I don't like to rely on default behaviour/conversion (too 
much bugs appear in that case). Therefore, I always like to explicitly return a 
value what is expected but you are right it will work in both cases.

I'm closing this issue.

Original comment by joc...@gmail.com on 3 Jun 2011 at 5:55

  • Changed state: Fixed
  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

@GoogleCodeExporter
Copy link
Author

Completely understand you logic.

-k

explicitly

Original comment by kenneth....@gmail.com on 3 Jun 2011 at 6:03

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