The java API exposed by the sightly engine is fairly limiting (probably on purpose) but there are definitely going to be use cases to extend or override out-of-box behavior. Some immediate ones come to mind:
- sightly XSSFIlter & XSSExtension leverages the XSSAPI#formatHtml which relies on XSSFilter -- there is no sightly @ context which allows for custom ProtectionContext or antisamy policy file with the exception of 'unsafe' and manually XSSFilter scrubbing. Allowing extension/customization of sightly contexts might go a long way in providing an idiomatic means to use custom antisamy policy files without resorting to JSP.
- sightly AttributePlugin (data-sly-attribute) blacklists 'style' and 'on___' attributes without documenting it or providing a means to disable. data-sly-<plugin> in general are great candidates for runtime configurability and extension.
- sightly Extension Registry Service could support & coordinate a priority property similar to how sightly FilterComponents do, which would make the RuntimeExtension API more useful, & avoid non-deterministic behavior and key collisions for RuntimeExtension#name()
Is there a future with sightly opening the doors to developers? This would help adoption and clean up our mixed JSP/sightly code bases.