Hi All, I got chirping crickets when I asked this question a few days ago, (except for one person sending me private mail telling me it sounds like a good idea in general) so let me try again... I'll also post a copy of this at http://trac-hacks.org/wiki/stevegt, and once the dust settles and I have a patch I'll enter that as a ticket @ edgewall.
== Wiki Edit Workflow Proposal == As wiki SPAM gets worse, as people start using trac for more critical projects, and as I develop the plugin that implements my evil master plan for world domination, there's going to need to be a lightweight, trac-ish way of allowing plugins to do page edit workflow. I have that need right now. I want to tackle this, I plan to post the result on trac-hacks.org, but before I spend a lot of time going down a development path, I think I should get some advice as to which path I should take; it's looking more and more like trac itself will need to be patched, and I'd prefer to do this in a way that the patch will likely be accepted into mainstream. There appear to be (at least) two parts to this problem: (1) The default viewable version of a wiki page needs to be selectable via an extension point, not hardcoded as "highest version number", and (2) the version of the page which a user edits when they hit "Edit This Page" needs to be configurable, rather than "most recent". I'm starting to think that (1) is going to require a change to the WikiPage class, and (2) a change to WikiModule. In WikiPage, if version number is None then the default action is determined by the ORDER BY sorting in a SELECT statement. I see three choices here: - patch WikiPage to add an IWikiPageVersionSelector extension point (called before SELECT); this helps anyone implementing workflow - patch WikiModule to add an IWikiPageProvider extension point; then WikiPage implements IWikiPageProvider; this helps anyone using alternate wiki page storage and/or workflow - don't patch the code; just have my own plugin do the job via overriding and subclassing WikiModule, reassigning the 'WikiPage' symbol at runtime, and/or other guerilla tactics; this helps nobody other than myself In WikiModule, right now an edit is hardcoded as "latest version" in process_request. But you'd actually want the "Edit This Page" button to edit the version you're looking at, or maybe the currently elected version, not the latest version. This probably needs a trac.ini configuration item to control it -- either another patch or another override. Does anyone have any preference as to which of these routes I take? Steve On Thu, Feb 23, 2006 at 08:38:11AM -0800, Steve Traugott wrote: > Hi All, > > Does anyone know how a plugin could gracefully override the > conventional wiki "last edit wins" behavior? Or am I going to have to > patch trac to get this? > > We're working on a plugin that, among other things, uses weighted > voting to decide which edit is actually the default rendered version. > We might also want the elected version to be the one that's brought up > in the edit page, and so on. Our reasons for doing this are many, and > I'm skipping a lot of detail, but one beneficial side-effect is > vandalism prevention. > > I can see how I might subclass WikiModule, have a new process_request > fix up the version number and then call WikiModule.process_request > directly, but that seems to violate the whole intent of the component > architecture, and I don't know if it's "right". > > The plugin development documentation and tutorials are excellent as > far as they go, they've helped a lot, and I like what I see in the > component architecture -- very nice. I have to think I'm still > missing something critical though, because I can't see how to do this > without completely overriding and subclassing the existing wiki > component. Searching back through the archives, and grepping the > trac-hacks.org SVN tree, I so far haven't been able to spot any > examples of other plugins that are doing anything like version number > munging. If anyone can provide pointers, I'd be forever in your debt. > > Steve > -- > Stephen G. Traugott (KG6HDQ) > UNIX/Linux Infrastructure Architect, TerraLuna LLC > [EMAIL PROTECTED] > http://www.stevegt.com -- http://Infrastructures.Org > _______________________________________________ > Trac mailing list > [email protected] > http://lists.edgewall.com/mailman/listinfo/trac -- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC [EMAIL PROTECTED] http://www.stevegt.com -- http://Infrastructures.Org _______________________________________________ Trac mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac
