Juan,
Thx for the (long) reply.
It is indeed key to carefully select what will/will-not be added to the
public api.
Having textToHtml() on the public api make a lot of sense IMO. It will
facilitate plugin authors (existing, new) in quickly building new plugins
just be using the public api's (wi
Sorry, part of the mail was incomplete.Corrected & resend:
> Juan,
>
> Thx for the (long) reply.
> It is indeed key to carefully select what will/will-not be added to the
> public api.
>
> Having textToHtml() on the public api make a lot of sense IMO. It will
> facilitate plugin authors (existi
Hi Dirk,
would something like context.getEngine().getManager( RenderingApi.class
).textToHtml( Context, String ) work for you?
RenderingApi would sit on the o.a.w.api.engine package, and thus being part
of the public API. It would, initially, consist
of only the .textToHtml(..) method. We can add
Hi,
one last line; just to clarify, I'm not opposed to have the textToHtml
method on the public api, my concerns were more
inline with not seeing the Engine as being the place for it.. As for how to
call it,
context.getEngine().getManager( RenderingApi.class ).textToHtml(..)
would be an option, b
Juan,
Sounds logical to keep the RenderManagerApi (? why the "Api" name?) stuff
separated from the Engine interface.
I'd prefer the
"context.getEngine().render().textToHtml(...) "
syntax or perhaps more consistent
"context.getEngine().getRenderManagerApi().textToHtml(...)"
dirk
On Wed, Ap
