So a couple of months ago I was trying to resolve the issue of HTML5 support in the rewriter and I realized that the current implementation isn't a good fit for HTML5 and is overly heavy and complex. As I was diving into the the HTML5 specs I came up with a solution that could correctly identify an HTML tag as text was being pushed to it.
This allowed me to create a streaming set of events that didn't require me to parse the whole document first. I initially didn't think this was a good fit for Sling. So I built it out to a separate repository. I'm going to go ahead and put it in the whiteboard so that I can get some additional eyes on it, but it may satisfy several of your concerns. One implementation of it I came up with during this email exchange was to make this part of a ServletResponseWrapper so that if we know a resource is being requested as html content, we could wrap it with this wrapper and any text that is written to the out is modified on the fly. TLDR; 100 percent agree that the rewriter as it exists now is not a good solution. Disagree on making a solution that will only fit one way of creating HTML. -- Jason On Wed, Oct 24, 2018, at 12:55 AM, Carsten Ziegeler wrote: > As usual we're giving ourselves and our users a hard time as we want to > support all the possible options in the world instead of focusing on one > or two options and make them as good as possible. I don't care what the > solution is, but supporting 5 different ways of creating html is imho > totally wrong and fragmenting our user base. Whether it is HTL or not is > a different question. > > The current architecture of the rewriter is not optimal as it needs to > reparse the output which is expensive. The servlet API has no support > for streaming text based outputs so as long as we have that API in > between we have a bad solution. Building on top of something where we > know that its not a good thing, seems wrong to me as well. > > Carsten >
