incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Pablo Santos Rodríguez <>
Subject changes in WikiPlugin API
Date Mon, 26 Nov 2012 22:08:15 GMT
Hi all,

picking up with a few weeks old thread, regarding the WikiPlugin's API: the
question was if it was possible to generify the WikiPlugin API (more
specifically, the parameters Map), and to what extent. So, my findings so

WikiForms, a special type of WikiPlugins are built up with using
Map<String, String>

WikiPlugins are built using Map<String, String> but they also add a custom
attribute, _bounds, which is an int[], so at the end a Map<String, Object>
is used. This parameter isn't used throughout the source, but maybe it's
used by some other plugins.

As WikiForms and WikiPlugins are built using different types of Maps, there
is a small mismatch between them, which can be solved through one of the
following options:

- option 1: String execute( WikiContext context, Map<String, Object> params
would retain backwards compatibility. However there will be a little
mismatch between WikiForms and the rest of WikiPlugins, as the former are
built up assuming Map<String, String>. Nothing specially serious, as it
would be fixed by omiting the generics in the bridge between WikiForms and
Plugins. It (may) look a bit strange, but it would work.

- option 2: String execute( WikiContext context, Map<String, String> params
would break backwards compatibility, as this would mean either dropping the
_bounds attribute from WikiPlugins or changing the type of the bounds
parameter from int[] to String, or adding a new int[] getBounds() method.
However, plugins and forms would fit seamlessly.

I'm more inclined towards option #2 + publishing a getBounds method, but
I'd rather ask here which option would fit better. I'd also like to push
these changes as soon as the 2.9.0 is released and announced (the vote
passed at general@i.a.o, so these two should happen shortly).

juan pablo

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