yes, that's what we roughly outlined at [1]. of course that's still a lot of work to do to get rid of the rewriter, and when it's time it maybe still deprecated kept in in-place for more exotic use cases (like PDF generation).
why / for what use cases do we want to get rid of it - my view: - the rewriter is currently (esp. in AEM) mainly used for checking validity of links in a post-processing step - that means AFTER the markup was generated by all the scripts, it is parsed again, link are identified by heuristics, and if a link seems to point to an internal page/resource, and this page/resource does not exist, the link is removed by the rewriter - this leads to several problems: - performance issue: why generating the markup and directly after parse it again to serialize it again? - responsibility/control issue: what should happen should if a link is invalid should rely in the control of the component/script that renders the link. sometimes only the anchor is unwrapped, but often more is happening, e.g. the whole teaser is hidden, the whole navigation entry is hidden etc. the rewriter cannot "know" these use cases. - link detection issue: because relying on heuristics it is never sure that the rewriter can detect all links. e.g. by default it cannot detect link in data attributes, link in javascript, link in JSON files etc. - that means the aspect of externalizing and validating links belongs into the business/framework logic, not in a post processing link rewriter. that's why we build the URL/link handler in wcm.io [2] - and i think in the long run sling should go in this direction as well (at least for the basic URL handling features). I known that lot's of sling-based application put all their complex link handling logic into customized rewriter pipelines, but imho this is the wrong place for it. see also [3] for some background information. stefan [1] https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E [2] https://wcm.io/handler/ [3] https://adapt.to/2019/en/schedule/assets-and-links-in-aem-projects.html >-----Original Message----- >From: Jason E Bailey [mailto:j...@apache.org] >Sent: Monday, September 9, 2019 3:07 PM >To: dev@sling.apache.org >Subject: Why get rid of the rewriter? > >I obviously missed the chat at the adaptTo() meetup. > >Can anyone summarize why we are getting rid of it? And the thought process >on replacing it? > >- Jason
