@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 <konra...@gmx.de> 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 <jsedd...@gmail.com> 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 <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 > >>>> > >> >
