Why get rid of the rewriter?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Why get rid of the rewriter?

Jason E Bailey-2
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
Reply | Threaded
Open this post in threaded view
|

RE: Why get rid of the rewriter?

Stefan Seifert
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:[hidden email]]
>Sent: Monday, September 9, 2019 3:07 PM
>To: [hidden email]
>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


Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

Daniel Klco-2
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 <[hidden email]> 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:[hidden email]]
> >Sent: Monday, September 9, 2019 3:07 PM
> >To: [hidden email]
> >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
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

Roy Teeuwen
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 <[hidden email]>
Verzonden: dinsdag, september 10, 2019 3:29 AM
Aan: [hidden email]
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 <[hidden email]> 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:[hidden email]]
> >Sent: Monday, September 9, 2019 3:07 PM
> >To: [hidden email]
> >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
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: Why get rid of the rewriter?

Stefan Seifert
In reply to this post by Daniel Klco-2

>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
Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

Bertrand Delacretaz
In reply to this post by Jason E Bailey-2
Hi,

On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

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 <[hidden email]>
wrote:

> Hi,
>
> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

Carsten Ziegeler
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 <[hidden email]>
> wrote:
>
>> Hi,
>>
>> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

justzzzz
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 <[hidden email]>
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 <
> [hidden email]>
> > wrote:
> >
> >> Hi,
> >>
> >> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
> [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

Konrad Windszus
The new url rewriter SPI will be perfectly supporting AOP.
Konrad

> Am 10.09.2019 um 16:09 schrieb Justin Edelson <[hidden email]>:
>
> 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 <[hidden email]>
> 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 <
>> [hidden email]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
>> [hidden email]
>>

Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

Julian Sedding-3
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 <[hidden email]> wrote:

>
> The new url rewriter SPI will be perfectly supporting AOP.
> Konrad
>
> > Am 10.09.2019 um 16:09 schrieb Justin Edelson <[hidden email]>:
> >
> > 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 <[hidden email]>
> > 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 <
> >> [hidden email]>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>>> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
> >> [hidden email]
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

Konrad Windszus
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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> The new url rewriter SPI will be perfectly supporting AOP.
>> Konrad
>>
>>> Am 10.09.2019 um 16:09 schrieb Justin Edelson <[hidden email]>:
>>>
>>> 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 <[hidden email]>
>>> 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 <
>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
>>>> [hidden email]
>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

Jason E Bailey
In reply to this post by Ruben Reusser
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 <[hidden email]>
> wrote:
>
> > Hi,
> >
> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

RE: Why get rid of the rewriter?

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:[hidden email]]
>Sent: Tuesday, September 10, 2019 6:09 PM
>To: [hidden email]
>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
><[hidden email]>
>> wrote:
>>
>> > Hi,
>> >
>> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
>>


Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

Jason E Bailey
+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:[hidden email]]
> >Sent: Tuesday, September 10, 2019 6:09 PM
> >To: [hidden email]
> >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
> ><[hidden email]>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
> >>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

Carsten Ziegeler
In reply to this post by Stefan Seifert
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:[hidden email]]
>> Sent: Tuesday, September 10, 2019 6:09 PM
>> To: [hidden email]
>> 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
>> <[hidden email]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

justzzzz
In reply to this post by Konrad Windszus
... for urls, not for markup in general.

On Tue, Sep 10, 2019 at 10:35 AM Konrad Windszus <[hidden email]> wrote:

> The new url rewriter SPI will be perfectly supporting AOP.
> Konrad
>
> > Am 10.09.2019 um 16:09 schrieb Justin Edelson <[hidden email]
> >:
> >
> > 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 <[hidden email]>
> > 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 <
> >> [hidden email]>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>>> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]>
> 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
> >> [hidden email]
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

Julian Sedding-3
In reply to this post by Konrad Windszus
@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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
> >>
> >> The new url rewriter SPI will be perfectly supporting AOP.
> >> Konrad
> >>
> >>> Am 10.09.2019 um 16:09 schrieb Justin Edelson <[hidden email]>:
> >>>
> >>> 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 <[hidden email]>
> >>> 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 <
> >>>> [hidden email]>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
> >>>> [hidden email]
> >>>>
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

Julian Sedding-3
In reply to this post by Stefan Seifert
@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 <[hidden email]> 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:[hidden email]]
> >Sent: Tuesday, September 10, 2019 6:09 PM
> >To: [hidden email]
> >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
> ><[hidden email]>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Why get rid of the rewriter?

justzzzz
In reply to this post by Stefan Seifert
+1 great summary.

On Tue, Sep 10, 2019 at 12:37 PM Stefan Seifert <[hidden email]>
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:[hidden email]]
> >Sent: Tuesday, September 10, 2019 6:09 PM
> >To: [hidden email]
> >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
> ><[hidden email]>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey <[hidden email]> 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
> >>
>
>
>