I have recently refactored TWiki::UI::Edit::edit in a minor way to allow reuse of the edit routine from within plugins that want to edit part of the topic.

If one were to insert a new handler, say finalizeEditHandler before the edit page is written out, those plugins could do their job without having to call edit directly, making the API clean.

I have this written and tested, and wonder whether it would be prefered to have this code in rather than the simple refactoring. We don't need to publish the handler, but I would feel better if I would not have to call a core routine from the plugin.

Guidance requested... --TW

---

Every time we add a handler that assumes the algorithms employed in the core, we freeze the core code a bit more, making it more brittle and increasing the maintenance problems. I agree it's not good to call functions in the core, but adding handlers has the same effect in the long term.

If you had seen the trouble I have had maintaining ill-considered or poorly designed handlers and API functions in the past (I'm thinking of the code added specifically to support SessionPlugin here), you would share my concern.

Can you do two things:

1. State the spec of the proposed handler, detailing where and how it would be used (with an example)
2. Explain how two plugins that both support the handler would interact?

CC

Oh boy, you are right on (2). This handler would have to be invoked by only one plugin at a time. Maybe that is not quite the spirit of a plugin? Are there "exclusive plugins"? Should there be? -- TW

---

Yes, there are, for some handlers; that is one of the horriblenesses I had to deal with.

I don't think this should be classed as a bug, it is an issue that needs to be discussed in Codev before coming back here. So I created TWiki:Codev.AddFinalizeEditHandler, am reclassifying this as Enhancement and discarding it - please reopen if there is agreement.

CC