[jira] [Resolved] (JSPWIKI-806) EntityManager Proposal

["Juan Pablo Santos Rodríguez (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JSPWIKI-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juan Pablo Santos Rodríguez resolved JSPWIKI-806.
-------------------------------------------------
    Fix Version/s: 2.11.0-M7
       Resolution: Fixed

Done on 2.11.0-M7-git-16, the refactor at JSPWIKI-120 allowed to register custom managers on the {{WikiEngine}} pretty easily:

* {{WikiEngine}} will look on classpath for an {{ini/classmappings-extra.xml}} file, which has the same structure as the {{ini/classmappings.xml}} file
* If the {{ini/classmappings-extra.xml}} file is found, the {{Engine}} will register each {{requestedClass}} with its correspondent {{mappedClass}}, and thus making it accesible through the {{Engine#getManager( Class<?> )}} method
* The custom manager *must* have a no-arg constructor
* If there's a need to perform some initialization tasks involving the {{Engine}}, the custom manager should implement {{o.a.w.api.engine.Initializable}} and perform those tasks there
* The classes don't get registered in any particular order, as we're iterating the contents of a {{Map}}
* As with "official" managers, if there are two {{requestedClass}} entries with the same {{mappedClass}}, the last getting registered overwrites the other(s)
* Access to the entity is controlled through its access modifiers (the {{Engine}} must be able to "see" it, though)

As the goal of this issue was to register custom managers, I'm setting it as Resolved, please reopen if anything else is needed.

> EntityManager Proposal
> ----------------------
>
>                 Key: JSPWIKI-806
>                 URL: https://issues.apache.org/jira/browse/JSPWIKI-806
>             Project: JSPWiki
>          Issue Type: Improvement
>          Components: Core &amp; storage
>            Reporter: Juan Pablo Santos Rodríguez
>            Priority: Major
>             Fix For: 2.11.0-M7
>
>         Attachments: jspwiki-war-newApi-20131211.tar.gz
>
>
> Taken from http://s.apache.org/wS:
> {quote}
> \[...]
> 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.
> \[...]
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)