Tags:
development1Add my vote for this tag plugin1Add my vote for this tag create new tag
, view all tags

Feature Proposal: Add Rename Handler for Content Move

Motivation

As of Dakar, each plugin has its own work area. Some Plugins (for example TagMePlugin) manage a database of topics and associated data, thus moving it out of band. To support this, however, we need a new handler to notify Plugins when a topic or attachment has been renamed or moved, so that the out of band database can be kept in sync.

Description and Documentation

A Plugin that keeps web/topic/attachment specific data needs to be notified if a web, topic or attachments ares renamed.

A new handler is proposed to inform Plugins of content rename/move:

afterRenameHandler( $fromWeb, $fromTopic, $fromAttachment, $toWeb, $toTopic, $toAttachment )

Impact and Available Solutions

Implementation

-- Contributors: PeterThoeny, MeredithLesly

Discussion

another possiblilty is that a plugin might need to be able to veto the move for some reason.

-- SvenDowideit - 27 Feb 2006

TopicRenamedHandler would deal with search/goto

-- MartinCleaver - 28 Feb 2006

This is an excellent idea. The same handler would be useful for WebDAVPlugin as well.

-- CrawfordCurrie - 05 Jun 2006

I don't like the name: you are not detecting a MOVE of CONTENT, but rather if the topic has been renamed.

-- MartinCleaver - 23 Jul 2006

I see your point. I chose "content" instead of "topic" because it is for topic move and attachment move. We could name it topicOrAttachmentMovedHandler, but contentMovedHandler is shorter. Idea for a better name?

-- PeterThoeny - 24 Jul 2006

Seems there are no voices against implementing the feature. Only debate is what to call the handler.

All this needs now is an owner committed to implement it. Is this going to be a 4.1 item or is it 4.2. If no committed owner it is 4.2

-- KennethLavrsen - 27 Sep 2006

i don't think you need a handler for this.

package TWiki::Plugins::NosePlugin;

use vars qw($startWeb $startTopic);

sub initPlugin {
    my ($web, $topic....) = @_;
    $startWeb = $web;
    $startTopic = $topic;
}

sub afterSaveHandler {
    my ($text, $endtopic, $endweb...) = @_;
    my $context = TWiki::Func::getContext();

    if ($context->{rename}) {
       ... then this is a content move...
    }
}
ought to work (untested).

-- CrawfordCurrie - 02 Oct 2006

Thanks Crawford, I will try this out in the TagMePlugin. I wish I knew that at the time of the heated discussions on the TagMePlugin limitations.

I do not find the rename context that intuitive from an educational perspective. "OK, so my plugin needs to know of topic renames. Let me consult the API documentation. Hmm, there is an API call to rename content, but I do not see a callback to get notified of a topic rename. I guess TWiki does not supported that." If we documemnt the rename context in the afterSaveHandler callback, it is unlikely that a developer will look for that information there.

-- PeterThoeny - 02 Oct 2006

How do I get at the original name before the rename? Is that the name during initPlugin? To avoid race condition, is the original name available in the afterSaveHandler callback?

-- PeterThoeny - 02 Oct 2006

The rename context test did not work, but a simple "$oldWeb.$oldTopic" ne "$newWeb.$newTopic" does.

I am concerned though that there is a race condition in a mod_perl environment since the old web & topic names are stored in global variables.

A proper solution (also for educational purposes) is to implement a plugin handler for content move.

-- PeterThoeny - 03 Oct 2006

The "rename" context is set whenever the "rename" script is run. Each top level CGI script sets a context the same as the name of the script, as described in IfStatements. Since rename is the only entry point to renaming a topic, then the context id is the most reliable way to tell you are renaming. If we ever add an API to support topic renames, then the context would also be set in that API. This is not a common requirement, and documenting this approach in a cookbook is a lot more efficient than adding yet another handler.

There is no risk of a race condition. mod_perl processes do not share address spaces, so there is no spill-over of gloabl variables between processes. The mod_perl "problem" is that global variables persist between runs in the same process. Since initPlugin is used to initialise the variables for each run, there is no risk.

-- CrawfordCurrie - 03 Oct 2006

Thanks for the clarification on the race condition.

For now I will keep the web.topic name compare in the TagMePlugin since the rename context did not work, e.g. it was not set in afterSaveHandler.

Adding this handler has now a lower priority for me, but I think we better add it to make it easy for plugin authors. The plugin performance issue with many handlers can be addressed if we RegisterHandlersInInitPlugin.

-- PeterThoeny - 03 Oct 2006

If the current set of handlers with the contexts like rename can do the job, then I would assume adding another handler just for the fun of it should be considered very carefully.

I sense the best for the community would be if Crawford shows Peter and the rest of us how the actual code sniplet should look like to make it work.

It seems the TagMePlugin now has a feature coded that could have been implemented with this rename context - according to Crawford. How about pasting in the code that would work?

If it works the "business case" for the new handler will be very weak. And if it cannot be made to work, then the case is strong for the new handler.

-- KennethLavrsen - 11 Oct 2006

I think we need this handler in order to make the API clean and educational. And after all, we decised already to implement this feature.

I did hack in the TagMePlugin to make it work: The context did not work, so I simply compare the web.topic of initPlugin and afterSaveHandler callback, with a special case to discard rename of WebHome since the statistics script initializes as WebHome but saves as WebStatistics. This is a crude hack, but at least the plugin is now aware of topic renames...

-- PeterThoeny - 12 Oct 2006

The last action from the release meeting was.

"Crawford Currie: Propose how to avoid new handler in PluginHandlerForContentMove."

There was no vote, no decision because you needed to continue the discussion on this topic. And I am trying to get the discussion finished so we can take a vote at next release meeting and get this accepted or rejected.

Note: I am not against this proposal. I am just filling my role as customer advocate as defined in TWikiRelease04x01Process ensuring that a proper decision is made which everybody will have to respect once it is taken.

-- KennethLavrsen - 12 Oct 2006

I understand your role on customer advocate. Here is the timeline on the process and on this proposal as seen in the WhatIsIn04x01 history:

  • 19 Jul 2006: PTh proposes the feature
  • 14 Aug 2006: TWikiRelease04x01Process is decided at EdinburghReleaseMeeting2006x08x14
  • 28 Aug 2006: Two week grace period after establishing process
  • 27 Sep 2006: KJL changes it to "accepted"
  • 05 Oct 2006: KJL reverted to "under disussions" because an alternative is discovered
  • 12 Oct 2006: PTh changed it back to "accepted"
  • 12 Oct 2006: KJL reverted to "under disussions"

I am listing this to point out that I was merely following our agreed on process by changed it back to "accepted": The proposed feature was implicitly accepted on 28 Aug 2006 (e.g. nobody raised a concern for two weeks (actually much longer than that)), and formally listed as such on 27 Sep 2006. If someone had implemented it after 28 Aug 2006 it would be a done deal. A concern was raised on 05 Oct 2006, almost 6 weeks after acceptance.

-- PeterThoeny - 12 Oct 2006

I have added a comment on TWikiRelease04x01Process about the process as such.

I do not think it was very clear to all that this proposal was a topic under the new 14 day rule. It is only a few days ago that we agreed that it is topics in WhatIsIn04x01 that follow the new policy - while we wait for the TWiki Application for the process to be finished. And there was never a clear announcement about the new process.

This is why I added my statement the 27th of September to clarify the acceptance status of this proposal to trigger any concerns. And Crawford then raised a concern. The 14 day period - which I support - I suggested it myself - is not there to enable people to sneak in features or horrorble non-compatible API changes. It is there to ensure that developers with a proposal and the will to implement it are not ignored to death.

As we get used to the new process - people will be more on the alert to get the concerns raised. But this is a proposal from before the new policy and I do not think it was clear to Crawford that this proposal would be accepted unless he said something, until I added my statement the 27 Sep 2006. It was not even clear to me.

When I answer the question: "What is best for TWiki, the community and the customers?" then the answer would be that we have the right people to think carefully about the impact - both pros and cons - and make the right decision.

I fear that someone is going to find some proposal from round August or before which changes TWiki API in a non-compatible way or adds new default plugins, that can count more than 14 days of silence and claim a decision is made.

I am not going to revert the state of this a 3rd time. But Crawford you can always raise a RevertDecisionPluginHandlerForContentMove on WhatIsIn04x01 and we can take a vote on that. I think it would be best for TWiki if Peter and Crawford discuss the handler on this topic till the impact of the feature and the alternatives are clear, and then the community can take a vote.

There ís currently no programmer ready to implement it anyway so I do not understand why you are against making a good discussion followed by a good community decision. As it looks now this feature would not be implemented until 4.2 anyway.

-- KennethLavrsen - 12 Oct 2006

Just for clarification. I am against the approach of adding handlers to solve one-off problems in plugins, as it has caused me much pain in the past. The mess created when support for SessionPlugin was hacked in has been a nightmare to deal with. I prefer consistent and well thought out approaches, such as ensuring there is a handler for each end of each major operation, to hacking in one-off solutions for specific plugins. I do not see that level of thought in this proposal, and for that reason alone I am against it. Why is the proposal for contentMovedHandler when every other similar handler is named afterOperationHandler? Where is the beforeContentMove handler? The before/afterAttachmentMove handlers?

-- CrawfordCurrie - 13 Oct 2006

I raised my concern on not following the two week garce period rule in TWikiRelease04x01Process and will leave it with that. Having said that, I am open to revisiting the decision of having this feature accepted.

Not sure how the session handling example applies to this atomic TWiki function here.

  • Rename is an essential part of TWiki (as in any content management system)
  • TWiki is integrated with other systems, they need to be made aware of content changes
  • Plugins need to be made aware of content changes (Crawford stated on 05 Jun 2006 that "this is an excellent idea. The same handler would be useful for WebDAVPlugin as well.")

So, content rename is not a special case for one plugin.

Good point on handler name. To make it consistent with the script names and to plan for a future handler that could intervene on a content rename I changed the handler name from contentMovedHandler to afterRenameHandler.

-- PeterThoeny - 13 Oct 2006

Where is the beforeContentMove handler? The before/afterAttachmentMove handlers? If you don't consider these handlers as well, you are treating this as a special case.

-- CrawfordCurrie - 14 Oct 2006

One step at a time. If you look carefully enough at the proposed interface, this is a handler for topics and attachments.

-- PeterThoeny - 15 Oct 2006

Back to the issue and getting on track again.

Crawford provided the needed code snippet for Peter's TagMePlugin.

Detecting the rename context plus checking source and target topics by comparing names given to initPlugin and afterSaveHander should really do the job.

Peter tried it but said it failed. Why? Can we continue here. Even better: close this proposal and move the discussion to TagMePluginDev.

-- MichaelDaum - 16 Oct 2006

This is not a TagMe discussion. Peter proposes a new afterRenameHandler.

It is relevant to argue against it if we already have the means to do the same in existing handlers. And it is relevant to argue for it if the current handlers do not provide the needed functionality.

I think this discussion flows better if both parties give examples of both use and code that supports both viewpoints.

-- KennethLavrsen - 16 Oct 2006

If any work on this one is going to get into 4.1 then we need this discussion to get to some sort of conclusion so we can vote for it at a release meeting. If we take it to the meeting as it is - a majority will not know what they vote for. If this moves nowhere it ends in the parking lot for 4.2.

-- KennethLavrsen - 06 Nov 2006

This is now implemented: Bugs:Item3157, SVN 11992.

-- PeterThoeny - 16 Nov 2006

Edit | Attach | Watch | Print version | History: r36 < r35 < r34 < r33 < r32 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r36 - 2006-11-16 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.