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 >>>> >>
