[
https://issues.apache.org/jira/browse/JSPWIKI-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066224#comment-17066224
]
ASF subversion and git services commented on JSPWIKI-806:
---------------------------------------------------------
Commit 3b8bb073fbc93d2bae83cb11acd1fdfd8f548484 in jspwiki's branch
refs/heads/master from juanpablo
[ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=3b8bb07 ]
Refactor WikiEngine initialization (somewhat related to JSPWIKI-806)
> EntityManager Proposal
> ----------------------
>
> Key: JSPWIKI-806
> URL: https://issues.apache.org/jira/browse/JSPWIKI-806
> Project: JSPWiki
> Issue Type: Improvement
> Components: Core & storage
> Reporter: Juan Pablo Santos RodrÃguez
> Priority: Major
> 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)
