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

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

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.

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs