You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the afteRemove callback is, quite non-intuitively, called even if the users denies removal via confirm(), and the callback provides no way of telling the client whether or not the element was REALLY removed. This makes it impossible to, e.g., post an AJAX delete-resource request based on the afterRemove callbacking being called (which is what we are trying to do).
To work around this we locally hacked the afterRemove-calling code to pass a second parameter, a boolean telling us whether or not the remove actually happened. This is, however, IMO, not a real solution. IMO the afterRemove should not be called unless something is actually removed.
The text was updated successfully, but these errors were encountered:
the afteRemove callback is, quite non-intuitively, called even if the users denies removal via confirm(), and the callback provides no way of telling the client whether or not the element was REALLY removed. This makes it impossible to, e.g., post an AJAX delete-resource request based on the afterRemove callbacking being called (which is what we are trying to do).
To work around this we locally hacked the afterRemove-calling code to pass a second parameter, a boolean telling us whether or not the remove actually happened. This is, however, IMO, not a real solution. IMO the afterRemove should not be called unless something is actually removed.
The text was updated successfully, but these errors were encountered: