Not sure how putting responsibilities for saving something in the persistence manager is an "antipattern."
We use manager classes to get (look up) nodes; rename and move nodes (e.g., via PageRenamer); and to delete nodes. Should WikiPage implementations all be required to implement these actions too? No -- I think we agree that we need a manager class to get pages, and to delete them, and to rename them. Why would saving be any different? So, that's my theoretical counter-argument. Practically speaking, here's another one. Saving is better done in ContentManager because we must fire events to signify a successful save, same as we do for delete/rename events. We should not assume implementations of WikiPage will get this right. I suppose it would be easy enough to say, by contract, "all implementing classes must fire ContentEvent.NODE_SAVED (with the following parameters...)". But what if we added, say, a NODE_SAVE_REQUEST event later -- so that listeners could do something before the save happens? Implementors would then be required to get that right, too. Andrew On Mon, May 11, 2009 at 1:46 AM, Janne Jalkanen <[email protected]> wrote: >> >> - att.save(); >> + engine.getContentManager().save( att ); > > Funny. I developed WikiPage.save() just so that we would get rid of this > antipattern of calling a Manager to save content. Why would we want to > bring it back? > > /Janne >
