> >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 provi
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
@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
... 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
ent: 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 imple
t; >-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 rewri
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
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
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
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
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"
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,
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
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
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
>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
gt; 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-----
&
ts.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 Bail
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
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
20 matches
Mail list logo