Re: [xwiki-devs] [VOTE] API change for Rendering module

Hi, I'd like to propose the following API changes to the Rendering module: 1) Modify PrintRendererFactory a) There's now one factory component per Renderer type with the following interface: public interface PrintRendererFactory { /** * @return the Syntax supported by the Renderer type * @since 2.0M3 */ Syntax getSyntax(); /** * @param printer the printer to use to output renderer data * @return a new Renderer instance (stateful) * @since 2.0M3 */ PrintRenderer createRenderer(WikiPrinter printer); } b) The getAvailableSynatxes() doesn't exist anymore. It's been moved to SyntaxFactory, see below. 2) Modify SyntaxFactory a) Remove getAvailableSyntaxes() since there are different types of syntaxes: Parser syntaxes, Renderer syntaxes and even amongst Parser/Renderer there will be different types of them: streaming, block. Thus the new strategy is for client code to directly ask for syntaxes by looking up the objects against the CM. getAvailableSyntaxes() has been deprecated. 3) Introduce BlockRenderer @ComponentRole public interface BlockRenderer { /** * @param block the block to render in the target syntax * @param printer the object where to output the result of the rendering */ void render(Block block, WikiPrinter printer); /** * @param blocks the list of blocks to render in the target syntax * @param printer the object where to output the result of the rendering * @todo remove this API once we introduce the notion of BlockCollection */ void render(Collection<Block> blocks, WikiPrinter printer); } Goals: a) Have 2 types of Renderers (as we'll have 2 types of Parsers in the future): Stream and Block b) reduce code duplication since using the BlockRenderer will simplify the client code 4) Introduce Converter @ComponentRole public interface Converter { void convert(Reader source, Syntax sourceSyntax, Syntax targetSyntax, WikiPrinter printer) throws ConversionException; }

Goal: Simplify client code when the need is pure conversion. 5) Move Renderer's implementation classes (components now) in the internal package They're now components and thus we can move them in the internal package. Here's my +1 to all Thanks -Vincent