morebits: pass api object to failure handlers wherever possible #679
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Presently, the morebits.wiki.page object is passed to the failure handler. But this object is of no use as it contains no information about the error. The morebits.wiki.api object is more useful as it carries the errorCode and errorText properties, and can thus be used to determine the error and produce a customised error message. Also, the page object still remains accessible as it is the parent attribute of the api object. (While the api object is not accessible from the page object.) The success callback continues to take the page object as parameter. This is probably desired for the success callback to allow additional processing with the page after save. This change does not break anything in Twinkle.
…acks Give the apiobj as the parameter to the failure handler on all types of errors (except, of course, when the error is handled before any API calls take place), rather than doing the mix of giving the pageobj on some errors and apiobj on some errors. L2856 - `ctx.onDeleteFailure.call(this, this, ctx.deleteProcessApi);` was most probably a typo, as it passes two arguments to the fail callback, which is not done anywhere else. Remove `if (ctx.onDeleteFailure)` checks since these will always evaluate to true, as `ctx.onDelelteFailure` fallbacks to an empty function (L2301) if not given by user.
Use moveApi object as parameter to the `ctx.onMoveFailure` if issue is detected after moveApi stage. The moveProcessApi object is already being passed to `ctx.onMoveSuccess` and `ctx.onMoveFailure` when the move succeeds or when moveProcessApi is failing.
Same changes as done with move function. When an issue is detected after protectApi, pass protectApi object to failure callback. When protection succeeds or protectProcessApi fails, the protectProcessApi object is already being passed to the success/failure callbacks.
…backs Similar to what is done in morebits.wiki.page.deletePage().
None of fnProcessDelete, fnProcessUndelete, or fnDoneOne take an argument.
siddharthvp
changed the title
This was referenced Dec 4, 2019
|
Closing in favour of a superior solution described in #783. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pass the
morebits.wiki.apiobject (rather than themorebits.wiki.pageobject) to the failure callbacks wherever possible, except where the error is being handled before any API calls are made (such as when trying to protect without being admin or without setting the protection settings). The apiobj is more useful since it has theerrorCode, using which the client script may choose to show customised error messages. The pageobj is anyway still accessible as it is set as theparentattribute of apiobj in all usages.Regarding the success callbacks,
save()is currently giving the pageobj (useful to allow further processing with the page) while the other functions are giving the apiobj. No changes made here.See individual commit messages for more details.
This does not break any existing code.