Hi Ichiro, nothing really disruptive, but I'd like to make the following changes:
- WikiEngine returning interfaces instead of concrete Managers. May rename concrete maangers along the way, e.g.: PluginManager becoming DefaultPluginManager implements PluginManager - Delete org.apache.wiki.WikiException in favour of org.apache.wiki.api.WikiException - Creation of an API module to hold Manager interfaces, general exceptions and WikiEngine + WikiContext, once they aren't coupled to concrete classes - Most probably WikiEngine should be passed as an interface (WikiEngine implements Engine?); same for WikiContext. This can/could/should be done as EntityManager takes shape However I'm afraid I can't give you a timeline for these; I'll expect to begin next week, creating an api module with a few classes, an utils module, again with a few classes and a filter module, holding all WikiFilters related stuff br, juan pablo On Thu, Jul 11, 2013 at 11:35 AM, Ichiro Furusato <[email protected] > wrote: > Hi, > > I just have one further question prior to diving into this: is anyone > out there actually modifying or substituting any of JSPWiki's > primary managers? If so, I'd like to hear about it (offlist if you > wish) so that I can be sure that what I'm doing is compatible with > what you're doing (if it's not too outlandish). > > As was suggested, I've read over JSPWIKI-155 and I think the > solution I've proposed will probably work in at least the 80/20 > case, just not sure about the 90/10 until I hear from someone out > on that limb. > > If I don't hear from anyone I'll assume that so long as the result is > internally consistent I'll have some freedom to tear the living sh*t > out of the insides of WikiEngine. At this point this whole thing is > somewhat of an experiment anyway, but it might pan out. > > Ichiro > > > On Thu, Jul 11, 2013 at 1:23 AM, Ichiro Furusato > <[email protected]>wrote: > > > > > > > > > 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 > >> > > >> > > > > >
