... for urls, not for markup in general. On Tue, Sep 10, 2019 at 10:35 AM Konrad Windszus <konra...@gmx.de> wrote:
> The new url rewriter SPI will be perfectly supporting AOP. > Konrad > > > Am 10.09.2019 um 16:09 schrieb Justin Edelson <jus...@justinedelson.com > >: > > > > 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 <cziege...@apache.org> > > 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 <j...@apache.org> > 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 > >> > >
