incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ichiro Furusato <ichiro.furus...@gmail.com>
Subject Re: EntityManager proposal
Date Thu, 11 Jul 2013 09:35:06 GMT
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
<ichiro.furusato@gmail.com>wrote:

>
>
>
> On Wed, Jul 10, 2013 at 9:51 AM, Juan Pablo Santos Rodríguez <
> juanpablo.santos@gmail.com> 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
>> <ichiro.furusato@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
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message