Hi Ichiro, I'm definitely interested, and will be glad to help with whatever I can.
One of the ideas behind JSPWIKI-155 is doing more or less the same thing, but without a separate class, i.e.: regarding the EntityManager, why not moving it into WikiEngine (thinking in WikiEngine as an already ubiquitous class that will be returning interfaces and thus not carrying the whole application from one manager to another)? I specially like the idea of getting a (maybe new) manager from WikiEngine without declaring an specific method for it, it's very interesting, and the idea of processing the Managers from a configuration file rather than explicitly instantiating (through ClassUtil.getMappedObject, but doing that explicitly) them. Finally, a couple of notes/questions regarding the EntityManager - could classmappings.xml be the config file for the EntityManager (whether it becomes a new class or just a refactored WikiEngine)? We could add parameters as needed - I would "include" a mandatory field for each Manager. If it's mandatory, the WikiEngine cannot initialize, and the application doesn't start. If it isn't, the error is simply logged. rgrds, juan pablo On Tue, Jul 9, 2013 at 10:52 AM, Ichiro Furusato <ichiro.furus...@gmail.com>wrote: > 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 >
