In TWiki:Plugins.EditContrib, I broke TWiki::UI::Edit::edit into the following components:

• edit does the heavy lifting, creating the body of the page. This is exactly a copy from TWiki::UI::Edit::edit sans the final code that assembles and writes the page.
• finalize_edit wraps up and writes the page. It is extended from the original code in that it is given the page in three pieces: a section before the text to be edited, a section after the text, and the portion of the topic that is being edited, which are assembled into the single edit topic.

(Actually I also factored out an init_edit that sets up the editing session and does all the checking for whether the edit should proceed, but that is not necessary.)

In various plugins, I call edit, then do some more processing, and finally call a finalize_edit to assemble and write out the page.

The bummer is that most of this just refactors code from lib/TWiki/UI/Edit.pm, and thus is going to have to change whenever that file changes.

I propose that we segment TWiki::UI::Edit::edit in this manner. This will allow plugin writers as well as the twiki core to reuse a single core editing functionality; their application will only differ in whether there is a pre or post section being passed to finalize_edit. The impact when doing standard editing is little: there are a few conditionals that check for the presence of the pre and post sections. Parameters are passed by reference, so there is no cost there.

Of course, the edit functions should then be exported in the FuncDotPm API...

I tried to think how we could do this with another plugin hook. This would also be feasible but a little more convoluted. That would be the second best choice.

I'll let that stew for a little and hope for feedback....

---

Incremental refactoring is fine, but I'm not sure I want to give plugins authors any more access to the nitty-gritty of editing than they get through the handlers. The whole flow is a mess, and needs to be reworked from top-to-to.

The problem is that if you publish the APIs, it locks down the flow, and it can never ever change again, so we'd better be sure it's right....

CC

Yeah, the problem of backwards comatibility. I am fine with not publishing any changes to the API. Just refactoring would be sufficient for me.

TW

---

Refactored as discussed into

sub edit {
    my $session = shift;
    my ( $text, $tmpl ) = init_edit( $session, 'edit' );
    finalize_edit ( $session, $text, $tmpl );
}

Checked in as 11593.

-- TW

There was a link to here from TWiki:Codev.WhatIsIn04x00. The code refactor is done and the larger future API proposal seems to be no longer pushed for. If this desire could come back API changes will require a formal discussion on Codev. I have maked this one as DONE in the TWiki:Codev.WhatIsIn04x00. There has been no objections to the checkin here or in the twiki-dev mailing list.

-- KJL

4.1.0 released

KJL