Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Is there an option to strip whitespace from the XML reports? If not we'll write up a patch to do so if it's not too crazy.
It wouldn't be as simple as creating an option to toggle these values would it?
./renderers/FrxXML.inc:
15 $dom->ownerDocument->formatOutput = TRUE;
16 $dom->ownerDocument->preserveWhiteSpace = TRUE;
Thanks for your guidance
Comment | File | Size | Author |
---|---|---|---|
#6 | whitespace_stripping-2238193-6.patch | 1.02 KB | metzlerd |
#3 | whitespace_stripping-2238193-3.patch | 2.23 KB | jamesdixon |
Comments
Comment #1
jamesdixon CreditAttribution: jamesdixon commentedWe have large XML files generated by the reports which would be reduced to just over half the size if we were to implement this. :)
Comment #2
metzlerd CreditAttribution: metzlerd commentedFrxXML is about dispalying xml, and not about .frx file generation. That code is only executed if you use an frx:renderer="FrxXML" attribute in the report. If it cannot be done with simple LibXML configuration objects then you might consider implementing an input filter to do the whitespace replacement and set this as the input filter used by forena. That would reduce the file size, whithout need for complicating the ui.
Another way to look at this would be an skin specified option that was read by the .XML document format. Then it could be applied just before rendering in docformats/FrxXMLDoc.inc. We already have some code there that is checking skin options to control root elements in this case, so it seems like it might be a good fit there.
Comment #3
jamesdixon CreditAttribution: jamesdixon commentedRather than stripping it from the output generated inside docformats/FrxXMLDoc.inc, in an effort to reduce memory consumption I've put the whitespace stripping inside renderers/FrxRenderer.inc.
We switched to Forena 4.x, as the memory usage seems to be less in the new version.
Please find the patch attached. To use one can add the following to their skininfo file.
FrxReport[stripWhitespace] = true
Comment #4
jamesdixon CreditAttribution: jamesdixon commentedComment #5
metzlerd CreditAttribution: metzlerd commentedThis is the right strategy but I need to refactor this patch based on memory leak work.
Comment #6
metzlerd CreditAttribution: metzlerd commentedHere's a revised patch that need some testing.
Comment #7
metzlerd CreditAttribution: metzlerd commentedSeems to test out as advertised.
Comment #8
jamesdixon CreditAttribution: jamesdixon commentedI can confirm this works, thank you!
Comment #10
Pierre.Vriens CreditAttribution: Pierre.Vriens commentedJames or David,
Extra questions related to your "... large XML files generated by the reports which would be reduced to just over half the size ...", and the related .skinfo addition of "FrxReport[stripWhitespace] = true" as described above:
1) Can you think of cases where you would not want to take advantage of this new feature?
2) Assuming that in most (over 50%) of the cases it is best to have this new feature enabled, why not make that the default, either by adding it to the delivered .skinfo file(s), or by swapping the if/else logic (2x) implemented in the current dev version? And in cases where the Whitespaces should not be stripped, add "FrxReport[stripWhitespace] = false".
If this makes sense to you, I'd be happy to submit an appropriate patch for it, either in the .skinfo file, or to swap the logic in the FrxRenderer.inc (let me know which approach is best, but I'd vote for the FrxRenderer.inc correction).
FYI: I'm planning to also document this stripWhitespace option (and some other .skinfo options) in an upcoming iteration of the Tutorial enhancements. So any extra info you can provide on this will help me to do so.
Comment #11
metzlerd CreditAttribution: metzlerd commentedForena is not used all that often for generating large XML documents. In this case it was being used to generate an XML document with 10s of thousands of nodes and so the file size was an issue. Generally what you get out of an XML file is the same format as the .frx file that was used to build it and this is the sensible default IMHO. In most cases readability is more important to me than the size of the rendered report, so I would not want it as a default for my reports. Anyone who is concerned about this could make it the default for their custom skin if they chose to. Also there is a small performance penalty (memory and processing) for this feature, so I'm not sure it makes sense to set it as default.