Hi Ichiro,
com.ecyrd.jspwiki namespace is also a default valid plugin namespace for
2.9.x, it is
translated into org.apache.jspwiki at
org.apache.wiki.utilClassUtil#findClass (this was
part of https://issues.apache.org/jira/browse/JSPWIKI-719).
The <K,V> is just to ensure that older, ungenerified, plugins can remain
compatible with
current trunk, while also allowing something like:
MyPlugin implements WikiPlugin<String, Object>
and therefore getting the typed Map at execute(..). I'm not very fond of
introducing the
<String, Object> change b/c of the compatibility issue, (in 2.9.x, 2.10.x
would be
the place for that) but maybe I'm being over-conservative here. So, other
thoughts from
anyone else (specially plugin devs)?
cheers,
jp
On Sun, Nov 4, 2012 at 9:39 PM, Ichiro Furusato
<ichiro.furus...@gmail.com>wrote:
> Hi Juan Pablo,
>
> Given that the package name of all plugins is required to change from
> com.ecyrd.jspwiki
> to org.apache.wiki, anyone with existing plugins is going to have to
> fix and recompile them
> for compatibility anyway, so it's a good time to force generics into the
> API.
>
> I'm not sure why you'd suggest
>
> public String execute( WikiContext context, Map<K,V> params )
> throws PluginException;
>
> as the method signature, as I believe we'd want to constrain K to
> String and V to any
> Object, so I'd advocate for Map<String,Object> myself (and all of my
> plugins would
> conform with that simple change). Perhaps you have a reasons I don't
> understand.
>
> I've taken over the CeryleWikiPlugin set and while I'm not going to
> commit to upgrading
> the entire set, I'm willing to release most of them, depending on my
> time constraints.
> Some of rather obscure, but a number are pretty handy (such as the user
> tagging
> system).
>
> Cheers,
>
> Ichiro
>
> On Mon, Nov 5, 2012 at 8:31 AM, Juan Pablo Santos Rodríguez
> <juanpablo.san...@gmail.com> wrote:
> > Hi Ichiro,
> >
> > in fact, PluginManager#parseArgs builds a HashMap<String, Object> but
> > returns an
> > ungenerified Map, most probably because this way binary compatibility
> with
> > older,
> > ungenerified plugins is ensured. Besides, as the plugin system hasn't had
> > any issues
> > since a long long time, the focus had been put elsewhere.
> >
> > But yes, aside from the compatibility issue, constraining to <String,
> > Object> makes
> > sense to me, as most probably this is how the Map is used by everyone
> > (anyone not
> > doing this way please correct me).
> >
> > hmm right now I'm thinking that WikiPlugin's signature could be changed
> to
> > something like:
> >
> > public interface WikiPlugin <K, V> {
> > public String execute( WikiContext context, Map<K,V> params ) throws
> > PluginException;
> > }
> >
> > so you could override the Map types on your plugins. Makes sense?
> >
> >
> > br,
> > juan pablo
> >
> > On Sat, Nov 3, 2012 at 10:23 AM, Ichiro Furusato
> > <ichiro.furus...@gmail.com>wrote:
> >
> >> Hi,
> >>
> >> In looking at the 2.9.0 code I note that it doesn't use generics in a
> >> number of
> >> rather key places, such as WikiPlugin.execute(), so I'm guessing it
> hasn't
> >> been updated in a few years (at least in that regard), perhaps due to
> the
> >> somewhat longstanding status of the project going into Apache, or for
> >> legacy-
> >> compatibility reasons.
> >>
> >> Could someone please fill me in as to any particular reason why the Map
> >> argument couldn't be constrained to <String,String> or <String,Object>?
> >> I've
> >> got quite a few plugins that are now incompatible with a generics-less
> >> WikiPlugin API, i.e.,
> >>
> >> public String execute( WikiContext context, Map<String,Object>
> >> params ) throws PluginException;
> >>
> >> ...and rather than remove all my generics I'm wondering if it'd be
> possible
> >> to update the API. Yes, I know that is a brash assumption.
> >>
> >> Thanks much,
> >>
> >> Ichiro
>
