On Wed, Jul 10, 2013 at 9:51 AM, Juan Pablo Santos Rodríguez < [email protected]> wrote:
> Hi Ichiro, > > I'm definitely interested, and will be glad to help with whatever I can > Hi Juan Pablo, That'd be great, thanks! > 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 haven't looked over the existing proposals, will take a look at JSPWIKI-155. I'll have to look into what benefits there might be in having the EntityManager either in or out of WikiEngine. I was thinking it might be the *only* getter method from WikiEngine (apart from the deprecated get*Manager() methods). > 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. > I've done something similar to this in a recent project and it just seems like something that might have other possible uses (e.g., as a general purpose name-value pair storage). This raises the idea of having a parameter option to permit some entities to be persisted across sessions, or used across instances, things like that. > 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 > We could, but my only concern is that we'd then be overloading the use of classmappings.xml, especially given their purposes are different. I'd really advocate a new XML file with a new syntax. Then there'd be no potential for pollution. > - 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. Hmm. Under what circumstances would the EntityManager permit a failure? I'd think all of them would be mandatory. One thing I had thought of might be permitting (via parameter) lazy instantiation though. Not everything needs to be there right at the beginning -- the EntityManager could create managers only when needed then, i.e., upon first request. Cheers, Ichiro rgrds, > juan pablo > > On Tue, Jul 9, 2013 at 10:52 AM, Ichiro Furusato > <[email protected]>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 > > >
