incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <>
Subject Re: svn commit: r770959 [2/2] - in /incubator/jspwiki/trunk: ./ src/java/org/apache/wiki/ src/java/org/apache/wiki/action/ src/java/org/apache/wiki/api/ src/java/org/apache/wiki/auth/ src/java/org/apache/wiki/content/ src/java/org/apache/wiki/event/
Date Sat, 02 May 2009 21:35:09 GMT

On May 2, 2009, at 20:10 , Andrew Jaquith wrote:

> As for page renaming -- this seems like it should really be just a
> specific application of the more general case of JCR node renaming.
> Logically, the node-renaming code should live in ContentManager, no?

Well, logically, *everything* should reside in ContentManager.  
However, I really detest the fact that it's got internal classes and  
dozens and dozens of methods, and it's simply becoming unwieldy -  
exactly the reason I wanted to move away from PageManager and  
AttachmentManager in the first place!  I would be thinking of ways to  
tear down the class as much as possible, if I had any energy to code  
right now.

I'm thinking this from the code maintenance point of view, not from  
what-goes-where point of view. Page renaming is a fairly  
straightforward functionality which is why it makes sense to keep it  
out of ContentManager, the same as search and references.

> would be smaller and lighter. The page-renaming code (currently parked
> in ContentManager) has already gotten slimmer because of the movement
> of re-indexing and re-referencing code into the listener methods of
> SearchManager and ReferenceManager.

But this does not come from the integration, since any class can  
listen to notifications. Simplification would be true for a separate  
PageRenamer as well.

> That said, I am not really convinced we need a separate PageRenamer
> class. It's called from exactly one place, RenameActionBean. If we had
> a decent JCR "prototype method" for renaming nodes in ContentManager
> that does most of the heavy lifting, we could just do it fairly
> directly.

JCR does not care about the content of the pages. JSPWiki renaming  
functionality *does*. This is why it needs to be treated above the JCR  

JCR has a fairly straightforward method "Workspace.move()" which takes  
care of all the JCR specifics. It's a matter of taste whether that  
method is called from ContentManager or PageRenamer, but it should not  
be public.


View raw message