[jira] [Closed] (SLING-7586) [Sling Models] Memory Leak in cached adapters

[Dan Klco (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Klco closed SLING-7586.
---

> [Sling Models] Memory Leak in cached adapters
> -
>
> Key: SLING-7586
> URL: https://issues.apache.org/jira/browse/SLING-7586
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.4.0, Sling Models Impl 1.4.2, Sling 
> Models Impl 1.4.4, Sling Models Impl 1.4.6, Sling Models Impl 1.4.8
>Reporter: Justin Edelson
>Assignee: Dan Klco
>Priority: Major
> Fix For: Sling Models Impl 1.4.10
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> There is a potential memory leak in the adapterCache in ModelAdapterFactory 
> when the model class references the adaptable. The solution is to wrap the 
> model object in a WeakReference. That ensures that the model can be GC'd and 
> then the key can be GC'd.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SLING-7603) Add missing OSGi capabilities

[Dan Klco (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Klco closed SLING-7603.
---

> Add missing OSGi capabilities
> -
>
> Key: SLING-7603
> URL: https://issues.apache.org/jira/browse/SLING-7603
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Sling Models Impl 1.4.10
>
>
> {noformat}
> osgi.service;objectClass=java.lang.Runnable
> osgi.service;objectClass=javax.servlet.Servlet
> osgi.service;objectClass=org.apache.sling.api.adapter.AdapterFactory
> osgi.service;objectClass=org.apache.sling.models.factory.ModelFactory
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SLING-8043) create MissingElementsException only if there is at least one missing element

[Dan Klco (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Klco closed SLING-8043.
---

> create MissingElementsException only if there is at least one missing element
> -
>
> Key: SLING-8043
> URL: https://issues.apache.org/jira/browse/SLING-8043
> Project: Sling
>  Issue Type: Improvement
>Affects Versions: Sling Models Impl 1.4.8
>Reporter: Dan Klco
>Assignee: Dan Klco
>Priority: Minor
> Fix For: Sling Models Impl 1.4.10
>
>
> Tracking the PR here: 
> https://github.com/apache/sling-org-apache-sling-models-impl/pull/7



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SLING-7584) Only the last DisposalCallbackRegistry is disposed when multiple models are adapted in the same request

[Dan Klco (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Klco closed SLING-7584.
---

> Only the last DisposalCallbackRegistry is disposed when multiple models are 
> adapted in the same request
> ---
>
> Key: SLING-7584
> URL: https://issues.apache.org/jira/browse/SLING-7584
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.4.6, Sling Models Impl 1.4.8
>Reporter: Justin Edelson
>Priority: Major
> Fix For: Sling Models Impl 1.4.10
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The implementation of SLING-5668 naively assumes that only a single disposal 
> callback registry will be used per request. This is plainly not the case and 
> unfortunately results in only the last callback for a given request to be 
> invoked.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

RESULT] [VOTE] Release Apache Sling Models Impl version 1.4.10

[Daniel Klco]

Hi,

The vote has passed with the following result :

+1 (binding): Oliver Lietz, Stefan Egli, Robert Munteanu, Dan Klco

I will copy this release to the Sling dist directory and promote the
artifacts to the central Maven repository.

Re: Sling 12 themes

[Daniel Klco]

Agreed with Justin. There are several different sources of URLs which may
need to be rewritten including directly from scripts, WYSIWYG HTML or Java
/ Model generated HTML (bad practice, I know) and I'm not seeing how a
pure-HTL solution would handle WYSIWYG HTML or Java / Model HTML without
having to re-parse the content.

Additionally, there's more value in the Sling Rewriter, as Justin and Jason
have described, to be able to rewrite any outgoing content. Unfortunately,
right now it's not easy easy to do as it could be if the API were cleaned
and a better reference implementation provided.

On Tue, Oct 23, 2018 at 7:45 PM Justin Edelson 
wrote:

> Just my 2cents as a fan of the rewriter.
>
> The problem with saying "just use HTL" (aside from what Jason said) is that
> it enables a separation of concerns. To say "just use HTL" implies that
> there is a single developer (or organization) who "owns" all the code
> responsible for generating HTML and has the authority to change them to
> suit emerging requirements (which today can be done universally via a
> rewriter transformer). But this isn't really the case a lot of the time --
> there's multiple "owners" who are each contributing components and applying
> rewriter-style logic across those owners is complicated (if not impossible)
> to manage. This also assumes that HTL (or any other scripting language
> generating HTML) is actually being used properly -- in my experience,
> there's plenty of "raw" HTML being output from string properties and you
> need a way to rewrite that too.
>
> I really don't think all the rewriter use cases boil down to link
> rewriting.
> https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13
> is
> a real-world example. But I'll need to dig through my project archive to
> come up with good examples.
>
> Personally, I'd suggest that HTL could be more tightly coupled to the
> rewriter and rather than emit a character stream which gets parsed into a
> SAX stream, the rewriter could be reimagined as a more generic event stream
> processing chain and HTL is directly providing HTML events into this chain
> (and given that HTL knows the output context, it could indicate as part of
> the event that the text content should be parsed in the case of embedded
> HTML). The output of JSPs could be parsed as is the current state. JSON
> could be handled through different event types.
>
>
>
>
> On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler 
> wrote:
>
> > The rewriter as it is today is pretty heavy and adds a lot of overhead
> > to request processing. Especially as the output needs to be created
> > first and then parsed again.
> >
> > There is nothing wrong with enhancing it in general. But for example if
> > you use HTL we could provide much better and faster support ootb. I
> > think if JSON is rendered we could do something at JSON creation time
> > instead of needing to reparse it again as well.
> >
> > I agree that it gets pretty hard to come up with a solution that targets
> > all output formats at once, even with the rewriter concept it's not that
> > easy. But maybe we can come up with different implementations that share
> > a single configuration. For example for link rewriting that should be
> > possible.
> >
> >
> > Carsten
> >
> > Am 23.10.2018 um 21:43 schrieb Daniel Klco:
> > > I don't see how we could support multiple templating languages without
> > some
> > > sort of rewriter support.
> > >
> > > Part of the problem IMO is that the Rewriter library muddles the
> > rewriting
> > > concept with an expectation of specifically dealing with (X)HTML.
> Instead
> > > it would make more sense to me to have a content agnostic library for
> > > performing content rewriting and providing a HTML, XML and (possibly)
> > JSON
> > > implementation.
> > >
> > > On Tue, Oct 23, 2018 at 1:32 PM Jason E Bailey  wrote:
> > >
> > >>
> > >> On Tue, Oct 23, 2018, at 1:24 PM, Konrad Windszus wrote:
> > >>> I would  rather prefer to get rid of a server side postprocessing
> like
> > >>> the rewriter. For HTL I agree with Carsten, we should probably look
> > into
> > >>> a generic link rewriting mechanism which allows for custom rewriting
> > >>> with a nice HTL plugin. Much less overhead than a Cocoon pipeline
> which
> > >>> needs to deserialize and then serialize again...
> > >>> Would be interesting to get forward in that regard with Sling 12.
> > >>
> > >> There is a real world need for html post processing that is not
> > dependent
> > >> on HTL. The rewriter is already not a core component and something
> that
> > is
> > >> community supported so I don't think enhancing it should be much of an
> > >> issue. For what it's worth though I don't like the overhead of the
> > existing
> > >> pipeline as it is anyway. HTML doesn't have anything to do with XML
> > anymore.
> > >>
> > >>> For JSON and client side rendering the link rewriting must be rather
> > >>> encapsulated on the client side as well. I don’t think Sling should

Re: Sling 12 themes

[Oliver Lietz]

On Wednesday 24 October 2018 06:55:06 Carsten Ziegeler wrote:
> As usual we're giving ourselves and our users a hard time as we want to
> support all the possible options in the world instead of focusing on one
> or two options and make them as good as possible. I don't care what the
> solution is, but supporting 5 different ways of creating html is imho
> totally wrong and fragmenting our user base. Whether it is HTL or not is
> a different question.
> 
> The current architecture of the rewriter is not optimal as it needs to
> reparse the output which is expensive. The servlet API has no support
> for streaming text based outputs so as long as we have that API in
> between we have a bad solution. Building on top of something where we
> know that its not a good thing, seems wrong to me as well.

Are there any plans to remove the Servlet API and switch to something else?

Regards,
O.

> Carsten
[...]

Re: Sling 12 themes

[Jörg Hoh]

Hi Jason,

Am Mi., 24. Okt. 2018 um 14:45 Uhr schrieb Jason E Bailey :

>
>
> On Wed, Oct 24, 2018, at 2:18 AM, Jörg Hoh wrote:
>
> > If we choose that way and want to prefer 1 and 2 we have to educate a lot
> > of people first about the difference between a resource path and a URL
> > pointing to that resource. In 99% all cases I saw in the last decade,
> both
> > scripts and models don't really make a difference between these 2 (and
> let
> > the rewriter handle the difference if any)
>
> Okay, I admit it, I don't understand the distinction here that you're
> trying to make.
>

It's basically 2 things, I see as common patterns:

Resource r = rr.get(SOME_CONSTANT + SOME_OTHER_CONSTANT + "/" +
someVariable);

in different variations, but basically only String concatenation. For me it
doesn't feel good. But that's not related to the rewriter :-)

Secondly, this is often used in this way (JSP):



In that case the path of the resource is written, but actually it should be
a relative link to another page. Currently the rewriter takes care of such
cases (if the repo path does not match the path part of the URL), but for
many devs the difference is absolutely not clear. That's the reason why I
would opt for some more abstraction and not to (mis-) use the Resource API
for such cases.

HTH,
Jörg

-- 
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh

Re: Sling 12 themes

[Radu Cotescu]

Hi Jason,

> On 24 Oct 2018, at 14:45, Jason E Bailey wrote:
> 
> On Wed, Oct 24, 2018, at 2:18 AM, Jörg Hoh wrote:
> 
>> If we choose that way and want to prefer 1 and 2 we have to educate a lot
>> of people first about the difference between a resource path and a URL
>> pointing to that resource. In 99% all cases I saw in the last decade, both
>> scripts and models don't really make a difference between these 2 (and let
>> the rewriter handle the difference if any) 
> 
> Okay, I admit it, I don't understand the distinction here that you're trying 
> to make.

In JCR, at least, you have valid JCR characters for node names which are not 
valid URI characters. Some utility classes try to deal with this, the most 
famous one being [0] - see [1]. A Resource’s path is the ResourceProvider's 
view of the world, but it’s not necessarily a valid way of exposing the 
Resource on the web.

I guess this is what Jörg was trying to say.

Cheers,
Radu

[0] - 
https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/util/Text.html 

[1] - 
https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/util/Text.html#escapePath(java.lang.String)
 

Re: Sling 12 themes

[Justin Edelson]

As long as this doesn't require explicit action by the script developer, I
could see this working. But that's not how, IIUC, HTL works. Rewriting has
to work even if the script developer didn't anticipate that a particular
element/attribute/text content needs rewriting.

On Wed, Oct 24, 2018 at 9:21 AM Konrad Windszus  wrote:

> IMHO modifying the script would not even be necessary in the best case for
> HTL as the HTL context would lead to automatically invoking a certain HTL
> plugin which allows to modify the link itself.
> So I totally agree we need aspect-oriented programming here (i.e. only do
> it once in code instead of hundreds of times explicitly in HTL).
>
> Konrad
>
> > On 24. Oct 2018, at 15:16, Justin Edelson 
> wrote:
> >
> > As I was trying to say, this assumes that modifying the script (or the
> > model or even the content) is an option. In many cases it isn't. How
> often,
> > I don't know, but I'm sure it is more than 5% (although I guess it
> depends
> > on how this is measured).
> >
> >
> >
> > On Wed, Oct 24, 2018 at 1:20 AM Carsten Ziegeler 
> > wrote:
> >
> >> In addition to that, it seems to me wrong to write a script which
> >> creates an output (being that html or json or whatever) and then you
> >> need an additional mechanism to modify this output. Wouldn't it be much
> >> better to create the correct output in the first place?
> >>
> >> So I think there are three places where you potentially do the
> >> modifications:
> >> 1. You modify your model which is the input to your script
> >> 2. You do it in a script
> >> 3. You reparse the output of your script and then modify it
> >>
> >> Maybe there are still use cases for 3 and then the rewriter is a good
> >> tool for it. But I sincerely hope that 95% of the use cases can already
> >> be solved with 1 or 2 - and thats were we should focus on.
> >>
> >> Carsten
> >>
> >> Am 24.10.2018 um 06:55 schrieb Carsten Ziegeler:
> >>> As usual we're giving ourselves and our users a hard time as we want to
> >>> support all the possible options in the world instead of focusing on
> one
> >>> or two options and make them as good as possible. I don't care what the
> >>> solution is, but supporting 5 different ways of creating html is imho
> >>> totally wrong and fragmenting our user base. Whether it is HTL or not
> is
> >>> a different question.
> >>>
> >>> The current architecture of the rewriter is not optimal as it needs to
> >>> reparse the output which is expensive. The servlet API has no support
> >>> for streaming text based outputs so as long as we have that API in
> >>> between we have a bad solution. Building on top of something where we
> >>> know that its not a good thing, seems wrong to me as well.
> >>>
> >>> Carsten
> >>>
> >>> Am 24.10.2018 um 01:45 schrieb Justin Edelson:
>  Just my 2cents as a fan of the rewriter.
> 
>  The problem with saying "just use HTL" (aside from what Jason said) is
>  that
>  it enables a separation of concerns. To say "just use HTL" implies
> that
>  there is a single developer (or organization) who "owns" all the code
>  responsible for generating HTML and has the authority to change them
> to
>  suit emerging requirements (which today can be done universally via a
>  rewriter transformer). But this isn't really the case a lot of the
>  time --
>  there's multiple "owners" who are each contributing components and
>  applying
>  rewriter-style logic across those owners is complicated (if not
>  impossible)
>  to manage. This also assumes that HTL (or any other scripting language
>  generating HTML) is actually being used properly -- in my experience,
>  there's plenty of "raw" HTML being output from string properties and
> you
>  need a way to rewrite that too.
> 
>  I really don't think all the rewriter use cases boil down to link
>  rewriting.
> 
> >>
> https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13
>  is
>  a real-world example. But I'll need to dig through my project archive
> to
>  come up with good examples.
> 
>  Personally, I'd suggest that HTL could be more tightly coupled to the
>  rewriter and rather than emit a character stream which gets parsed
> into
> >> a
>  SAX stream, the rewriter could be reimagined as a more generic event
>  stream
>  processing chain and HTL is directly providing HTML events into this
>  chain
>  (and given that HTL knows the output context, it could indicate as
>  part of
>  the event that the text content should be parsed in the case of
> embedded
>  HTML). The output of JSPs could be parsed as is the current state.
> JSON
>  could be handled through different event types.
> 
> 
> 
> 
>  On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler <
> cziege...@apache.org>
>  wrote:
> 
> > The rewriter as it is today is pretty heavy and adds a lot of
> overhead
> > 

[GitHub] simonetripodi commented on a change in pull request #14: Issue/sling 8038

[GitBox]

simonetripodi commented on a change in pull request #14: Issue/sling 8038
URL: 
https://github.com/apache/sling-slingfeature-maven-plugin/pull/14#discussion_r227787621
 
 

 ##
 File path: 
src/main/java/org/apache/sling/feature/maven/mojos/ArtifactsMojo.java
 ##
 @@ -38,8 +38,7 @@
 
 @Mojo(
 name = "collect-artifacts",
-defaultPhase = LifecyclePhase.PACKAGE,
-requiresDependencyResolution = ResolutionScope.TEST,
+requiresProject = false,
 
 Review comment:
   good catch, thanks!  


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] simonetripodi commented on a change in pull request #14: Issue/sling 8038

[GitBox]

simonetripodi commented on a change in pull request #14: Issue/sling 8038
URL: 
https://github.com/apache/sling-slingfeature-maven-plugin/pull/14#discussion_r227787130
 
 

 ##
 File path: 
src/main/java/org/apache/sling/feature/maven/mojos/AbstractRepositoryMojo.java
 ##
 @@ -65,7 +65,12 @@
 
 @Override
 public void execute() throws MojoExecutionException, MojoFailureException {
-final File artifactDir = new 
File(this.project.getBuild().getDirectory(), repositoryDir);
+final File artifactDir ;
 
 Review comment:
   I have another suggestion here, in order to let Maven doing his job already:
   
   ```
   @Parameter(defaultValue = "${project.build.directory}/artifacts", property = 
"repositoryDir")
   private File artifactDir;
   ```
   
   since Maven is able already to interpolate variables and automatically 
convert types.
   
   Then, dropping `String repositoryDir` declaration and `File artifactDir` 
building.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] simonetripodi commented on a change in pull request #14: Issue/sling 8038

[GitBox]

simonetripodi commented on a change in pull request #14: Issue/sling 8038
URL: 
https://github.com/apache/sling-slingfeature-maven-plugin/pull/14#discussion_r227787130
 
 

 ##
 File path: 
src/main/java/org/apache/sling/feature/maven/mojos/AbstractRepositoryMojo.java
 ##
 @@ -65,7 +65,12 @@
 
 @Override
 public void execute() throws MojoExecutionException, MojoFailureException {
-final File artifactDir = new 
File(this.project.getBuild().getDirectory(), repositoryDir);
+final File artifactDir ;
 
 Review comment:
   I have another suggestion here, in order to let Maven doing his job already:
   
   ```
   @Parameter(defaultValue = "${project.build.directory}/artifacts", property = 
"repositoryDir")
   private File artifactDir;```
   
   since Maven is able already to interpolate variables and automatically 
convert types.
   
   Then, dropping `String repositoryDir` declaration and `File artifactDir` 
building.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] simonetripodi commented on a change in pull request #14: Issue/sling 8038

[GitBox]

simonetripodi commented on a change in pull request #14: Issue/sling 8038
URL: 
https://github.com/apache/sling-slingfeature-maven-plugin/pull/14#discussion_r227787130
 
 

 ##
 File path: 
src/main/java/org/apache/sling/feature/maven/mojos/AbstractRepositoryMojo.java
 ##
 @@ -65,7 +65,12 @@
 
 @Override
 public void execute() throws MojoExecutionException, MojoFailureException {
-final File artifactDir = new 
File(this.project.getBuild().getDirectory(), repositoryDir);
+final File artifactDir ;
 
 Review comment:
   I have another suggestion here, in order to let Maven doing his job already:
   
   ```@Parameter(defaultValue = "${project.build.directory}/artifacts", 
property = "repositoryDir")
   private File artifactDir;``` since Maven is able already to interpolate 
variables and automatically convert types.
   
   Then, dropping `String repositoryDir` declaration and `File artifactDir` 
building.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] simonetripodi commented on a change in pull request #14: Issue/sling 8038

[GitBox]

simonetripodi commented on a change in pull request #14: Issue/sling 8038
URL: 
https://github.com/apache/sling-slingfeature-maven-plugin/pull/14#discussion_r227785818
 
 

 ##
 File path: 
src/main/java/org/apache/sling/feature/maven/mojos/AbstractRepositoryMojo.java
 ##
 @@ -47,7 +47,7 @@
 /**
  * The directory to store the artifacts into.
  */
-@Parameter(defaultValue = "artifacts")
+@Parameter(defaultValue = "artifacts", property = "repositoryDir")
 
 Review comment:
   Hi there @DominikSuess, thanks for jumping in to help! :)
   
   the `property` allows you specify the parameter via CLI with 
`-DrepositoryDir=foo-bar`, I'd suggets to restore it!


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Sling 12 themes

[Justin Edelson]

These are orthogonal questions IMO.

We can say that the one true way of generating HTML is HTL (or Thymeleaf or
JSP or whatever). But that doesn't obviate the need to modify the *output*
of the HTL script using some kind of AOP model (which is really what the
rewriter is).

On Wed, Oct 24, 2018 at 12:55 AM Carsten Ziegeler 
wrote:

> As usual we're giving ourselves and our users a hard time as we want to
> support all the possible options in the world instead of focusing on one
> or two options and make them as good as possible. I don't care what the
> solution is, but supporting 5 different ways of creating html is imho
> totally wrong and fragmenting our user base. Whether it is HTL or not is
> a different question.
>
> The current architecture of the rewriter is not optimal as it needs to
> reparse the output which is expensive. The servlet API has no support
> for streaming text based outputs so as long as we have that API in
> between we have a bad solution. Building on top of something where we
> know that its not a good thing, seems wrong to me as well.
>
> Carsten
>
> Am 24.10.2018 um 01:45 schrieb Justin Edelson:
> > Just my 2cents as a fan of the rewriter.
> >
> > The problem with saying "just use HTL" (aside from what Jason said) is
> that
> > it enables a separation of concerns. To say "just use HTL" implies that
> > there is a single developer (or organization) who "owns" all the code
> > responsible for generating HTML and has the authority to change them to
> > suit emerging requirements (which today can be done universally via a
> > rewriter transformer). But this isn't really the case a lot of the time
> --
> > there's multiple "owners" who are each contributing components and
> applying
> > rewriter-style logic across those owners is complicated (if not
> impossible)
> > to manage. This also assumes that HTL (or any other scripting language
> > generating HTML) is actually being used properly -- in my experience,
> > there's plenty of "raw" HTML being output from string properties and you
> > need a way to rewrite that too.
> >
> > I really don't think all the rewriter use cases boil down to link
> > rewriting.
> > https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13
> is
> > a real-world example. But I'll need to dig through my project archive to
> > come up with good examples.
> >
> > Personally, I'd suggest that HTL could be more tightly coupled to the
> > rewriter and rather than emit a character stream which gets parsed into a
> > SAX stream, the rewriter could be reimagined as a more generic event
> stream
> > processing chain and HTL is directly providing HTML events into this
> chain
> > (and given that HTL knows the output context, it could indicate as part
> of
> > the event that the text content should be parsed in the case of embedded
> > HTML). The output of JSPs could be parsed as is the current state. JSON
> > could be handled through different event types.
> >
> >
> >
> >
> > On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler 
> > wrote:
> >
> >> The rewriter as it is today is pretty heavy and adds a lot of overhead
> >> to request processing. Especially as the output needs to be created
> >> first and then parsed again.
> >>
> >> There is nothing wrong with enhancing it in general. But for example if
> >> you use HTL we could provide much better and faster support ootb. I
> >> think if JSON is rendered we could do something at JSON creation time
> >> instead of needing to reparse it again as well.
> >>
> >> I agree that it gets pretty hard to come up with a solution that targets
> >> all output formats at once, even with the rewriter concept it's not that
> >> easy. But maybe we can come up with different implementations that share
> >> a single configuration. For example for link rewriting that should be
> >> possible.
> >>
> >>
> >> Carsten
> >>
> >> Am 23.10.2018 um 21:43 schrieb Daniel Klco:
> >>> I don't see how we could support multiple templating languages without
> >> some
> >>> sort of rewriter support.
> >>>
> >>> Part of the problem IMO is that the Rewriter library muddles the
> >> rewriting
> >>> concept with an expectation of specifically dealing with (X)HTML.
> Instead
> >>> it would make more sense to me to have a content agnostic library for
> >>> performing content rewriting and providing a HTML, XML and (possibly)
> >> JSON
> >>> implementation.
> >>>
> >>> On Tue, Oct 23, 2018 at 1:32 PM Jason E Bailey  wrote:
> >>>
> 
>  On Tue, Oct 23, 2018, at 1:24 PM, Konrad Windszus wrote:
> > I would  rather prefer to get rid of a server side postprocessing
> like
> > the rewriter. For HTL I agree with Carsten, we should probably look
> >> into
> > a generic link rewriting mechanism which allows for custom rewriting
> > with a nice HTL plugin. Much less overhead than a Cocoon pipeline
> which
> > needs to deserialize and then serialize again...
> > Would be interesting to get forward in that regard with Sling 12.

Re: Sling 12 themes

[Konrad Windszus]

IMHO modifying the script would not even be necessary in the best case for HTL 
as the HTL context would lead to automatically invoking a certain HTL plugin 
which allows to modify the link itself.
So I totally agree we need aspect-oriented programming here (i.e. only do it 
once in code instead of hundreds of times explicitly in HTL).

Konrad

> On 24. Oct 2018, at 15:16, Justin Edelson  wrote:
> 
> As I was trying to say, this assumes that modifying the script (or the
> model or even the content) is an option. In many cases it isn't. How often,
> I don't know, but I'm sure it is more than 5% (although I guess it depends
> on how this is measured).
> 
> 
> 
> On Wed, Oct 24, 2018 at 1:20 AM Carsten Ziegeler 
> wrote:
> 
>> In addition to that, it seems to me wrong to write a script which
>> creates an output (being that html or json or whatever) and then you
>> need an additional mechanism to modify this output. Wouldn't it be much
>> better to create the correct output in the first place?
>> 
>> So I think there are three places where you potentially do the
>> modifications:
>> 1. You modify your model which is the input to your script
>> 2. You do it in a script
>> 3. You reparse the output of your script and then modify it
>> 
>> Maybe there are still use cases for 3 and then the rewriter is a good
>> tool for it. But I sincerely hope that 95% of the use cases can already
>> be solved with 1 or 2 - and thats were we should focus on.
>> 
>> Carsten
>> 
>> Am 24.10.2018 um 06:55 schrieb Carsten Ziegeler:
>>> As usual we're giving ourselves and our users a hard time as we want to
>>> support all the possible options in the world instead of focusing on one
>>> or two options and make them as good as possible. I don't care what the
>>> solution is, but supporting 5 different ways of creating html is imho
>>> totally wrong and fragmenting our user base. Whether it is HTL or not is
>>> a different question.
>>> 
>>> The current architecture of the rewriter is not optimal as it needs to
>>> reparse the output which is expensive. The servlet API has no support
>>> for streaming text based outputs so as long as we have that API in
>>> between we have a bad solution. Building on top of something where we
>>> know that its not a good thing, seems wrong to me as well.
>>> 
>>> Carsten
>>> 
>>> Am 24.10.2018 um 01:45 schrieb Justin Edelson:
 Just my 2cents as a fan of the rewriter.
 
 The problem with saying "just use HTL" (aside from what Jason said) is
 that
 it enables a separation of concerns. To say "just use HTL" implies that
 there is a single developer (or organization) who "owns" all the code
 responsible for generating HTML and has the authority to change them to
 suit emerging requirements (which today can be done universally via a
 rewriter transformer). But this isn't really the case a lot of the
 time --
 there's multiple "owners" who are each contributing components and
 applying
 rewriter-style logic across those owners is complicated (if not
 impossible)
 to manage. This also assumes that HTL (or any other scripting language
 generating HTML) is actually being used properly -- in my experience,
 there's plenty of "raw" HTML being output from string properties and you
 need a way to rewrite that too.
 
 I really don't think all the rewriter use cases boil down to link
 rewriting.
 
>> https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13
 is
 a real-world example. But I'll need to dig through my project archive to
 come up with good examples.
 
 Personally, I'd suggest that HTL could be more tightly coupled to the
 rewriter and rather than emit a character stream which gets parsed into
>> a
 SAX stream, the rewriter could be reimagined as a more generic event
 stream
 processing chain and HTL is directly providing HTML events into this
 chain
 (and given that HTL knows the output context, it could indicate as
 part of
 the event that the text content should be parsed in the case of embedded
 HTML). The output of JSPs could be parsed as is the current state. JSON
 could be handled through different event types.
 
 
 
 
 On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler 
 wrote:
 
> The rewriter as it is today is pretty heavy and adds a lot of overhead
> to request processing. Especially as the output needs to be created
> first and then parsed again.
> 
> There is nothing wrong with enhancing it in general. But for example if
> you use HTL we could provide much better and faster support ootb. I
> think if JSON is rendered we could do something at JSON creation time
> instead of needing to reparse it again as well.
> 
> I agree that it gets pretty hard to come up with a solution that
>> targets
> all output formats at once, even with the rewriter concept it's not
>> 

Re: Sling 12 themes

[Justin Edelson]

As I was trying to say, this assumes that modifying the script (or the
model or even the content) is an option. In many cases it isn't. How often,
I don't know, but I'm sure it is more than 5% (although I guess it depends
on how this is measured).



On Wed, Oct 24, 2018 at 1:20 AM Carsten Ziegeler 
wrote:

> In addition to that, it seems to me wrong to write a script which
> creates an output (being that html or json or whatever) and then you
> need an additional mechanism to modify this output. Wouldn't it be much
> better to create the correct output in the first place?
>
> So I think there are three places where you potentially do the
> modifications:
> 1. You modify your model which is the input to your script
> 2. You do it in a script
> 3. You reparse the output of your script and then modify it
>
> Maybe there are still use cases for 3 and then the rewriter is a good
> tool for it. But I sincerely hope that 95% of the use cases can already
> be solved with 1 or 2 - and thats were we should focus on.
>
> Carsten
>
> Am 24.10.2018 um 06:55 schrieb Carsten Ziegeler:
> > As usual we're giving ourselves and our users a hard time as we want to
> > support all the possible options in the world instead of focusing on one
> > or two options and make them as good as possible. I don't care what the
> > solution is, but supporting 5 different ways of creating html is imho
> > totally wrong and fragmenting our user base. Whether it is HTL or not is
> > a different question.
> >
> > The current architecture of the rewriter is not optimal as it needs to
> > reparse the output which is expensive. The servlet API has no support
> > for streaming text based outputs so as long as we have that API in
> > between we have a bad solution. Building on top of something where we
> > know that its not a good thing, seems wrong to me as well.
> >
> > Carsten
> >
> > Am 24.10.2018 um 01:45 schrieb Justin Edelson:
> >> Just my 2cents as a fan of the rewriter.
> >>
> >> The problem with saying "just use HTL" (aside from what Jason said) is
> >> that
> >> it enables a separation of concerns. To say "just use HTL" implies that
> >> there is a single developer (or organization) who "owns" all the code
> >> responsible for generating HTML and has the authority to change them to
> >> suit emerging requirements (which today can be done universally via a
> >> rewriter transformer). But this isn't really the case a lot of the
> >> time --
> >> there's multiple "owners" who are each contributing components and
> >> applying
> >> rewriter-style logic across those owners is complicated (if not
> >> impossible)
> >> to manage. This also assumes that HTL (or any other scripting language
> >> generating HTML) is actually being used properly -- in my experience,
> >> there's plenty of "raw" HTML being output from string properties and you
> >> need a way to rewrite that too.
> >>
> >> I really don't think all the rewriter use cases boil down to link
> >> rewriting.
> >>
> https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13
> >> is
> >> a real-world example. But I'll need to dig through my project archive to
> >> come up with good examples.
> >>
> >> Personally, I'd suggest that HTL could be more tightly coupled to the
> >> rewriter and rather than emit a character stream which gets parsed into
> a
> >> SAX stream, the rewriter could be reimagined as a more generic event
> >> stream
> >> processing chain and HTL is directly providing HTML events into this
> >> chain
> >> (and given that HTL knows the output context, it could indicate as
> >> part of
> >> the event that the text content should be parsed in the case of embedded
> >> HTML). The output of JSPs could be parsed as is the current state. JSON
> >> could be handled through different event types.
> >>
> >>
> >>
> >>
> >> On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler 
> >> wrote:
> >>
> >>> The rewriter as it is today is pretty heavy and adds a lot of overhead
> >>> to request processing. Especially as the output needs to be created
> >>> first and then parsed again.
> >>>
> >>> There is nothing wrong with enhancing it in general. But for example if
> >>> you use HTL we could provide much better and faster support ootb. I
> >>> think if JSON is rendered we could do something at JSON creation time
> >>> instead of needing to reparse it again as well.
> >>>
> >>> I agree that it gets pretty hard to come up with a solution that
> targets
> >>> all output formats at once, even with the rewriter concept it's not
> that
> >>> easy. But maybe we can come up with different implementations that
> share
> >>> a single configuration. For example for link rewriting that should be
> >>> possible.
> >>>
> >>>
> >>> Carsten
> >>>
> >>> Am 23.10.2018 um 21:43 schrieb Daniel Klco:
>  I don't see how we could support multiple templating languages without
> >>> some
>  sort of rewriter support.
> 
>  Part of the problem IMO is that the Rewriter library muddles the
> 

use cases for the rewriter that I have used

[Jason E Bailey]

#  Validation of endpoints of URLS's - looking for invalid URL's

#  Modifying a URL to have a different prefix as part of a multi-tenant 
implementation, user selects a resource to point to, or include into an 
existing page. That resource is accessible via the tree but technically lives 
in a different website.

# Looking at the resource that is being pointed to and adding a class to the 
image based on the type of resource. This one is no longer valid, but at the 
time we wanted to identify an image that was uploaded directly by an author 
versus a dam image . So in the authoring environment we would modify the class 
if the image had been directly uploaded so that it would be have a watermark on 
it. 

# Looking at a resource and modifying the page and link. We had a specific page 
type called a modal page, whenever you linked to that page, instead of opening 
in a new tab, the rewrite would detect that you are pointing to a modal page, 
add the necessary calls to the css and js that the modal functionality needed 
to work correctly and added a trigger so that the link worked as a trigger for 
a modal call.


- Jason

Re: Sling 12 themes

[Jason E Bailey]

On Wed, Oct 24, 2018, at 2:18 AM, Jörg Hoh wrote:

> If we choose that way and want to prefer 1 and 2 we have to educate a lot
> of people first about the difference between a resource path and a URL
> pointing to that resource. In 99% all cases I saw in the last decade, both
> scripts and models don't really make a difference between these 2 (and let
> the rewriter handle the difference if any) 

Okay, I admit it, I don't understand the distinction here that you're trying to 
make.



- Jason

Re: Sling 12 themes

[Jason E Bailey]

So a couple of months ago I was trying to resolve the issue of HTML5 support in 
the rewriter and I realized that the current implementation isn't a good fit 
for HTML5 and is overly heavy and complex. As I was diving into the the HTML5 
specs I came up with a solution that could correctly identify an HTML tag as 
text was being pushed to it. 

This allowed me to create a streaming set of events that didn't require me to 
parse the whole document first. I initially didn't think this was a good fit 
for Sling. So I built it out to a separate repository. I'm going to go ahead 
and put it in the whiteboard so that I can get some additional eyes on it, but 
it may satisfy several of your concerns.

One implementation of it I came up with during this email exchange was to make 
this part of a ServletResponseWrapper so that if we know a resource is being 
requested as html content, we could wrap it with this wrapper and any text that 
is written to the out is modified on the fly. 

TLDR; 100 percent agree that the rewriter as it exists now is not a good 
solution. Disagree on making a solution that will only fit one way of creating 
HTML.

--
Jason

On Wed, Oct 24, 2018, at 12:55 AM, Carsten Ziegeler wrote:
> As usual we're giving ourselves and our users a hard time as we want to 
> support all the possible options in the world instead of focusing on one 
> or two options and make them as good as possible. I don't care what the 
> solution is, but supporting 5 different ways of creating html is imho 
> totally wrong and fragmenting our user base. Whether it is HTL or not is 
> a different question.
> 
> The current architecture of the rewriter is not optimal as it needs to 
> reparse the output which is expensive. The servlet API has no support 
> for streaming text based outputs so as long as we have that API in 
> between we have a bad solution. Building on top of something where we 
> know that its not a good thing, seems wrong to me as well.
> 
> Carsten
> 

Re: Archetype naming (was: [VOTE] Release Apache Sling 11)

[Robert Munteanu]

On Tue, 2018-10-23 at 20:51 +0200, Oliver Lietz wrote:
> On Tuesday 23 October 2018 10:38:52 Robert Munteanu wrote:
> > Hi Olli,
> 
> Hi Robert,
> 
> > On Mon, 2018-10-22 at 22:08 +0200, Oliver Lietz wrote:
> > > > > - sling-launchpad-archetype 1.0.8
> > > 
> > > should be sling-starter-archetype
> > 
> > Hm, maybe? 'Launchpad' is the term we use for the utilities that
> > allow
> > setting up a Sling application, while 'starter' is the term for our
> > own
> > sample/demo application.
> > 
> > Maybe sling-application-archetype would be better, decoupling the
> > concept from our own internal naming for tooling?
> 
> sorry, I mean sling-slingstart-archetype. We don't have a module
> named sling-
> launchpad-archetype, right?

Ah, I misread your email, sorry. Yes, that should've been 'sling-
slingstart-archetype'.

Thanks,

Robert

[jira] [Comment Edited] (SLING-8008) Create dedicated parent for bundle projects

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16662089#comment-16662089
 ] 

Konrad Windszus edited comment on SLING-8008 at 10/24/18 10:49 AM:
---

PR created in 
[https://github.com/apache/sling-parent/pull/3|https://github.com/apache/sling-parent/pull/3.]
 Please check and give feedback. I will not merge for at least one week to give 
everyone enough time to check this.


was (Author: kwin):
PR created in [https://github.com/apache/sling-parent/pull/3.] Please check and 
give feedback. I will not merge for at least one week to give everyone enough 
time to check this.

> Create dedicated parent for bundle projects
> ---
>
> Key: SLING-8008
> URL: https://issues.apache.org/jira/browse/SLING-8008
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Parent 34
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As followup to the Sling Hackathon in Berlin in September (compare with 
> [https://www.mail-archive.com/dev@sling.apache.org/msg79953.html 
> |https://www.mail-archive.com/dev@sling.apache.org/msg79953.html).]there is 
> the proposal to split up the current parent pom into two pieces: one for 
> JARs/general aspect, another one for bundles (covering only those aspects).
>  
> The reasons for this switch are:
>  - we would like to switch completely to bnd-maven-plugin, but without the 
> need for a separate bnd file
>  - we currently have only one parent pom for bundle modules and non-bundle 
> modules, making it difficult to configure the bnd-maven-plugin globally so it 
> gets up picked only for bundles, not for simple jar files.
>  - using maven profiles would be an option, but there is no nice way to 
> trigger the profile without ugly hacks like having an empty bnd file present.
>  - https://issues.apache.org/jira/browse/MJAR-193 would be another solution 
> (haven the bnd plugin handing over the manifest extensions to the maven jar 
> plugin), but this feature is not available yet
>  
> The proposed solutions looks like this
>  - create an additional "sling-bundle-parent" inheriting from the existing 
> "sling-parent"
>  - all bundle-related stuff goes there and will be removed from "sling-parent"
>  - old maven-bundle-plugin and bnd-maven-plugin should be removed from 
> sling-parent
>  - maven-bundle-plugin should be banned from sling-bundle-parent
>  - one repo for both, always released together
>  - start with next version 36
>  - make a wiki page with migration steps
>  - bundle modules will use "sling-bundle-parent", jar modules "sling-parent"
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-8008) Create dedicated parent for bundle projects

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16662089#comment-16662089
 ] 

Konrad Windszus commented on SLING-8008:


PR created in [https://github.com/apache/sling-parent/pull/3.] Please check and 
give feedback. I will not merge for at least one week to give everyone enough 
time to check this.

> Create dedicated parent for bundle projects
> ---
>
> Key: SLING-8008
> URL: https://issues.apache.org/jira/browse/SLING-8008
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Parent 34
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As followup to the Sling Hackathon in Berlin in September (compare with 
> [https://www.mail-archive.com/dev@sling.apache.org/msg79953.html 
> |https://www.mail-archive.com/dev@sling.apache.org/msg79953.html).]there is 
> the proposal to split up the current parent pom into two pieces: one for 
> JARs/general aspect, another one for bundles (covering only those aspects).
>  
> The reasons for this switch are:
>  - we would like to switch completely to bnd-maven-plugin, but without the 
> need for a separate bnd file
>  - we currently have only one parent pom for bundle modules and non-bundle 
> modules, making it difficult to configure the bnd-maven-plugin globally so it 
> gets up picked only for bundles, not for simple jar files.
>  - using maven profiles would be an option, but there is no nice way to 
> trigger the profile without ugly hacks like having an empty bnd file present.
>  - https://issues.apache.org/jira/browse/MJAR-193 would be another solution 
> (haven the bnd plugin handing over the manifest extensions to the maven jar 
> plugin), but this feature is not available yet
>  
> The proposed solutions looks like this
>  - create an additional "sling-bundle-parent" inheriting from the existing 
> "sling-parent"
>  - all bundle-related stuff goes there and will be removed from "sling-parent"
>  - old maven-bundle-plugin and bnd-maven-plugin should be removed from 
> sling-parent
>  - maven-bundle-plugin should be banned from sling-bundle-parent
>  - one repo for both, always released together
>  - start with next version 36
>  - make a wiki page with migration steps
>  - bundle modules will use "sling-bundle-parent", jar modules "sling-parent"
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SLING-8008) Create dedicated parent for bundle projects

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus reassigned SLING-8008:
--

Assignee: Konrad Windszus

> Create dedicated parent for bundle projects
> ---
>
> Key: SLING-8008
> URL: https://issues.apache.org/jira/browse/SLING-8008
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Parent 34
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As followup to the Sling Hackathon in Berlin in September (compare with 
> [https://www.mail-archive.com/dev@sling.apache.org/msg79953.html 
> |https://www.mail-archive.com/dev@sling.apache.org/msg79953.html).]there is 
> the proposal to split up the current parent pom into two pieces: one for 
> JARs/general aspect, another one for bundles (covering only those aspects).
>  
> The reasons for this switch are:
>  - we would like to switch completely to bnd-maven-plugin, but without the 
> need for a separate bnd file
>  - we currently have only one parent pom for bundle modules and non-bundle 
> modules, making it difficult to configure the bnd-maven-plugin globally so it 
> gets up picked only for bundles, not for simple jar files.
>  - using maven profiles would be an option, but there is no nice way to 
> trigger the profile without ugly hacks like having an empty bnd file present.
>  - https://issues.apache.org/jira/browse/MJAR-193 would be another solution 
> (haven the bnd plugin handing over the manifest extensions to the maven jar 
> plugin), but this feature is not available yet
>  
> The proposed solutions looks like this
>  - create an additional "sling-bundle-parent" inheriting from the existing 
> "sling-parent"
>  - all bundle-related stuff goes there and will be removed from "sling-parent"
>  - old maven-bundle-plugin and bnd-maven-plugin should be removed from 
> sling-parent
>  - maven-bundle-plugin should be banned from sling-bundle-parent
>  - one repo for both, always released together
>  - start with next version 36
>  - make a wiki page with migration steps
>  - bundle modules will use "sling-bundle-parent", jar modules "sling-parent"
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] kwin opened a new pull request #3: SLING-8008 separate parent pom for bundles

[GitBox]

kwin opened a new pull request #3: SLING-8008 separate parent pom for bundles
URL: https://github.com/apache/sling-parent/pull/3
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Resolved] (SLING-7903) Release Sling 11

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved SLING-7903.

Resolution: Fixed
  Assignee: Robert Munteanu

> Release Sling 11
> 
>
> Key: SLING-7903
> URL: https://issues.apache.org/jira/browse/SLING-7903
> Project: Sling
>  Issue Type: Task
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>
> Documentation at 
> https://cwiki.apache.org/confluence/display/SLING/Releasing+a+new+version+of+the+Sling+Starter



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SLING-7911) Send announcement to u...@sling.apache.org and annou...@apache.org

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-7911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved SLING-7911.

Resolution: Fixed

> Send announcement to u...@sling.apache.org and annou...@apache.org
> --
>
> Key: SLING-7911
> URL: https://issues.apache.org/jira/browse/SLING-7911
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Sling 12 themes

[Konrad Windszus]

I think it would be good to start collecting use cases for rewriting. Then we 
see how much could be covered by an HTL plugin (in case HTL would be used).

> On 24. Oct 2018, at 10:41, Carsten Ziegeler  > wrote:
> 
> Very valid point, thanks Jörg.
> 
> I think in the end it depends on whether we want to step back for a second 
> and look what the best solution is or whether we just want to continue with 
> what we have and put more stuff on top of it and try to make it work somehow.
> 
> Carsten
> 
> Am 24.10.2018 um 08:18 schrieb Jörg Hoh:
>> Hi
>> Am Mi., 24. Okt. 2018 um 07:20 Uhr schrieb Carsten Ziegeler <
>> cziege...@apache.org >:
>>> 
>>> 
>>> So I think there are three places where you potentially do the
>>> modifications:
>>> 1. You modify your model which is the input to your script
>>> 2. You do it in a script
>>> 3. You reparse the output of your script and then modify it
>>> 
>>> Maybe there are still use cases for 3 and then the rewriter is a good
>>> tool for it. But I sincerely hope that 95% of the use cases can already
>>> be solved with 1 or 2 - and thats were we should focus on.
>>> 
>>> 
>> (Totally unrelated to the rewriter discussion, but rather something else
>> for Sling 12, and which bothered me for quite some time)
>> If we choose that way and want to prefer 1 and 2 we have to educate a lot
>> of people first about the difference between a resource path and a URL
>> pointing to that resource. In 99% all cases I saw in the last decade, both
>> scripts and models don't really make a difference between these 2 (and let
>> the rewriter handle the difference if any) and internally use a simple
>> String to hold it. In my opinion the first step to get there would be an
>> introduction of concepts representing the ResourcePath and a ResourceURL/I
>> (ignore the names for the moment) which should eliminate the string
>> concatenation operations which I see way to often to create resource paths,
>> and make the distinction explicit. Plus a lot of convenience and
>> integration into the resource API. And then I see a chance, that (1) and
>> (2) get the traction so they are used in the mentioned 95% of all cases.
>> Not before.
>> Jörg
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org 

Re: Sling 12 themes

[Carsten Ziegeler]

Very valid point, thanks Jörg.

I think in the end it depends on whether we want to step back for a 
second and look what the best solution is or whether we just want to 
continue with what we have and put more stuff on top of it and try to 
make it work somehow.


Carsten

Am 24.10.2018 um 08:18 schrieb Jörg Hoh:

Hi

Am Mi., 24. Okt. 2018 um 07:20 Uhr schrieb Carsten Ziegeler <
cziege...@apache.org>:




So I think there are three places where you potentially do the
modifications:
1. You modify your model which is the input to your script
2. You do it in a script
3. You reparse the output of your script and then modify it

Maybe there are still use cases for 3 and then the rewriter is a good
tool for it. But I sincerely hope that 95% of the use cases can already
be solved with 1 or 2 - and thats were we should focus on.



(Totally unrelated to the rewriter discussion, but rather something else
for Sling 12, and which bothered me for quite some time)

If we choose that way and want to prefer 1 and 2 we have to educate a lot
of people first about the difference between a resource path and a URL
pointing to that resource. In 99% all cases I saw in the last decade, both
scripts and models don't really make a difference between these 2 (and let
the rewriter handle the difference if any) and internally use a simple
String to hold it. In my opinion the first step to get there would be an
introduction of concepts representing the ResourcePath and a ResourceURL/I
(ignore the names for the moment) which should eliminate the string
concatenation operations which I see way to often to create resource paths,
and make the distinction explicit. Plus a lot of convenience and
integration into the resource API. And then I see a chance, that (1) and
(2) get the traction so they are used in the mentioned 95% of all cases.
Not before.

Jörg



--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Sling 12 themes

[Jörg Hoh]

Hi

Am Mi., 24. Okt. 2018 um 07:20 Uhr schrieb Carsten Ziegeler <
cziege...@apache.org>:

>
>
> So I think there are three places where you potentially do the
> modifications:
> 1. You modify your model which is the input to your script
> 2. You do it in a script
> 3. You reparse the output of your script and then modify it
>
> Maybe there are still use cases for 3 and then the rewriter is a good
> tool for it. But I sincerely hope that 95% of the use cases can already
> be solved with 1 or 2 - and thats were we should focus on.
>
>
(Totally unrelated to the rewriter discussion, but rather something else
for Sling 12, and which bothered me for quite some time)

If we choose that way and want to prefer 1 and 2 we have to educate a lot
of people first about the difference between a resource path and a URL
pointing to that resource. In 99% all cases I saw in the last decade, both
scripts and models don't really make a difference between these 2 (and let
the rewriter handle the difference if any) and internally use a simple
String to hold it. In my opinion the first step to get there would be an
introduction of concepts representing the ResourcePath and a ResourceURL/I
(ignore the names for the moment) which should eliminate the string
concatenation operations which I see way to often to create resource paths,
and make the distinction explicit. Plus a lot of convenience and
integration into the resource API. And then I see a chance, that (1) and
(2) get the traction so they are used in the mentioned 95% of all cases.
Not before.

Jörg

-- 
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh