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
>
>    

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

Reply via email to