Hi,
I've been playing around with WikiPage objects lately and noted that
the constructor includes the parent WikiEngine. This has been true so
far as I know for the life of the project. The JSPWiki isn't particularly
clean in this regard so this would be (IMO) categorised as an API
cleanup.
I'd like to modify the WikiPage class so that we can create them
without a WikiEngine dependency. They are then more portable and
can be created, stored, transferred, etc. without regard to their parent
wiki. There isn't much of a logical reason for a WikiPage to know about
its wiki so this seems like a good idea.
Looking a bit more closely it's clear that the WikiEngine argument is
only used for two things:
1. the application name is used to differentiate wiki pages for
use in permissions.
2. the WikiEngine provides a PageSorter to permit WikiPages
to be sorted according to a property-configured sort algorithm.
Neither are compelling as a reason for this dependency, particularly
if there is only one JSPWiki instance running in a given JVM. Earlier
versions of Tomcat used to host multiple webapps/wikis in the same
memory space, but that's not true any longer, i.e., wikis can't interact
directly.
So I'm curious to know of anyone using multiple wikis in the same JVM.
I can't think of a scenario but there certainly may be some out there.
If that's *not* the case then reason #1 goes out the door. Reason #2
is a relatively simple fix, as if there is only one wiki per JVM we can set
the PageSorter as a static variable on WikiPage. That's effectively what's
happening with the WikiPage requesting the singleton PageSorter from
the WikiEngine so there'd be no effective difference.
I've already done the coding for this in a local copy of JSPWiki -- it's
not particularly difficult. I'd deprecate the current constructor that
includes
the WikiEngine rather than eliminate it, as it is used in a lot of places.
Pros? Cons? Thanks for any.
Ichiro
