Re: Why get rid of the rewriter?
+1 great summary. On Tue, Sep 10, 2019 at 12:37 PM Stefan Seifert wrote: > i try to write a first summary: > > - we have good use cases for a rewriter in general, but are unhappy with > the current implementation and it's way of configuration. the whole thing > is a bit "alien" to the other parts of sling. > > - a new rewriter implementation should be performant and with up-to-date > support for modern HTML. ideally something like SAX for HTML (not > XML/XHTML). this would not cover other use cases producing something other > than HTML, though. perhaps there are libraries out there that can be built > upon. should also provide modular support, e.g. rewriting only the output > of a single component or text fragment. maybe someone can come up with a > proposal. > > - we have to keep the old rewriter for backward compatibility because it > was used a lot in the past, but do not plan to maintain it further and > probably will remove it from the sling starter as well. mark it as > deprecated or contrib. > > - we do no longer want to use the rewriter for link validation and > externalization, but support this as aspect in another, more appropriate > way (with some basic support or hooks/SPIs from Sling itself, the rest is > more up to upstream layers). we have currently only very rough ideas here, > a proposal needs to be draftet as well. > > stefan > > >-Original Message- > >From: Jason E Bailey [mailto:jason.bai...@24601.org] > >Sent: Tuesday, September 10, 2019 6:09 PM > >To: dev@sling.apache.org > >Subject: Re: Why get rid of the rewriter? > > > >I'm positive towards the concept of the rewriter, a utility that provides > >centralized features that addresses cross-cutting concerns with user > >generated content. > > > >I'm not a fan of the current implementation of the rewriter. > > > >1. As Ruben pointed out, as of HTML5 html doesn't have anything to do > >with XML. There is no concept of namespace in HTML now. There is no self > >closing tag. There may not be an end tag. There is a concept of implied > >parent tags. > > > >2. TagSoup, which is currently used to parse the HTML, requires fully > >cached content and will attempt to validate the content and add to it, > >where appropriate. Which isn't necessary. > > > >3. The Rewriter requires the pipeline configuration to be in a specific > >place with a specific name which is inflexible and contrary to other tools > >we use. > > > > > >The point being that I would prefer to have the rewriter implementation > >deprecated in favor of a more up to date solution then having the concept > >of the rewriter deprecated. > > > > > > > >-- > >Jason > > > >On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote: > >> As was pointed out before the rewriter is used in a lot of projects for > >> other things than rewriting links (in our case we use it a lot to inject > >> legal disclaimers or content fragment models) > >> > >> The bigger problem however is that it assumes hml == xml and hence can > >not > >> deal with attributes with no value > >> > >> Ruben > >> > >> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz > > > >> wrote: > >> > >> > Hi, > >> > > >> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: > >> > > ...Can anyone summarize why we are getting rid of it?... > >> > > >> > I'm not sure if we need to "get rid" of that module, even if some > >> > portion of Sling users stops using it. > >> > > >> > The proposal at [1] says the rewriter should be "deprecated and no > >> > longer used", which is apparently what was discussed at the adaptTo > >> > round table or hackathon. > >> > > >> > If people still find the module useful I think it''s fine to move it > >> > to "contrib" status instead of deprecating. As long as there's a > >> > reasonable expectation that the module will be maintained I think > >> > that's a realistic status, but our guarantees are weak for contrib > >> > modules so there's no pressure. > >> > > >> > And if other modules provide better ways of doing similar things, link > >> > to them from the rewriter's docs. > >> > > >> > -Bertrand > >> > > >> > [1] > >> > > > > https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3 > >f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E > >> > > >> > >> > >> -- > >> thank you > >> > >> Ruben Reusser > >> CTO, headwire.com, Inc > >> > > >
Re: Why get rid of the rewriter?
@Stefan: thanks for the summary. +1 IMHO that captures the main points of the discussion well. Regards Julian On Tue, Sep 10, 2019 at 6:37 PM Stefan Seifert wrote: > > i try to write a first summary: > > - we have good use cases for a rewriter in general, but are unhappy with the > current implementation and it's way of configuration. the whole thing is a > bit "alien" to the other parts of sling. > > - a new rewriter implementation should be performant and with up-to-date > support for modern HTML. ideally something like SAX for HTML (not XML/XHTML). > this would not cover other use cases producing something other than HTML, > though. perhaps there are libraries out there that can be built upon. should > also provide modular support, e.g. rewriting only the output of a single > component or text fragment. maybe someone can come up with a proposal. > > - we have to keep the old rewriter for backward compatibility because it was > used a lot in the past, but do not plan to maintain it further and probably > will remove it from the sling starter as well. mark it as deprecated or > contrib. > > - we do no longer want to use the rewriter for link validation and > externalization, but support this as aspect in another, more appropriate way > (with some basic support or hooks/SPIs from Sling itself, the rest is more up > to upstream layers). we have currently only very rough ideas here, a proposal > needs to be draftet as well. > > stefan > > >-Original Message- > >From: Jason E Bailey [mailto:jason.bai...@24601.org] > >Sent: Tuesday, September 10, 2019 6:09 PM > >To: dev@sling.apache.org > >Subject: Re: Why get rid of the rewriter? > > > >I'm positive towards the concept of the rewriter, a utility that provides > >centralized features that addresses cross-cutting concerns with user > >generated content. > > > >I'm not a fan of the current implementation of the rewriter. > > > >1. As Ruben pointed out, as of HTML5 html doesn't have anything to do > >with XML. There is no concept of namespace in HTML now. There is no self > >closing tag. There may not be an end tag. There is a concept of implied > >parent tags. > > > >2. TagSoup, which is currently used to parse the HTML, requires fully > >cached content and will attempt to validate the content and add to it, > >where appropriate. Which isn't necessary. > > > >3. The Rewriter requires the pipeline configuration to be in a specific > >place with a specific name which is inflexible and contrary to other tools > >we use. > > > > > >The point being that I would prefer to have the rewriter implementation > >deprecated in favor of a more up to date solution then having the concept > >of the rewriter deprecated. > > > > > > > >-- > >Jason > > > >On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote: > >> As was pointed out before the rewriter is used in a lot of projects for > >> other things than rewriting links (in our case we use it a lot to inject > >> legal disclaimers or content fragment models) > >> > >> The bigger problem however is that it assumes hml == xml and hence can > >not > >> deal with attributes with no value > >> > >> Ruben > >> > >> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz > > > >> wrote: > >> > >> > Hi, > >> > > >> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: > >> > > ...Can anyone summarize why we are getting rid of it?... > >> > > >> > I'm not sure if we need to "get rid" of that module, even if some > >> > portion of Sling users stops using it. > >> > > >> > The proposal at [1] says the rewriter should be "deprecated and no > >> > longer used", which is apparently what was discussed at the adaptTo > >> > round table or hackathon. > >> > > >> > If people still find the module useful I think it''s fine to move it > >> > to "contrib" status instead of deprecating. As long as there's a > >> > reasonable expectation that the module will be maintained I think > >> > that's a realistic status, but our guarantees are weak for contrib > >> > modules so there's no pressure. > >> > > >> > And if other modules provide better ways of doing similar things, link > >> > to them from the rewriter's docs. > >> > > >> > -Bertrand > >> > > >> > [1] > >> > > >https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3 > >f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E > >> > > >> > >> > >> -- > >> thank you > >> > >> Ruben Reusser > >> CTO, headwire.com, Inc > >> > >
Re: Why get rid of the rewriter?
@Konrad: I guess it boils down to rich-text processing again. So you could argue that each component should explicitly process all its rich-text properties explicitly and dump into a data-structure held in a request attribute. It would be possible, but it would be much more invasive than post-processing the markup, especially if the capability is to be retrofitted in an application with 100+ existing components, many of which would have rich-text properties. Regards Julian On Tue, Sep 10, 2019 at 5:09 PM Konrad Windszus wrote: > > Why can footnotes not be added as request attributes (either just as a > numeric counter or a complex object depending on the use case)? > > > On 10. Sep 2019, at 16:55, Julian Sedding wrote: > > > > Another real-world use-case that was nicely solved using the rewriter > > is footnotes. Footnotes are collected by a rewriter and consecutive > > numbers injected into the markup. At the end of a page all collected > > footnote's texts were then rendered. > > > > Off the top of my head I cannot name another elegant solution for this > > problem. > > > > Granted there is extra processing due to serialising -> parsing -> > > serialising. However, I have yet to encounter a real world scenario > > where this performance cost becomes a performance problem. > > > > HTL question: could HTL be (easily) modified to generate SAX events > > instead of rendering the markup directly? That should (for HTL) allow > > getting rid of the processing overhead. Just a thought on how to solve > > the underlying issue while keeping the rewriter (maybe by allowing it > > to be hooked in differently). > > > > Regards > > Julian > > > > > > > > > > > > > > > > On Tue, Sep 10, 2019 at 4:35 PM Konrad Windszus wrote: > >> > >> The new url rewriter SPI will be perfectly supporting AOP. > >> Konrad > >> > >>> Am 10.09.2019 um 16:09 schrieb Justin Edelson : > >>> > >>> I see that the same assumptions are being made here that were made a year > >>> ago when this was discussed. I would strongly caution against assuming > >>> that > >>> the "aspect developer" and the "script developer" are the same person or > >>> even work for the same organization. The value of AOP programming styles, > >>> such as that used by the rewriter, is that these roles do not need to be > >>> aware of each other. > >>> > >>> Agree 100% that AEM should change how link rewriting is done. But that's > >>> not really Sling's concern per se with respect to the rewriter. Sling's > >>> concern should be (1) whether or not AOP has value in a component-based > >>> system (I think the answer here is a clear "yes") and (2) what the right > >>> programming model is to support AOP. To Reuben's point, it is certainly > >>> possible that SAX is the wrong programming model (I personally don't > >>> agree, > >>> but I have a very soft spot for SAX). But the answer to that IMO is to > >>> define a better programming model, not jump to the conclusion that AOP > >>> doesn't have value. > >>> > >>> Cheers, > >>> Justin > >>> > >>> On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler > >>> wrote: > >>> > The rewriter is a generic solution (for xhtml) which works independent > of the scripting engine used. However, with engines like HTL which knows > about HTML and has all the contextual information about the html > elements, it is way more efficient to do any transformation whether its > link transformations or anything else already during that step. > Reparsing with a rather expensive XML processing pipeline is flexible > but also slows down the rendering unnecessary. > > Carsten > > > Am 10.09.2019 um 14:56 schrieb Ruben Reusser: > > As was pointed out before the rewriter is used in a lot of projects for > > other things than rewriting links (in our case we use it a lot to inject > > legal disclaimers or content fragment models) > > > > The bigger problem however is that it assumes hml == xml and hence can > not > > deal with attributes with no value > > > > Ruben > > > > On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz < > bdelacre...@apache.org> > > wrote: > > > >> Hi, > >> > >>> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: > >>> ...Can anyone summarize why we are getting rid of it?... > >> > >> I'm not sure if we need to "get rid" of that module, even if some > >> portion of Sling users stops using it. > >> > >> The proposal at [1] says the rewriter should be "deprecated and no > >> longer used", which is apparently what was discussed at the adaptTo > >> round table or hackathon. > >> > >> If people still find the module useful I think it''s fine to move it > >> to "contrib" status instead of deprecating. As long as there's a > >> reasonable expectation that the module will be maintained I think > >> that's a realistic status, but our guarantees are weak for
Re: Why get rid of the rewriter?
... for urls, not for markup in general. On Tue, Sep 10, 2019 at 10:35 AM Konrad Windszus wrote: > The new url rewriter SPI will be perfectly supporting AOP. > Konrad > > > Am 10.09.2019 um 16:09 schrieb Justin Edelson >: > > > > I see that the same assumptions are being made here that were made a year > > ago when this was discussed. I would strongly caution against assuming > that > > the "aspect developer" and the "script developer" are the same person or > > even work for the same organization. The value of AOP programming styles, > > such as that used by the rewriter, is that these roles do not need to be > > aware of each other. > > > > Agree 100% that AEM should change how link rewriting is done. But that's > > not really Sling's concern per se with respect to the rewriter. Sling's > > concern should be (1) whether or not AOP has value in a component-based > > system (I think the answer here is a clear "yes") and (2) what the right > > programming model is to support AOP. To Reuben's point, it is certainly > > possible that SAX is the wrong programming model (I personally don't > agree, > > but I have a very soft spot for SAX). But the answer to that IMO is to > > define a better programming model, not jump to the conclusion that AOP > > doesn't have value. > > > > Cheers, > > Justin > > > > On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler > > wrote: > > > >> The rewriter is a generic solution (for xhtml) which works independent > >> of the scripting engine used. However, with engines like HTL which knows > >> about HTML and has all the contextual information about the html > >> elements, it is way more efficient to do any transformation whether its > >> link transformations or anything else already during that step. > >> Reparsing with a rather expensive XML processing pipeline is flexible > >> but also slows down the rendering unnecessary. > >> > >> Carsten > >> > >>> Am 10.09.2019 um 14:56 schrieb Ruben Reusser: > >>> As was pointed out before the rewriter is used in a lot of projects for > >>> other things than rewriting links (in our case we use it a lot to > inject > >>> legal disclaimers or content fragment models) > >>> > >>> The bigger problem however is that it assumes hml == xml and hence can > >> not > >>> deal with attributes with no value > >>> > >>> Ruben > >>> > >>> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz < > >> bdelacre...@apache.org> > >>> wrote: > >>> > Hi, > > > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey > wrote: > > ...Can anyone summarize why we are getting rid of it?... > > I'm not sure if we need to "get rid" of that module, even if some > portion of Sling users stops using it. > > The proposal at [1] says the rewriter should be "deprecated and no > longer used", which is apparently what was discussed at the adaptTo > round table or hackathon. > > If people still find the module useful I think it''s fine to move it > to "contrib" status instead of deprecating. As long as there's a > reasonable expectation that the module will be maintained I think > that's a realistic status, but our guarantees are weak for contrib > modules so there's no pressure. > > And if other modules provide better ways of doing similar things, link > to them from the rewriter's docs. > > -Bertrand > > [1] > > >> > https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E > > >>> > >>> > >> > >> -- > >> -- > >> Carsten Ziegeler > >> Adobe Research Switzerland > >> cziege...@apache.org > >> > >
Re: Why get rid of the rewriter?
Sounds good to me, now for the rewriter I would like to have something more special geared towards html thank a generic thing like SAX. So basically instead of getting the information that the element name is "a" and then you have to figure out that this is a link, you already get the information this is a "LINK" or a "SRC" or whatever. Regards Carsten Am 10.09.2019 um 18:37 schrieb Stefan Seifert: i try to write a first summary: - we have good use cases for a rewriter in general, but are unhappy with the current implementation and it's way of configuration. the whole thing is a bit "alien" to the other parts of sling. - a new rewriter implementation should be performant and with up-to-date support for modern HTML. ideally something like SAX for HTML (not XML/XHTML). this would not cover other use cases producing something other than HTML, though. perhaps there are libraries out there that can be built upon. should also provide modular support, e.g. rewriting only the output of a single component or text fragment. maybe someone can come up with a proposal. - we have to keep the old rewriter for backward compatibility because it was used a lot in the past, but do not plan to maintain it further and probably will remove it from the sling starter as well. mark it as deprecated or contrib. - we do no longer want to use the rewriter for link validation and externalization, but support this as aspect in another, more appropriate way (with some basic support or hooks/SPIs from Sling itself, the rest is more up to upstream layers). we have currently only very rough ideas here, a proposal needs to be draftet as well. stefan -Original Message- From: Jason E Bailey [mailto:jason.bai...@24601.org] Sent: Tuesday, September 10, 2019 6:09 PM To: dev@sling.apache.org Subject: Re: Why get rid of the rewriter? I'm positive towards the concept of the rewriter, a utility that provides centralized features that addresses cross-cutting concerns with user generated content. I'm not a fan of the current implementation of the rewriter. 1. As Ruben pointed out, as of HTML5 html doesn't have anything to do with XML. There is no concept of namespace in HTML now. There is no self closing tag. There may not be an end tag. There is a concept of implied parent tags. 2. TagSoup, which is currently used to parse the HTML, requires fully cached content and will attempt to validate the content and add to it, where appropriate. Which isn't necessary. 3. The Rewriter requires the pipeline configuration to be in a specific place with a specific name which is inflexible and contrary to other tools we use. The point being that I would prefer to have the rewriter implementation deprecated in favor of a more up to date solution then having the concept of the rewriter deprecated. -- Jason On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote: As was pointed out before the rewriter is used in a lot of projects for other things than rewriting links (in our case we use it a lot to inject legal disclaimers or content fragment models) The bigger problem however is that it assumes hml == xml and hence can not deal with attributes with no value Ruben On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz wrote: Hi, On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: ...Can anyone summarize why we are getting rid of it?... I'm not sure if we need to "get rid" of that module, even if some portion of Sling users stops using it. The proposal at [1] says the rewriter should be "deprecated and no longer used", which is apparently what was discussed at the adaptTo round table or hackathon. If people still find the module useful I think it''s fine to move it to "contrib" status instead of deprecating. As long as there's a reasonable expectation that the module will be maintained I think that's a realistic status, but our guarantees are weak for contrib modules so there's no pressure. And if other modules provide better ways of doing similar things, link to them from the rewriter's docs. -Bertrand [1] https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3 f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E -- thank you Ruben Reusser CTO, headwire.com, Inc -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Why get rid of the rewriter?
+1 for the summary -- Jason On Tue, Sep 10, 2019, at 12:37 PM, Stefan Seifert wrote: > i try to write a first summary: > > - we have good use cases for a rewriter in general, but are unhappy > with the current implementation and it's way of configuration. the > whole thing is a bit "alien" to the other parts of sling. > > - a new rewriter implementation should be performant and with > up-to-date support for modern HTML. ideally something like SAX for HTML > (not XML/XHTML). this would not cover other use cases producing > something other than HTML, though. perhaps there are libraries out > there that can be built upon. should also provide modular support, e.g. > rewriting only the output of a single component or text fragment. maybe > someone can come up with a proposal. > > - we have to keep the old rewriter for backward compatibility because > it was used a lot in the past, but do not plan to maintain it further > and probably will remove it from the sling starter as well. mark it as > deprecated or contrib. > > - we do no longer want to use the rewriter for link validation and > externalization, but support this as aspect in another, more > appropriate way (with some basic support or hooks/SPIs from Sling > itself, the rest is more up to upstream layers). we have currently only > very rough ideas here, a proposal needs to be draftet as well. > > stefan > > >-Original Message- > >From: Jason E Bailey [mailto:jason.bai...@24601.org] > >Sent: Tuesday, September 10, 2019 6:09 PM > >To: dev@sling.apache.org > >Subject: Re: Why get rid of the rewriter? > > > >I'm positive towards the concept of the rewriter, a utility that provides > >centralized features that addresses cross-cutting concerns with user > >generated content. > > > >I'm not a fan of the current implementation of the rewriter. > > > >1. As Ruben pointed out, as of HTML5 html doesn't have anything to do > >with XML. There is no concept of namespace in HTML now. There is no self > >closing tag. There may not be an end tag. There is a concept of implied > >parent tags. > > > >2. TagSoup, which is currently used to parse the HTML, requires fully > >cached content and will attempt to validate the content and add to it, > >where appropriate. Which isn't necessary. > > > >3. The Rewriter requires the pipeline configuration to be in a specific > >place with a specific name which is inflexible and contrary to other tools > >we use. > > > > > >The point being that I would prefer to have the rewriter implementation > >deprecated in favor of a more up to date solution then having the concept > >of the rewriter deprecated. > > > > > > > >-- > >Jason > > > >On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote: > >> As was pointed out before the rewriter is used in a lot of projects for > >> other things than rewriting links (in our case we use it a lot to inject > >> legal disclaimers or content fragment models) > >> > >> The bigger problem however is that it assumes hml == xml and hence can > >not > >> deal with attributes with no value > >> > >> Ruben > >> > >> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz > > > >> wrote: > >> > >> > Hi, > >> > > >> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: > >> > > ...Can anyone summarize why we are getting rid of it?... > >> > > >> > I'm not sure if we need to "get rid" of that module, even if some > >> > portion of Sling users stops using it. > >> > > >> > The proposal at [1] says the rewriter should be "deprecated and no > >> > longer used", which is apparently what was discussed at the adaptTo > >> > round table or hackathon. > >> > > >> > If people still find the module useful I think it''s fine to move it > >> > to "contrib" status instead of deprecating. As long as there's a > >> > reasonable expectation that the module will be maintained I think > >> > that's a realistic status, but our guarantees are weak for contrib > >> > modules so there's no pressure. > >> > > >> > And if other modules provide better ways of doing similar things, link > >> > to them from the rewriter's docs. > >> > > >> > -Bertrand > >> > > >> > [1] > >> > > >https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3 > >f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E > >> > > >> > >> > >> -- > >> thank you > >> > >> Ruben Reusser > >> CTO, headwire.com, Inc > >> > > >
RE: Why get rid of the rewriter?
i try to write a first summary: - we have good use cases for a rewriter in general, but are unhappy with the current implementation and it's way of configuration. the whole thing is a bit "alien" to the other parts of sling. - a new rewriter implementation should be performant and with up-to-date support for modern HTML. ideally something like SAX for HTML (not XML/XHTML). this would not cover other use cases producing something other than HTML, though. perhaps there are libraries out there that can be built upon. should also provide modular support, e.g. rewriting only the output of a single component or text fragment. maybe someone can come up with a proposal. - we have to keep the old rewriter for backward compatibility because it was used a lot in the past, but do not plan to maintain it further and probably will remove it from the sling starter as well. mark it as deprecated or contrib. - we do no longer want to use the rewriter for link validation and externalization, but support this as aspect in another, more appropriate way (with some basic support or hooks/SPIs from Sling itself, the rest is more up to upstream layers). we have currently only very rough ideas here, a proposal needs to be draftet as well. stefan >-Original Message- >From: Jason E Bailey [mailto:jason.bai...@24601.org] >Sent: Tuesday, September 10, 2019 6:09 PM >To: dev@sling.apache.org >Subject: Re: Why get rid of the rewriter? > >I'm positive towards the concept of the rewriter, a utility that provides >centralized features that addresses cross-cutting concerns with user >generated content. > >I'm not a fan of the current implementation of the rewriter. > >1. As Ruben pointed out, as of HTML5 html doesn't have anything to do >with XML. There is no concept of namespace in HTML now. There is no self >closing tag. There may not be an end tag. There is a concept of implied >parent tags. > >2. TagSoup, which is currently used to parse the HTML, requires fully >cached content and will attempt to validate the content and add to it, >where appropriate. Which isn't necessary. > >3. The Rewriter requires the pipeline configuration to be in a specific >place with a specific name which is inflexible and contrary to other tools >we use. > > >The point being that I would prefer to have the rewriter implementation >deprecated in favor of a more up to date solution then having the concept >of the rewriter deprecated. > > > >-- >Jason > >On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote: >> As was pointed out before the rewriter is used in a lot of projects for >> other things than rewriting links (in our case we use it a lot to inject >> legal disclaimers or content fragment models) >> >> The bigger problem however is that it assumes hml == xml and hence can >not >> deal with attributes with no value >> >> Ruben >> >> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz > >> wrote: >> >> > Hi, >> > >> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: >> > > ...Can anyone summarize why we are getting rid of it?... >> > >> > I'm not sure if we need to "get rid" of that module, even if some >> > portion of Sling users stops using it. >> > >> > The proposal at [1] says the rewriter should be "deprecated and no >> > longer used", which is apparently what was discussed at the adaptTo >> > round table or hackathon. >> > >> > If people still find the module useful I think it''s fine to move it >> > to "contrib" status instead of deprecating. As long as there's a >> > reasonable expectation that the module will be maintained I think >> > that's a realistic status, but our guarantees are weak for contrib >> > modules so there's no pressure. >> > >> > And if other modules provide better ways of doing similar things, link >> > to them from the rewriter's docs. >> > >> > -Bertrand >> > >> > [1] >> > >https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3 >f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E >> > >> >> >> -- >> thank you >> >> Ruben Reusser >> CTO, headwire.com, Inc >>
Re: Why get rid of the rewriter?
I'm positive towards the concept of the rewriter, a utility that provides centralized features that addresses cross-cutting concerns with user generated content. I'm not a fan of the current implementation of the rewriter. 1. As Ruben pointed out, as of HTML5 html doesn't have anything to do with XML. There is no concept of namespace in HTML now. There is no self closing tag. There may not be an end tag. There is a concept of implied parent tags. 2. TagSoup, which is currently used to parse the HTML, requires fully cached content and will attempt to validate the content and add to it, where appropriate. Which isn't necessary. 3. The Rewriter requires the pipeline configuration to be in a specific place with a specific name which is inflexible and contrary to other tools we use. The point being that I would prefer to have the rewriter implementation deprecated in favor of a more up to date solution then having the concept of the rewriter deprecated. -- Jason On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote: > As was pointed out before the rewriter is used in a lot of projects for > other things than rewriting links (in our case we use it a lot to inject > legal disclaimers or content fragment models) > > The bigger problem however is that it assumes hml == xml and hence can not > deal with attributes with no value > > Ruben > > On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz > wrote: > > > Hi, > > > > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: > > > ...Can anyone summarize why we are getting rid of it?... > > > > I'm not sure if we need to "get rid" of that module, even if some > > portion of Sling users stops using it. > > > > The proposal at [1] says the rewriter should be "deprecated and no > > longer used", which is apparently what was discussed at the adaptTo > > round table or hackathon. > > > > If people still find the module useful I think it''s fine to move it > > to "contrib" status instead of deprecating. As long as there's a > > reasonable expectation that the module will be maintained I think > > that's a realistic status, but our guarantees are weak for contrib > > modules so there's no pressure. > > > > And if other modules provide better ways of doing similar things, link > > to them from the rewriter's docs. > > > > -Bertrand > > > > [1] > > https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E > > > > > -- > thank you > > Ruben Reusser > CTO, headwire.com, Inc >
Re: Why get rid of the rewriter?
Why can footnotes not be added as request attributes (either just as a numeric counter or a complex object depending on the use case)? > On 10. Sep 2019, at 16:55, Julian Sedding wrote: > > Another real-world use-case that was nicely solved using the rewriter > is footnotes. Footnotes are collected by a rewriter and consecutive > numbers injected into the markup. At the end of a page all collected > footnote's texts were then rendered. > > Off the top of my head I cannot name another elegant solution for this > problem. > > Granted there is extra processing due to serialising -> parsing -> > serialising. However, I have yet to encounter a real world scenario > where this performance cost becomes a performance problem. > > HTL question: could HTL be (easily) modified to generate SAX events > instead of rendering the markup directly? That should (for HTL) allow > getting rid of the processing overhead. Just a thought on how to solve > the underlying issue while keeping the rewriter (maybe by allowing it > to be hooked in differently). > > Regards > Julian > > > > > > > > On Tue, Sep 10, 2019 at 4:35 PM Konrad Windszus wrote: >> >> The new url rewriter SPI will be perfectly supporting AOP. >> Konrad >> >>> Am 10.09.2019 um 16:09 schrieb Justin Edelson : >>> >>> I see that the same assumptions are being made here that were made a year >>> ago when this was discussed. I would strongly caution against assuming that >>> the "aspect developer" and the "script developer" are the same person or >>> even work for the same organization. The value of AOP programming styles, >>> such as that used by the rewriter, is that these roles do not need to be >>> aware of each other. >>> >>> Agree 100% that AEM should change how link rewriting is done. But that's >>> not really Sling's concern per se with respect to the rewriter. Sling's >>> concern should be (1) whether or not AOP has value in a component-based >>> system (I think the answer here is a clear "yes") and (2) what the right >>> programming model is to support AOP. To Reuben's point, it is certainly >>> possible that SAX is the wrong programming model (I personally don't agree, >>> but I have a very soft spot for SAX). But the answer to that IMO is to >>> define a better programming model, not jump to the conclusion that AOP >>> doesn't have value. >>> >>> Cheers, >>> Justin >>> >>> On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler >>> wrote: >>> The rewriter is a generic solution (for xhtml) which works independent of the scripting engine used. However, with engines like HTL which knows about HTML and has all the contextual information about the html elements, it is way more efficient to do any transformation whether its link transformations or anything else already during that step. Reparsing with a rather expensive XML processing pipeline is flexible but also slows down the rendering unnecessary. Carsten > Am 10.09.2019 um 14:56 schrieb Ruben Reusser: > As was pointed out before the rewriter is used in a lot of projects for > other things than rewriting links (in our case we use it a lot to inject > legal disclaimers or content fragment models) > > The bigger problem however is that it assumes hml == xml and hence can not > deal with attributes with no value > > Ruben > > On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz < bdelacre...@apache.org> > wrote: > >> Hi, >> >>> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: >>> ...Can anyone summarize why we are getting rid of it?... >> >> I'm not sure if we need to "get rid" of that module, even if some >> portion of Sling users stops using it. >> >> The proposal at [1] says the rewriter should be "deprecated and no >> longer used", which is apparently what was discussed at the adaptTo >> round table or hackathon. >> >> If people still find the module useful I think it''s fine to move it >> to "contrib" status instead of deprecating. As long as there's a >> reasonable expectation that the module will be maintained I think >> that's a realistic status, but our guarantees are weak for contrib >> modules so there's no pressure. >> >> And if other modules provide better ways of doing similar things, link >> to them from the rewriter's docs. >> >> -Bertrand >> >> [1] >> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E >> > > -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org >>
Re: Why get rid of the rewriter?
Another real-world use-case that was nicely solved using the rewriter is footnotes. Footnotes are collected by a rewriter and consecutive numbers injected into the markup. At the end of a page all collected footnote's texts were then rendered. Off the top of my head I cannot name another elegant solution for this problem. Granted there is extra processing due to serialising -> parsing -> serialising. However, I have yet to encounter a real world scenario where this performance cost becomes a performance problem. HTL question: could HTL be (easily) modified to generate SAX events instead of rendering the markup directly? That should (for HTL) allow getting rid of the processing overhead. Just a thought on how to solve the underlying issue while keeping the rewriter (maybe by allowing it to be hooked in differently). Regards Julian On Tue, Sep 10, 2019 at 4:35 PM Konrad Windszus wrote: > > The new url rewriter SPI will be perfectly supporting AOP. > Konrad > > > Am 10.09.2019 um 16:09 schrieb Justin Edelson : > > > > I see that the same assumptions are being made here that were made a year > > ago when this was discussed. I would strongly caution against assuming that > > the "aspect developer" and the "script developer" are the same person or > > even work for the same organization. The value of AOP programming styles, > > such as that used by the rewriter, is that these roles do not need to be > > aware of each other. > > > > Agree 100% that AEM should change how link rewriting is done. But that's > > not really Sling's concern per se with respect to the rewriter. Sling's > > concern should be (1) whether or not AOP has value in a component-based > > system (I think the answer here is a clear "yes") and (2) what the right > > programming model is to support AOP. To Reuben's point, it is certainly > > possible that SAX is the wrong programming model (I personally don't agree, > > but I have a very soft spot for SAX). But the answer to that IMO is to > > define a better programming model, not jump to the conclusion that AOP > > doesn't have value. > > > > Cheers, > > Justin > > > > On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler > > wrote: > > > >> The rewriter is a generic solution (for xhtml) which works independent > >> of the scripting engine used. However, with engines like HTL which knows > >> about HTML and has all the contextual information about the html > >> elements, it is way more efficient to do any transformation whether its > >> link transformations or anything else already during that step. > >> Reparsing with a rather expensive XML processing pipeline is flexible > >> but also slows down the rendering unnecessary. > >> > >> Carsten > >> > >>> Am 10.09.2019 um 14:56 schrieb Ruben Reusser: > >>> As was pointed out before the rewriter is used in a lot of projects for > >>> other things than rewriting links (in our case we use it a lot to inject > >>> legal disclaimers or content fragment models) > >>> > >>> The bigger problem however is that it assumes hml == xml and hence can > >> not > >>> deal with attributes with no value > >>> > >>> Ruben > >>> > >>> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz < > >> bdelacre...@apache.org> > >>> wrote: > >>> > Hi, > > > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: > > ...Can anyone summarize why we are getting rid of it?... > > I'm not sure if we need to "get rid" of that module, even if some > portion of Sling users stops using it. > > The proposal at [1] says the rewriter should be "deprecated and no > longer used", which is apparently what was discussed at the adaptTo > round table or hackathon. > > If people still find the module useful I think it''s fine to move it > to "contrib" status instead of deprecating. As long as there's a > reasonable expectation that the module will be maintained I think > that's a realistic status, but our guarantees are weak for contrib > modules so there's no pressure. > > And if other modules provide better ways of doing similar things, link > to them from the rewriter's docs. > > -Bertrand > > [1] > > >> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E > > >>> > >>> > >> > >> -- > >> -- > >> Carsten Ziegeler > >> Adobe Research Switzerland > >> cziege...@apache.org > >> >
Re: Why get rid of the rewriter?
The new url rewriter SPI will be perfectly supporting AOP. Konrad > Am 10.09.2019 um 16:09 schrieb Justin Edelson : > > I see that the same assumptions are being made here that were made a year > ago when this was discussed. I would strongly caution against assuming that > the "aspect developer" and the "script developer" are the same person or > even work for the same organization. The value of AOP programming styles, > such as that used by the rewriter, is that these roles do not need to be > aware of each other. > > Agree 100% that AEM should change how link rewriting is done. But that's > not really Sling's concern per se with respect to the rewriter. Sling's > concern should be (1) whether or not AOP has value in a component-based > system (I think the answer here is a clear "yes") and (2) what the right > programming model is to support AOP. To Reuben's point, it is certainly > possible that SAX is the wrong programming model (I personally don't agree, > but I have a very soft spot for SAX). But the answer to that IMO is to > define a better programming model, not jump to the conclusion that AOP > doesn't have value. > > Cheers, > Justin > > On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler > wrote: > >> The rewriter is a generic solution (for xhtml) which works independent >> of the scripting engine used. However, with engines like HTL which knows >> about HTML and has all the contextual information about the html >> elements, it is way more efficient to do any transformation whether its >> link transformations or anything else already during that step. >> Reparsing with a rather expensive XML processing pipeline is flexible >> but also slows down the rendering unnecessary. >> >> Carsten >> >>> Am 10.09.2019 um 14:56 schrieb Ruben Reusser: >>> As was pointed out before the rewriter is used in a lot of projects for >>> other things than rewriting links (in our case we use it a lot to inject >>> legal disclaimers or content fragment models) >>> >>> The bigger problem however is that it assumes hml == xml and hence can >> not >>> deal with attributes with no value >>> >>> Ruben >>> >>> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz < >> bdelacre...@apache.org> >>> wrote: >>> Hi, > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: > ...Can anyone summarize why we are getting rid of it?... I'm not sure if we need to "get rid" of that module, even if some portion of Sling users stops using it. The proposal at [1] says the rewriter should be "deprecated and no longer used", which is apparently what was discussed at the adaptTo round table or hackathon. If people still find the module useful I think it''s fine to move it to "contrib" status instead of deprecating. As long as there's a reasonable expectation that the module will be maintained I think that's a realistic status, but our guarantees are weak for contrib modules so there's no pressure. And if other modules provide better ways of doing similar things, link to them from the rewriter's docs. -Bertrand [1] >> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E >>> >>> >> >> -- >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org >>
Re: Why get rid of the rewriter?
I see that the same assumptions are being made here that were made a year ago when this was discussed. I would strongly caution against assuming that the "aspect developer" and the "script developer" are the same person or even work for the same organization. The value of AOP programming styles, such as that used by the rewriter, is that these roles do not need to be aware of each other. Agree 100% that AEM should change how link rewriting is done. But that's not really Sling's concern per se with respect to the rewriter. Sling's concern should be (1) whether or not AOP has value in a component-based system (I think the answer here is a clear "yes") and (2) what the right programming model is to support AOP. To Reuben's point, it is certainly possible that SAX is the wrong programming model (I personally don't agree, but I have a very soft spot for SAX). But the answer to that IMO is to define a better programming model, not jump to the conclusion that AOP doesn't have value. Cheers, Justin On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler wrote: > The rewriter is a generic solution (for xhtml) which works independent > of the scripting engine used. However, with engines like HTL which knows > about HTML and has all the contextual information about the html > elements, it is way more efficient to do any transformation whether its > link transformations or anything else already during that step. > Reparsing with a rather expensive XML processing pipeline is flexible > but also slows down the rendering unnecessary. > > Carsten > > Am 10.09.2019 um 14:56 schrieb Ruben Reusser: > > As was pointed out before the rewriter is used in a lot of projects for > > other things than rewriting links (in our case we use it a lot to inject > > legal disclaimers or content fragment models) > > > > The bigger problem however is that it assumes hml == xml and hence can > not > > deal with attributes with no value > > > > Ruben > > > > On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz < > bdelacre...@apache.org> > > wrote: > > > >> Hi, > >> > >> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: > >>> ...Can anyone summarize why we are getting rid of it?... > >> > >> I'm not sure if we need to "get rid" of that module, even if some > >> portion of Sling users stops using it. > >> > >> The proposal at [1] says the rewriter should be "deprecated and no > >> longer used", which is apparently what was discussed at the adaptTo > >> round table or hackathon. > >> > >> If people still find the module useful I think it''s fine to move it > >> to "contrib" status instead of deprecating. As long as there's a > >> reasonable expectation that the module will be maintained I think > >> that's a realistic status, but our guarantees are weak for contrib > >> modules so there's no pressure. > >> > >> And if other modules provide better ways of doing similar things, link > >> to them from the rewriter's docs. > >> > >> -Bertrand > >> > >> [1] > >> > https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E > >> > > > > > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
Re: Why get rid of the rewriter?
The rewriter is a generic solution (for xhtml) which works independent of the scripting engine used. However, with engines like HTL which knows about HTML and has all the contextual information about the html elements, it is way more efficient to do any transformation whether its link transformations or anything else already during that step. Reparsing with a rather expensive XML processing pipeline is flexible but also slows down the rendering unnecessary. Carsten Am 10.09.2019 um 14:56 schrieb Ruben Reusser: As was pointed out before the rewriter is used in a lot of projects for other things than rewriting links (in our case we use it a lot to inject legal disclaimers or content fragment models) The bigger problem however is that it assumes hml == xml and hence can not deal with attributes with no value Ruben On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz wrote: Hi, On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: ...Can anyone summarize why we are getting rid of it?... I'm not sure if we need to "get rid" of that module, even if some portion of Sling users stops using it. The proposal at [1] says the rewriter should be "deprecated and no longer used", which is apparently what was discussed at the adaptTo round table or hackathon. If people still find the module useful I think it''s fine to move it to "contrib" status instead of deprecating. As long as there's a reasonable expectation that the module will be maintained I think that's a realistic status, but our guarantees are weak for contrib modules so there's no pressure. And if other modules provide better ways of doing similar things, link to them from the rewriter's docs. -Bertrand [1] https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Why get rid of the rewriter?
As was pointed out before the rewriter is used in a lot of projects for other things than rewriting links (in our case we use it a lot to inject legal disclaimers or content fragment models) The bigger problem however is that it assumes hml == xml and hence can not deal with attributes with no value Ruben On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz wrote: > Hi, > > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: > > ...Can anyone summarize why we are getting rid of it?... > > I'm not sure if we need to "get rid" of that module, even if some > portion of Sling users stops using it. > > The proposal at [1] says the rewriter should be "deprecated and no > longer used", which is apparently what was discussed at the adaptTo > round table or hackathon. > > If people still find the module useful I think it''s fine to move it > to "contrib" status instead of deprecating. As long as there's a > reasonable expectation that the module will be maintained I think > that's a realistic status, but our guarantees are weak for contrib > modules so there's no pressure. > > And if other modules provide better ways of doing similar things, link > to them from the rewriter's docs. > > -Bertrand > > [1] > https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E > -- thank you Ruben Reusser CTO, headwire.com, Inc
Re: Why get rid of the rewriter?
Hi, On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey wrote: > ...Can anyone summarize why we are getting rid of it?... I'm not sure if we need to "get rid" of that module, even if some portion of Sling users stops using it. The proposal at [1] says the rewriter should be "deprecated and no longer used", which is apparently what was discussed at the adaptTo round table or hackathon. If people still find the module useful I think it''s fine to move it to "contrib" status instead of deprecating. As long as there's a reasonable expectation that the module will be maintained I think that's a realistic status, but our guarantees are weak for contrib modules so there's no pressure. And if other modules provide better ways of doing similar things, link to them from the rewriter's docs. -Bertrand [1] https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
RE: Why get rid of the rewriter?
>What is the solution for rewriting URLs contained within the output of a >rich text editor? Similar to https://wcm.io/handler/richtext/? I hope that >downstream implementers of Sling will provide a pathway for replacing the >rewriter if it is removed. I would speculate this would result in a >tremendous amount of work to fix / test on upgrade for many >implementations. yes, you still need solutions for rich text components, and there a post processing is valid - but only for the rich text this component outputs, with full awareness of the context and it's configuration. stefan
Re: Why get rid of the rewriter?
I also used rewriting for various use cases ( for example creating disclaimer links at the bottom of the page based on whats on the page) To be honest, its just a nice wrapper around a filter, if you would take it away, people would just create a filter on page level that captures the response and do all the stuff afterwards, so I dont see any difference / better way being proposed yet. But if there is a better way, wouldnt mind hearing it! Van: Daniel Klco Verzonden: dinsdag, september 10, 2019 3:29 AM Aan: dev@sling.apache.org Onderwerp: Re: Why get rid of the rewriter? What is the solution for rewriting URLs contained within the output of a rich text editor? Similar to https://wcm.io/handler/richtext/? I hope that downstream implementers of Sling will provide a pathway for replacing the rewriter if it is removed. I would speculate this would result in a tremendous amount of work to fix / test on upgrade for many implementations. I agree the AEM Link Checker is a bad idea, though I argue that has to do more with the concept of removing links at runtime than the way it is implemented. While the rewriter is not the most efficient method, but it does give you the ability to affect the entire page structure in one go vs. having to handle it on a per-component, resource type or field basis. The problem I see with most implementations of Sling using the rewriter is they do not give enough control of how the rewriter operates. I've been using this with the Sling CMS reference, for example to allow for whitelisting attributes and elements on a per-site basis using Sling CA Configs: https://github.com/apache/sling-org-apache-sling-app-cms/blob/master/docs/configure-site.md#rewrite-configuration On Mon, Sep 9, 2019, 5:52 PM Stefan Seifert wrote: > 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 > > >
Re: Why get rid of the rewriter?
What is the solution for rewriting URLs contained within the output of a rich text editor? Similar to https://wcm.io/handler/richtext/? I hope that downstream implementers of Sling will provide a pathway for replacing the rewriter if it is removed. I would speculate this would result in a tremendous amount of work to fix / test on upgrade for many implementations. I agree the AEM Link Checker is a bad idea, though I argue that has to do more with the concept of removing links at runtime than the way it is implemented. While the rewriter is not the most efficient method, but it does give you the ability to affect the entire page structure in one go vs. having to handle it on a per-component, resource type or field basis. The problem I see with most implementations of Sling using the rewriter is they do not give enough control of how the rewriter operates. I've been using this with the Sling CMS reference, for example to allow for whitelisting attributes and elements on a per-site basis using Sling CA Configs: https://github.com/apache/sling-org-apache-sling-app-cms/blob/master/docs/configure-site.md#rewrite-configuration On Mon, Sep 9, 2019, 5:52 PM Stefan Seifert wrote: > 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 > > >
RE: Why get rid of the rewriter?
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
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
