Juan Pablo, I have no preference over the two options. I personally don't know of any plugins that will get broken, but maybe other people on the list can comment on that, so we hopefully get a better picture of what we might break.
kind regards, Harry On 26 November 2012 23:08, Juan Pablo Santos RodrÃguez < [email protected]> wrote: > 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 > far: > > 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 [email protected], so these two should happen shortly). > > > br, > juan pablo >
