Hi Murray,
> > Why introduce then the first option? Because that would be the way to go
> > with
>
> I'm guessing you had to take a typing break here. :-)
>
that would've been "next section"
>
> ...
> > (2) Filters
>
Juan Pablo wrote:
> (another lengthy e-mail, if we're lucky, the last one..)
I'll preface my remarks with one that tries to encapsulate my position: that
is, I don't *think* I'm asking to do anything more than a reasonable person
who has a substantial investment in JSPWiki customisation would ask:
Hi,
(another lengthy e-mail, if we're lucky, the last one..)
took a look at how could we achieve backward compatibility for (1)plugins,
(2)filters and (3)page
providers, while developing the public API. After that I'd like two make
two brief comments about
(4)next steps and (5)having JSPWiki inst
Hi Murray,
I'll look into make the current plugins mantain their signature if
possible. As I wrote else-thread, keep in mind the 6 last
releases contain code changes that could result in custom plugins / filters
not working anymore. That would also
happen on this release, whether the plugin signat
(apologies in advance because this is going to be a large e-mail)
Hi Jürgen,
I agree that retaining backward compatibility should be a top priority.
However, I strongly disagree with this sentence:
"As I understand this public API would bring no advantage in
functionality or user experience, onl
Hi,
part of the appeal of JSPWiki is for me that I can reach deep into the
wiki engine from plugins.
JSPWiki is for hackers, BigCorps use Confluence.
And as hacker I want control, I need to look into the Wiki core and
use what it offers, or work around its limitations.
So I'd rather prefer no API
> Hi Murray,
>
> for plugins, most probably there'll be a signature change on WikiPlugin,
> from:
> String execute( WikiContext context, Map< String, String > params ) throws
> PluginException;
>
> to:
> String execute( Context context, Map< String, String > params ) throws
> PluginException;
Hi
Hi Murray,
for plugins, most probably there'll be a signature change on WikiPlugin,
from:
String execute( WikiContext context, Map< String, String > params ) throws
PluginException;
to:
String execute( Context context, Map< String, String > params ) throws
PluginException;
With Context being a m
Hi Juan Pablo,
One of the things I have considered proposing I'll go ahead and
propose. I'm as seems typical lately rather overcommitted so I've
not been able to review what's going on with the new APIs but I
had the thought that it might be a good idea to actually support,
at least for some peri
Hi,
I'm finishing another group of commits introducing part of the new public
api. As the initial proposal is taking shape, I've thought an update would
be nice:
* o.a.w.api.core: core API interfaces
** Engine, Context and Session, extracted from WikiEngine, WikiContext and
Session
** Page and At
[...]
> Thoughts? Am I missing something, should the API include more things, or
> is it too wide,..?
Hi Juan Pablo,
As an author of a lot of plugins I'm guessing I'll have some work to do to
update my code. Sorry, but I won't be able to look into this and provide any
feedback until this coming w
11 matches
Mail list logo
