You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hogan.js, the Mustache compiler used for generating the HTML report, has been marked as unmaintained for almost three years now; changing compilers or templating languages altogether seems to be a prudent move no matter what, and utilising the Web Components standard would remove Hogan as a dependency without the need to replace it with any other external code.
This is obviously a massive undertaking, but I think the reward makes the effort worthwhile. For a start, the existing Hogan templates could be converted to <template> elements fairly quickly, and I've plenty of WebComponent experience from my ProseMirror plugin work. (prosemirror-plugin-outline implements the WAI-ARIA treegrid pattern, and a large chunk of that code could be applied here to improve the accessibility of GoAccess's data tables, addressing part of #2742. I can spin up an example page for that if you'd like, but the relevant web component code is in ProseMirrorOutline.component.js.)
Simplifying the panel creation process would not only speed up HTML report feature development in the long-run, it would also allow those interested in different or more flexible data views—#714, #1079, #2238, #2485, #2642, #2654, #2687, #2731, #2740—to create them independently and with relative ease, either for personal use or as part of a pull request.
Ideally, this new templating approach would mean that a static HTML report—as discussed in #685—could be generated with very large tables, and those tables would be ingested by the custom elements for generating the charts and other dynamic elements.
I'd be able to start investigating this further in a week or two, though I know you are currently working on some of the filtering issues mentioned above, and I don't want to impede that work in any way. Let me know if this is seems interesting, and I can attempt to assuage any nerves by discussing some example approaches in more detail.
The text was updated successfully, but these errors were encountered:
I like the idea, it's pretty interesting! Honestly, I'm not too familiar with <template> elements yet, but I agree it's a good time to move away from Hogan if it's not being maintained anymore and we can improve the report this way. Yeah, I'd like to check out that ProseMirror component example you mentioned, if possible.
I'm curious about how much change you anticipate in terms of JS and the templating aspect. I ask mostly because as you have seen, the generated report is self-contained, so I try to keep it as lean as possible. That said, I do prioritize all these improvements.
Hogan.js, the Mustache compiler used for generating the HTML report, has been marked as unmaintained for almost three years now; changing compilers or templating languages altogether seems to be a prudent move no matter what, and utilising the Web Components standard would remove Hogan as a dependency without the need to replace it with any other external code.
This is obviously a massive undertaking, but I think the reward makes the effort worthwhile. For a start, the existing Hogan templates could be converted to
<template>
elements fairly quickly, and I've plenty of WebComponent experience from my ProseMirror plugin work. (prosemirror-plugin-outline
implements the WAI-ARIA treegrid pattern, and a large chunk of that code could be applied here to improve the accessibility of GoAccess's data tables, addressing part of #2742. I can spin up an example page for that if you'd like, but the relevant web component code is in ProseMirrorOutline.component.js.)Simplifying the panel creation process would not only speed up HTML report feature development in the long-run, it would also allow those interested in different or more flexible data views—#714, #1079, #2238, #2485, #2642, #2654, #2687, #2731, #2740—to create them independently and with relative ease, either for personal use or as part of a pull request.
Ideally, this new templating approach would mean that a static HTML report—as discussed in #685—could be generated with very large tables, and those tables would be ingested by the custom elements for generating the charts and other dynamic elements.
I'd be able to start investigating this further in a week or two, though I know you are currently working on some of the filtering issues mentioned above, and I don't want to impede that work in any way. Let me know if this is seems interesting, and I can attempt to assuage any nerves by discussing some example approaches in more detail.
The text was updated successfully, but these errors were encountered: