Exporting a document without its attachments or with only a subset of them

[slauriere]

Hi everyone,

In the frame of an app I’m developing which contains multilingual content, some pages have one attachment per language and I would like to export some spaces containing such pages on a language basis, hence filtering out all attachments that do not match a given language, since they won’t be needed by the users using such exports and it will lighten the generated XAR file. Do you know if this something that could get easily achieved for instance with the Filter Module (I looked up the documentation and the code a bit but could not find the way to do it yet), or should I instead opt for another storage strategy which would take this specific export need into account?

Cheers

Stéphane

[tmortagne]

@slauriere

Do you know if this something that could get easily achieved for instance with the Filter Module

Well you actually can’t really do any XAR serializing/parsing without using the Filter module directly or indirectly since that’s how it’s implemented in recent versions of XWiki

As to how to implement this: the general idea of the filter module is that you have an input filter stream (which read stuff and produce “events”), an output filter stream (which receive “events” and produce stuff), and you can squeeze any filter you want in between to filter those events (in your case let or not let pass attachments to the output filter from what I understood). You can take a look at xwiki-platform/ExportAction.java at master · xwiki/xwiki-platform · GitHub to have a better understanding of how the standard XAR export uses the Filter module, the only difficulty is that you have to accept the same “events” than the output filter in your own filter if you want it to receive them, so it can mean bridging a lot of methods just to modify one. You can reduce a bit the plumbing by calling xarFilterStreamFactory.getFilterInterfaces() and create a Java Proxy from it, at least that way you are sure you won’t miss any call present or future. We would need to expose some helpers to make this kind of use case a bit easier to implement.