diff options
Diffstat (limited to 'doc/todo/need_global_renamepage_hook.mdwn')
| -rw-r--r-- | doc/todo/need_global_renamepage_hook.mdwn | 48 |
1 files changed, 44 insertions, 4 deletions
diff --git a/doc/todo/need_global_renamepage_hook.mdwn b/doc/todo/need_global_renamepage_hook.mdwn index ce55b42c3..9c987aac4 100644 --- a/doc/todo/need_global_renamepage_hook.mdwn +++ b/doc/todo/need_global_renamepage_hook.mdwn @@ -58,8 +58,48 @@ would solve my problem. Hmmm? --[[intrigeri]] >>> As Joey highlights it on [[plugins/contrib/po]], it's too late to >>> merge such a change, as the 3.x plugin API is released and should ->>> not be broken. I'm thus proposing to keep the existing ->>> `renamepage` as it is, and call `rename` the global hook I need. ->>> --[[intrigeri]] +>>> not be broken. I will thus keep the existing `renamepage` as it +>>> is, and call `rename` the global hook I need. --[[intrigeri]] -[[done]] as part of po branch +>>>> Done in my `po` branch. --[[intrigeri]] + +I think I see a problem in the rename hook. The hook is called +before the plugin adds any subpages to the set of pages to rename. +So, if the user choses to rename subpages, po will not notice +they are moving, and will not move their po files. + +Perhaps the hooks should be moved to come after subpages are added. +This would, though, mean that if the hook somehow decides to add +entirely other pages to the list, their subpages would not be +automatically added. + +I also have some qualms about the design of the hook. In particular, +passing the mutable array reference probably makes it impossible +to use from external plugins. Instead it could return any additional +rename hashes it wants to add. Or, if the ability to modify existing +hashes is desired, it could return the full set of hashes. + +--[[Joey]] + +> I fixed the last part, i.e. a rename hook function now returns the +> full set of hashes. As I also converted it to take named parameters, +> such a function still is passed a reference to the original array, +> though, because one can't build a hash containing an array of hashes +> as a value, without passing this array as a reference. +> +>> Sure. +> +> I'm not entirely sure about your first concern. Calling the hook +> before or after the subpages addition both have their own problems. +> +> What about running the hook before *and* after the subpages +> addition, with an additional `when` named parameter, so that +> a given hook function can choose to act only before or after, or both? +> +> --[[intrigeri]] +>> +>> Have you thought about making the hook be run once *per* file that is +>> selected to be renamed? This would even handle the case where two +>> plugins use the hook; plugin A would see when plugin B adds a new file +>> to be renamed. And the subpage renaming stuff could probably be moved +>> into the rename hook too. --[[Joey]] |