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 <[email protected]> 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
[email protected]
