+0 Thanks, Marius Vincent Massol wrote:

Hi,

We have the need to handle optional Transformations (for Annotations and more generally for user-introduced annotations).

Here's what Thomas and I are proposing:

1) We remove the TransformationManager component from the Rendering module (public API). This means that calling code must lookup Transformations directly.

2) We modify the Converter interface in the Rendering module in 2 ways: - add a new signature that takes a list of Transformation as parameter - modify the implementation for the signature that take no Transformation params so that no Transformations are executed when it's used (API breakage)

3) We add a XWiki configuration parameter in xwiki.properties to list the transformations that must be executed (it's a list of component hints) when a document is rendered. If this config param is not defined then the default value will contain the Macro Transformation.

4) We introduce a new module called xwiki-presentation which will contain code to handle XWiki Presentation stuff. For example: - template handling - displayers (document displayer, object displayers, etc) - display configuration - more to be defined but related to presentation

The idea would be to move stuff that is currently in XWiki/ XWikiDocument related to presentation there (for example XWikiDocument.getRenderedContent could be replaced by DocumentDisplayer.display(DocumentName, Syntax, Writer output) - to be defined later).

5) In order to allow modules to not depend on xwiki-core we introduce PresentationConfiguration in the new xwiki-presentation module defined in 4) with a getViewTransformations() method corresponding to a "presentation.viewTransformations" configuration parameter.

6) We introduce a new TransformationContext class similar to MacroTransformationContext and modify the Transformation API to:

void transform(XDOM, TransformationContext) (instead of XDOM dom, Syntax syntax)).

TransformationContext would contain 2 type of data: - the syntax - the list of transformations being executed (this is required by some Macros. For ex the HTML macro needs it and other may need it too)

7) We remove the getPriority() method from the Transformation interface

8) We modify calling code: WYSIWYG, XMLRPC, etc to use the new Converter API and to lookup PresentationConfiguration to get access to the list of view transformations to be executed.

Here's my +1

Thanks -Vincent

PS: A long and complex mail... sorry about that...

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, On 11/23/2009 7:00 PM, Vincent Massol wrote:

Hi,

We have the need to handle optional Transformations (for Annotations and more generally for user-introduced annotations).

Here's what Thomas and I are proposing:

1) We remove the TransformationManager component from the Rendering module (public API). This means that calling code must lookup Transformations directly.

2) We modify the Converter interface in the Rendering module in 2 ways: - add a new signature that takes a list of Transformation as parameter - modify the implementation for the signature that take no Transformation params so that no Transformations are executed when it's used (API breakage)

3) We add a XWiki configuration parameter in xwiki.properties to list the transformations that must be executed (it's a list of component hints) when a document is rendered. If this config param is not defined then the default value will contain the Macro Transformation.

4) We introduce a new module called xwiki-presentation which will contain code to handle XWiki Presentation stuff. For example: - template handling - displayers (document displayer, object displayers, etc) - display configuration - more to be defined but related to presentation

The idea would be to move stuff that is currently in XWiki/ XWikiDocument related to presentation there (for example XWikiDocument.getRenderedContent could be replaced by DocumentDisplayer.display(DocumentName, Syntax, Writer output) - to be defined later).

5) In order to allow modules to not depend on xwiki-core we introduce PresentationConfiguration in the new xwiki-presentation module defined in 4) with a getViewTransformations() method corresponding to a "presentation.viewTransformations" configuration parameter.

6) We introduce a new TransformationContext class similar to MacroTransformationContext and modify the Transformation API to:

void transform(XDOM, TransformationContext) (instead of XDOM dom, Syntax syntax)).

TransformationContext would contain 2 type of data: - the syntax - the list of transformations being executed (this is required by some Macros. For ex the HTML macro needs it and other may need it too)

7) We remove the getPriority() method from the Transformation interface

8) We modify calling code: WYSIWYG, XMLRPC, etc to use the new Converter API and to lookup PresentationConfiguration to get access to the list of view transformations to be executed.

Hehe, looks like the converter gets changed even sooner then I expected. Explicitly passing the entire list of transformations to the converter should ensure the same behavior. Note that the conversion in xmlrpc is still work in progress and I'm still to write the integration tests. The rate of changes in the rendering continues to be pretty high with an obvious risc of breakage. I'll need more tests on my .net side which makes Windows CI even more urgent. +1 for the proposed modifications. Thanks, Florin Ciubotaru

Here's my +1

Thanks -Vincent

PS: A long and complex mail... sorry about that...

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs