> In this discussion, I think there are two capabilities that are not > being clearly distinguished. > > First, there's the ability to rename a single page. Second, there's > the ability when you rename a single page to have the system go find > all the references to that page and change them to refer to the newly > named page.
Good point. I agree that the latter ability is the one that creates the majority of the problems, since - as I said - it's a batch operation with little in the way of compensation. I.e. it's easy to update a lot of pages but not necessarily easy to "unupdate" them. > I'd like to challenge the folks on the list to be very clear about what > the problem is before we go off into solutions. Are there other > problems beyond the two that I've mentioned? If you want to get right down to it, one of the issues here is that rename is not a feature of the core. Rename is a feature of the web app. At the engine level, all that's happening is a bunch of deletes, creates, and updates. The fact that these are not atomic leads to the can't-undo problems we've mentioned. Additionally, renames aren't really renames because history doesn't travel with the new page. I'm not suggesting that we move to a solution that supports true rename in the core, although it would be nice. I can think of one interesting way to do it, but I'll refrain from mentioning it. :) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
