sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Klco <>
Subject Re: Sling 12 themes
Date Tue, 23 Oct 2018 19:43:52 GMT
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

On Tue, Oct 23, 2018 at 1:32 PM Jason E Bailey <> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message