[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
On Aug 5, 2009, at 1:18 PM, Vincent Massol wrote:
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; }
+ boolean runTransformations in the parameters in a second signature. -Vincent
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
On Aug 5, 2009, at 1:23 PM, Vincent Massol wrote:
On Aug 5, 2009, at 1:18 PM, Vincent Massol wrote:
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; }
+ boolean runTransformations in the parameters in a second signature.
Actually strike this. I think we should always run transformations in the converter. If the user doesn't want them then he'll use the parser and renderer directly. -Vincent
-Vincent
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
+1 On Wed, Aug 5, 2009 at 14:11, Vincent Massol<[email protected]> wrote:
On Aug 5, 2009, at 1:23 PM, Vincent Massol wrote:
On Aug 5, 2009, at 1:18 PM, Vincent Massol wrote:
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; }
+ boolean runTransformations in the parameters in a second signature.
Actually strike this. I think we should always run transformations in the converter. If the user doesn't want them then he'll use the parser and renderer directly.
-Vincent
-Vincent
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Vincent Massol wrote:
On Aug 5, 2009, at 1:23 PM, Vincent Massol wrote:
On Aug 5, 2009, at 1:18 PM, Vincent Massol wrote:
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); }
+0
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.
+0
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
+0
4) Introduce Converter
@ComponentRole public interface Converter { void convert(Reader source, Syntax sourceSyntax, Syntax targetSyntax, WikiPrinter printer) throws ConversionException; }
+ boolean runTransformations in the parameters in a second signature.
Actually strike this. I think we should always run transformations in the converter. If the user doesn't want them then he'll use the parser and renderer directly.
+1, I'll finally drop my converter component.
-Vincent
-Vincent
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.
+1 Thanks, Marius
Here's my +1 to all
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol wrote:
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); }
+1
b) The getAvailableSynatxes() doesn't exist anymore. It's been moved to SyntaxFactory, see below.
+1
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.
+0 How does non-java code find out the available syntaxes? Would more specific methods be OK, like getParserSyntaxes, getRendererSyntaxes? If there are too many differences in the types of syntaxes, why is there only one SyntaxFactory? Doesn't the whole class suffer from this problem?
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
+1
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.
+1
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.
+1 -- Sergiu Dumitriu http://purl.org/net/sergiu/
Sergiu Dumitriu wrote:
Vincent Massol wrote:
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); }
+1
+0
b) The getAvailableSynatxes() doesn't exist anymore. It's been moved to SyntaxFactory, see below.
+1
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.
+0
How does non-java code find out the available syntaxes?
Normally +0 for 1b and 2a but this is a good question.
Would more specific methods be OK, like getParserSyntaxes, getRendererSyntaxes?
If there are too many differences in the types of syntaxes, why is there only one SyntaxFactory? Doesn't the whole class suffer from this problem?
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
+1
+0
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.
+1
+1
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.
+1
+1
participants (5)
-
Anca Paula Luca -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol