Ahh ok,
Well from my limited understanding it seems like a sensible idea to open this
up a bit more so perhaps I ought to just say +0, I really don't know this
codebase enough to make it +1.
Thanks,
Caleb
On 07/07/16 08:56, Vincent Massol wrote:
Hi Caleb,
On 06 Jul 2016, at 23:46, Caleb James DeLisle <[email protected]> wrote:
For CryptPad and the realtime infrastructure we deal with a DOM structure and
we needed to do a similar thing (for example to remove elements which are part
of the editor and not the document). We opted to use a similar strategy using
filter callbacks but we don't have lookahead capability.
Example Filter:
https://github.com/xwiki-labs/cryptpad/blob/master/www/pad/main.js#L51
Scanning the DOM while filtering:
https://github.com/xwiki-labs/hyperjson/blob/master/hyperjson.js#L34
For your use case you might consider to allow for buffering elements in a queue
for lookahead, your API might look like:
public void filter(Event ev, Callback<Event> whenDone);
Since you don't need to return the element synchronously, you can buffer a bunch
of events inside of the filter and wait until you know what to do and then send
them all in a loop.
Anyway just an idea.
Thanks for the ideas. We’ve actually been using Listeners in the Rendering
module from day one (we call them Listener or Renderers). The brainstorming
here is just to open up the ability to inject a user-defined listener in all
existing listeners/renderers. It’s a minor change.
FYI this is for example how we chain listeners in a listener (example for the
HTML one):
https://github.com/xwiki/xwiki-rendering/blob/master/xwiki-rendering-syntaxes/xwiki-rendering-syntax-xhtml/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/XHTMLRenderer.java#L68
And here’s some example of existing listeners to help write other listeners:
https://github.com/xwiki/xwiki-rendering/tree/master/xwiki-rendering-api/src/main/java/org/xwiki/rendering/listener/chaining
Here’s the lookahead one:
https://github.com/xwiki/xwiki-rendering/blob/master/xwiki-rendering-api/src/main/java/org/xwiki/rendering/listener/chaining/LookaheadChainingListener.java
Thanks
-Vincent
Caleb
On 06/07/16 22:33, Vincent Massol 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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
