On Thu, Jul 7, 2016 at 1:37 PM, Vincent Massol <[email protected]> wrote: > Thanks for your reply. > >> On 07 Jul 2016, at 12:31, Thomas Mortagne <[email protected]> wrote: >> >> I don't think this is a AbstractBlockRenderer job to deal with >> transformations. >> >> For me it means that when we want to filters the events we should not >> use BlockRenderer at all and instead chain listeners. For example we >> would refactor XWikiDocument#renderXDOM to create a chain of >> ChainingListener (with the actual syntax PrintRenderer at the end) >> content.traverse(myFirstListener). > > Sure, but there are still 2 problems: > * It doesn’t solve this use case: offer a way for extensions to contribute > some transformation listeners that will be used everywhere. This is the use > case we currently have with Transformations.
I was just talking about how the provided listeners would be used. You get the configured translations and create a chain from it. > * It would duplicate 99% of the content of AbstractBlockRenderer (the block > traversal) No, you just provide a helper for this. My point is that it's not BlockRenderer job to execute translation, this is a renderer. > > I need to think more about it and especially by forgetting what we have and > trying to imagine how we would design this if we were starting from scratch. > then, see if the result can be incorporated without breaking everything. > > At least do you agree with the need and that the Transformation > implementation doesn’t scale (and cannot scale), and that a solution done at > render time would be better since you’d traverse the tree only once? > > Thanks > -Vincent > >> On Wed, Jul 6, 2016 at 10:33 PM, Vincent Massol <[email protected]> wrote: >>> Hi devs, >>> >>> Rendering Tx are great to modify an XDOM into another XDOM. >>> >>> However they have a limitation: they’re slow (since you have to traverse >>> the whole AST). So if you have 10 Tx, you traverse the AST 10 times… >>> >>> I’d like to brainstorm about an alternative: the ability to register some >>> Listener that will get executed at render time and that will transform the >>> events. >>> >>> Use cases >>> ======== >>> >>> Here are some example of Tx that would benefit being rewritten using this >>> mechanism: >>> >>> * Icon Tx >>> * Auto linking of JIRA id to jira issues >>> * WikiWord Tx >>> >>> Implementation >>> ============= >>> >>> It could be something like: >>> >>> * Introduce a ConfigurableBlockRenderer interface with a addListener() >>> method >>> * Modify AbstractBlockRenderer to execute those Listeners before it calls >>> its PrintRenderer. This can be achieved with a composite listener that >>> wraps the listeners added and the PrintRenderer. >>> * Have a way to register some Listeners in the configuration, that should >>> be executed when a page is rendered >>> * Modify XWikiDocument so that those configured listeners are executed when >>> rendering a page >>> >>> Differences between Tx and Listeners >>> ============================== >>> >>> * Tx are slow but easy to write since you have access to the whole AST >>> * Listeners are harder to write since you need to store the events if you >>> need to remember them (but we have developed some tools already over the >>> years such as the LookaheadListener) >>> * Listeners depend on their order and they should be written carefully to >>> minimize their interdependencies >>> * Listener will get executed only at render time so you need to render to >>> get the modifications to the tree, while Tx are independent of rendering. >>> >>> WDYT? Do you see a better way to achieve the same goal (ie removing the Tx >>> performance limitation)? >>> >>> Thanks >>> -Vincent > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
