incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Kitching (JIRA)" <j...@apache.org>
Subject [jira] Created: (JSPWIKI-156) Allow customisation of CommandResolver (WikiEngine.m_commandResolver)
Date Thu, 24 Jan 2008 14:45:35 GMT
Allow customisation of CommandResolver (WikiEngine.m_commandResolver)
---------------------------------------------------------------------

                 Key: JSPWIKI-156
                 URL: https://issues.apache.org/jira/browse/JSPWIKI-156
             Project: JSPWiki
          Issue Type: Improvement
          Components: Core & storage
    Affects Versions: 2.8
            Reporter: Simon Kitching
            Priority: Minor


Currently, the WikiEngine creates its CommandResolver helper object via a call to new CommandResolver().

I would like to customise the way that the CommandResolver maps the incoming url to the actual
wiki content-file to load. This is to support a wiki-based webapp help system where the url
passed indicates the webapp page for which context-sensitive-help is wanted. If a specific
matching page is not present in the wiki I want to "walk up the directory tree" to find the
best available match. For example, with /Wiki.jsp?path=foo/bar/baz, first look for a foo%2fbar%2fbaz
page, then look for a foo%2fbar page, etc. This requires overriding getFinalPageName in the
CommandResolver class.

I'm sure there are other uses for the ability to customise the mapping from url to actual
content page.

Note that it is possible to modify the url before it is processed by jspwiki, so that it already
points to the actual page to display. However certainly in my case that requires looking inside
the "page repository" of the wiki to determine what pages currently exist and so is best done
inside the actual wiki engine.

One possibility would be for WikiEngine to use the ClassUtils.getMappedObject method to retrieve
the CommandResolver instance rather than just using new. However this would only be useful
if CommandResolver also has the "final" attribute removed from the class and methods, or if
CommandResolver were an interface and the current concrete class were renamed to CommandResolverImpl
or similar.

Alternatively, CommandResolver could itself support a "helper" object, like AuthorizationManager
has an optional "Authorizor" helper. This would be more work though.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message