Hi,
I'm in the middle of working through some new manager classes as a
supplement to JSPWiki. These managers will be singletons similar to
the dozen or so existing managers that get instantiated in the method
WikiEngine.initialize(), such as the PageManager, PluginManager, etc.
The following is *not* a commitment to work, it is an offer to share the
results if I'm able to (a) find the time to finish it; and (b) I can make it
work; and (c) people are interested. I'm seeking feedback about the
proposed design. I'm not currently a team member but I could pass the
code or patches on to someone to check in if necessary.
What I'm considering is potentially a solution to the note in that method
concerning the "unwieldy" nature of the current approach of building the
WikiEngine's managers, namely a new EntityManager that would
sequentially create all the current managers according to a configuration
file, such that each manager (entity) could then be referred to by name.
This would also permit additional entities (like my new manager) to be
added and subsequently referred to by name.
The only thing one would need to gain access to the EntityManager would
be the WikiEngine itself -- all other managers would therefore be available
by name and all of the existing getter methods could be deprecated and
eventually the WikiEngine would therefore be simplified. The WikiEngine
would spawn a singleton EntityManager and then let it handle access to
those entities.
The configuration for the EntityManager would be an XML file, where
each individual entity configuration would include the following parameters:
* identifier (package name) of the entity
* boot order parameter (1-n) OR order in file is used.
* boolean stating whether the entity can be modified/replaced
once created
* access modifiers suggesting permitted access to the entity:
'private' : only to the WikiEngine itself
'protected' : only to org.apache.wiki.* code
'public' : open access
[not sure how to do this but could get some advice from one of
the team's security experts]
* anything else?
This would obviously involve a substantial rewiring of the engine and
current managers, as they tend to gain access to each other via the
WikiEngine, hence the idea of deprecating the existing methods in
WikiEngine (and implementing their current getters via the EntityManager)
rather than eliminating them outright. Once done though, this would
greatly simplify the WikiEngine itself. It basically would have a new
bootstrap manager.
To give you an idea of what problem I'm trying to solve, we're currently
developing an updated TagManager based on Murray Altheim's existing
TagPlugin (and related features) to provide a tagging solution for
JSPWiki, as well as a GroovyService to provide a wiki-related Groovy
scripting solution, supporting an update to our older GroovyPlugin but
also permitting a wiki page-based command console (obviously not for
use on public wikis). You'd have a on-page form as a console drawing
upon a 'bin' directory of Groovy scripts, basically a file-based DSL over
Groovy command line functionality. So you could write a HelloWorld.grv
file, put it in the WEB-INF/bin directory and be able to type 'HelloWorld'
into the console command line. That kind of thing. We have this mostly
working already so this is basically a way to add a new manager
without either adding a getter to the WikiEngine or gaining access via
some singleton trickery.
If this sounds palatable to the group I'll go ahead and begin coding in
mind of it being a public effort (with appropriate Apache license headers
in the files, etc.), otherwise I'll build it as an addon for our own local
use.
I would like to know one question if I do begin: should I simply work on
the trunk or would this be better as a branch? If so I'd need someone to
create that branch.
If I end up running out of steam I might want some help, particularly on
the security-related stuff since that's not my forte. If anyone is up for
helping in this regard please let me know.
Cheers,
Ichiro
