Agreed with Justin. There are several different sources of URLs which may need to be rewritten including directly from scripts, WYSIWYG HTML or Java / Model generated HTML (bad practice, I know) and I'm not seeing how a pure-HTL solution would handle WYSIWYG HTML or Java / Model HTML without having to re-parse the content.
Additionally, there's more value in the Sling Rewriter, as Justin and Jason have described, to be able to rewrite any outgoing content. Unfortunately, right now it's not easy easy to do as it could be if the API were cleaned and a better reference implementation provided. On Tue, Oct 23, 2018 at 7:45 PM Justin Edelson <jus...@justinedelson.com> wrote: > Just my 2cents as a fan of the rewriter. > > The problem with saying "just use HTL" (aside from what Jason said) is that > it enables a separation of concerns. To say "just use HTL" implies that > there is a single developer (or organization) who "owns" all the code > responsible for generating HTML and has the authority to change them to > suit emerging requirements (which today can be done universally via a > rewriter transformer). But this isn't really the case a lot of the time -- > there's multiple "owners" who are each contributing components and applying > rewriter-style logic across those owners is complicated (if not impossible) > to manage. This also assumes that HTL (or any other scripting language > generating HTML) is actually being used properly -- in my experience, > there's plenty of "raw" HTML being output from string properties and you > need a way to rewrite that too. > > I really don't think all the rewriter use cases boil down to link > rewriting. > https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13 > is > a real-world example. But I'll need to dig through my project archive to > come up with good examples. > > Personally, I'd suggest that HTL could be more tightly coupled to the > rewriter and rather than emit a character stream which gets parsed into a > SAX stream, the rewriter could be reimagined as a more generic event stream > processing chain and HTL is directly providing HTML events into this chain > (and given that HTL knows the output context, it could indicate as part of > the event that the text content should be parsed in the case of embedded > HTML). The output of JSPs could be parsed as is the current state. JSON > could be handled through different event types. > > > > > On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler <cziege...@apache.org> > wrote: > > > The rewriter as it is today is pretty heavy and adds a lot of overhead > > to request processing. Especially as the output needs to be created > > first and then parsed again. > > > > There is nothing wrong with enhancing it in general. But for example if > > you use HTL we could provide much better and faster support ootb. I > > think if JSON is rendered we could do something at JSON creation time > > instead of needing to reparse it again as well. > > > > I agree that it gets pretty hard to come up with a solution that targets > > all output formats at once, even with the rewriter concept it's not that > > easy. But maybe we can come up with different implementations that share > > a single configuration. For example for link rewriting that should be > > possible. > > > > > > Carsten > > > > Am 23.10.2018 um 21:43 schrieb Daniel Klco: > > > I don't see how we could support multiple templating languages without > > some > > > sort of rewriter support. > > > > > > Part of the problem IMO is that the Rewriter library muddles the > > rewriting > > > concept with an expectation of specifically dealing with (X)HTML. > Instead > > > it would make more sense to me to have a content agnostic library for > > > performing content rewriting and providing a HTML, XML and (possibly) > > JSON > > > implementation. > > > > > > On Tue, Oct 23, 2018 at 1:32 PM Jason E Bailey <j...@apache.org> wrote: > > > > > >> > > >> On Tue, Oct 23, 2018, at 1:24 PM, Konrad Windszus wrote: > > >>> I would rather prefer to get rid of a server side postprocessing > like > > >>> the rewriter. For HTL I agree with Carsten, we should probably look > > into > > >>> a generic link rewriting mechanism which allows for custom rewriting > > >>> with a nice HTL plugin. Much less overhead than a Cocoon pipeline > which > > >>> needs to deserialize and then serialize again... > > >>> Would be interesting to get forward in that regard with Sling 12. > > >> > > >> There is a real world need for html post processing that is not > > dependent > > >> on HTL. The rewriter is already not a core component and something > that > > is > > >> community supported so I don't think enhancing it should be much of an > > >> issue. For what it's worth though I don't like the overhead of the > > existing > > >> pipeline as it is anyway. HTML doesn't have anything to do with XML > > anymore. > > >> > > >>> For JSON and client side rendering the link rewriting must be rather > > >>> encapsulated on the client side as well. I don’t think Sling should > > >>> provide that functionality as Sling is focusing on the server side. > > >> > > >> Missing a point here I think. If you are focusing on link rewriting, > > that > > >> is something that can only occur on the server side. Helps with > > >> multi-tenancy and cross linking. > > >> > > > > > > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > > >
