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 level.
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.
/Janne
