incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murray Altheim <murra...@altheim.com>
Subject Re: Controllable API
Date Wed, 25 Jun 2008 06:49:26 GMT
Janne Jalkanen wrote:
>> If I were to create a jspwiki_module.xml file for all of the plugins
>> I administer (and provide XML files for all jars I distribute), then
>> it'd be a matter of adding a single element (e.g., <enabled>, or
>> perhaps an ACL-based approach) to the XML, adding the rather minor
>> changes to com.ecyrd.jspwiki.ui.admin.beans.PluginBean to process the
>> new boolean or ACL value(s), and add the necessary functionality to
>> Admin.jsp to permit more than the current read-only display, instead
>> including a checkbox (boolean) or selector (ACL) for each plugin.
>>
>> Is this close to what's needed, or is there a lot more?
> 
> That's pretty much it... :-)

Except I just realized that there might be a requirement for dependency
management. For example, a large number of my plugins are queries of
one sort or another, so they often extend QueryPlugin, or extend an
extension of QueryPlugin. If an admin turned off QueryPlugin a whole
lot of plugins would fail, and relatively inexplicably. Perhaps a simple
reflection check of what the plugin extends would work, or just rely
on documentation, which is perhaps not as elegant but gets us to a
solution a lot faster.

> You might actually want to store the "enabled/disabled" status elsehwere 
> than in the jspwiki_module.xml, or else it won't be persisted across 
> restarts.  So I would recommend the workdir and store it in there in 
> some sort of a preferences object.  (Hmm, we already seem to have 
> com.ecyrd.jspwiki.preferences...  Anyhoo, this is something that 
> actually does need a bit of thinking - currently the reason why 
> Admin.jsp does not store any values is because of the fact that I could 
> never really figure out what the proper storage should be, and how that 
> should relate to the jspwiki.properties and filters.xml files.)

Okay, will look into that. I agree -- the XML file should be an initial
set of settings but I wouldn't want to write to it. What I do in my
Ceryle application is read an XML properties file but write it back
out using its native format with .prefs extension. The presence of the
prefs file tells the app to read it instead of the properties file. I
could mimic that behaviour pretty easily.

    <properties>
      <entry key="http://purl.org/ceryle/prop/#author"></entry>
      <entry key="http://purl.org/ceryle/prop/#restoreSession">false</entry>
    </properties>

    http\://purl.org/ceryle/prop/\#author=Murray Altheim
    http\://purl.org/ceryle/prop/\#restoreSession=true

>> [I'm also curious as to how the 'alias' feature works, as I currently
>> have a fair number of classes whose sole purpose is to provide an
>> alias so that users don't have to type "Plugin" appended to what is
>> basically a predicate name). Are multiple alii possible?]
> 
> At this moment, no, but it should be an easy enough extension.  Needs 
> changing of the WikiPluginInfo API though.

I'll look into that as well -- sounds like it would be permitting
multiple <alias> elements or something akin.

Murray

...........................................................................
Murray Altheim <murray07 at altheim.com>                           ===  = =
http://www.altheim.com/murray/                                     = =  ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =

       Boundless wind and moon - the eye within eyes,
       Inexhaustible heaven and earth - the light beyond light,
       The willow dark, the flower bright - ten thousand houses,
       Knock at any door - there's one who will respond.
                                       -- The Blue Cliff Record

Mime
View raw message