incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <>
Subject Re: svn commit: r773455 - in /incubator/jspwiki/trunk: ./ src/java/org/apache/wiki/ src/java/org/apache/wiki/api/ src/java/org/apache/wiki/content/ src/java/org/apache/wiki/parser/ src/java/org/apache/wiki/plugin/ src/java/org/apache/wiki/search/ src
Date Mon, 11 May 2009 13:06:07 GMT
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.


On Mon, May 11, 2009 at 1:46 AM, Janne Jalkanen
<> wrote:
>> -  ;
>> +            engine.getContentManager().save( att );
> Funny. I developed 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

View raw message