Re: Sling 12 themes

[Jason E Bailey]

More like a Sling 14 theme.

At some point I'd like to make the POST side a more fully integrated member. 
Working the same way that the GET side does.

So something like 
POST http://my.url/content/data.json
Can be handled by the JSON Post Processer

versus
POST http://my.url/content/data.xml 
which would be sending xml data.

selectors would have a place as well, as you would be able to define a variant 
of the data that you are pushing. 
POST http://my.url/content/data.template.xml 
would go to a specific POST handler.

- Jason

On Tue, Oct 23, 2018, at 9:29 AM, Robert Munteanu wrote:
> Hi,
> 
> Now that Sling 11 is out, we should be thinking about Sling 12 already
> :-) .
> 
> Each Sling release brings in hundreds of individual changes in the form
> of bug fixes and incremental improvements. On top of that, we also have
> major features or themes for the release, such as:
> 
> * updating to OSGi R7 (Sling 11)
> * Github migration (~Sling 10)
> * Refreshing the default ACL setup (Sling 11)
> * Enhanced Java 9+ support (Sling 10,11)
> 
> I think it would be an interesting and worthwhile exercise to see what
> various contributors would like to see as the major themes of Sling 12.
> 
> So, fire away :-)
> 
> Thanks,
> 
> Robert
> 
> 

Re: Sling 12 themes

[Robert Munteanu]

On Tue, 2018-10-23 at 16:29 +0200, Robert Munteanu wrote:
> I think it would be an interesting and worthwhile exercise to see
> what
> various contributors would like to see as the major themes of Sling
> 12.

Well, since I was the one asking :-)

My areas of focus for Sling 12 would be mostly internal-facing:

- moving tests closer to the code they test
- improved build checks for Github PRs
- move to a PR-only model for the starter module

Of course, these topics where we need to discuss upfront, and I'll do
that for each item when the time comes.

Thanks,

Robert

Re: Sling 12 themes

[Julian Sedding]

Hi Jason

Both the "sling:resourceType" and "jcr:primaryType" property names
used to derive the resource type of a resource (i.e.
Resource.getResourceType()) are implementation details of the JCR
Resource Provider (see [0]). For a JCR Resource Provide this seems
like a legitimate choice. If, however, generic (or JCR agnostic) parts
of Sling were to implement this fallback, that would be incorrect - I
agree with that.

Regarding the fact that Resource.getResourceType() may not return
null; there is the catch-all resource type "sling/servlet/default" -
this is equivalent to Object in Java. So here we go, we have a Sling
type-system in the makings ;)

Hope this helps clear up some misunderstandings.

Regards
Julian

[0] 
https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrItemResource.java#L117

On Thu, Nov 1, 2018 at 7:04 PM Jason E Bailey  wrote:
>
> >
> > Just to try and understand this better - you're saying that instead of
> > Sling falling back to the jcr:primaryType property in case of JCR
> > resources, the JCR resource provider should instead synthesize that
> > property itself, even if it does not exist?
> >
> > Robert
> >
>
> Right now there is an inconsistency between resources that are in the jcr and 
> resources that are in other resource providers. That inconsistency is that 
> all jcr resources have a jcr:primaryType. This is understandable because the 
> jcr has a Type system and there is a defined hierarchy of types in the jcr 
> that all lead back to nt:base.
>
> The fact that there is always a type is exploited by the ResourceResolver so 
> that it falls back to checking the jcr:primaryType if there is no  
> resourceType. This becomes problematic with ResourceProviders because 
> initially, there was never a requirement for them to provide either.
>
> There has been talk recently about creating a type system for resources.
> https://cwiki.apache.org/confluence/display/SLING/Sling+Type+System%3A+motivation+and+requirements.
>  For there to be a proper type system you need to have a Type hierarchy.
>
> Right now the getResourceType no longer allows you to return null, so it must 
> return something, if you're creating a resource provider that could be a 
> value that represents a "fake" resource.  In a type system that doesn't make 
> sense.
>
> If we implement a Sling Resource Type system we will be left with two options
> 1. All resources must have a valid sling:resourceType associated with it
> 2. Or consider a default sling:resourceType if none is present.
>
> -Jason

Re: Sling 12 themes

[Jason E Bailey]

> 
> Just to try and understand this better - you're saying that instead of
> Sling falling back to the jcr:primaryType property in case of JCR
> resources, the JCR resource provider should instead synthesize that
> property itself, even if it does not exist?
> 
> Robert
> 

Right now there is an inconsistency between resources that are in the jcr and 
resources that are in other resource providers. That inconsistency is that all 
jcr resources have a jcr:primaryType. This is understandable because the jcr 
has a Type system and there is a defined hierarchy of types in the jcr that all 
lead back to nt:base. 

The fact that there is always a type is exploited by the ResourceResolver so 
that it falls back to checking the jcr:primaryType if there is no  
resourceType. This becomes problematic with ResourceProviders because 
initially, there was never a requirement for them to provide either. 

There has been talk recently about creating a type system for resources. 
https://cwiki.apache.org/confluence/display/SLING/Sling+Type+System%3A+motivation+and+requirements.
 For there to be a proper type system you need to have a Type hierarchy.

Right now the getResourceType no longer allows you to return null, so it must 
return something, if you're creating a resource provider that could be a value 
that represents a "fake" resource.  In a type system that doesn't make sense.

If we implement a Sling Resource Type system we will be left with two options
1. All resources must have a valid sling:resourceType associated with it
2. Or consider a default sling:resourceType if none is present.

-Jason

Re: Sling 12 themes

[Robert Munteanu]

On Tue, 2018-10-30 at 20:48 +0100, Oliver Lietz wrote:
> > Wild idea: would it be possible to provide an optional extension
> > point
> > for scripting engines where they could signal that a link is
> > output?
> > Then we would have a central place for handling link rewriting.
> > 
> > I guess for HTL this would not be too hard, and if we cover JSP,
> > HTL
> > and maybe Freemarker/Tyhmeleaf this will be useful enough so that
> > we
> > can recommend using this instead of the more heavy-weight rewriter.
> > 
> > Thoughts?
> 
> Thymeleaf (and Sling Scripting Thymeleaf) already provides an
> extension point 
> for links:
> 
> https://www.thymeleaf.org/apidocs/thymeleaf/3.0.11.RELEASE/org/thymeleaf/linkbuilder/ILinkBuilder.html
> https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.html#link-urls
> https://www.thymeleaf.org/doc/articles/standardurlsyntax.html
> 
> I'm not sure if it makes sense to fit it in a common (cross-
> language) 
> Scripting API.

There are a lot of 'if's in my argument.

_If_ we decide that the major use case for the rewrite is adjusting
links and _if_ the rewriter is too heavyweight for that scenario and
_if_ it's possible to create a common, optional, API for scripting
engines to expose link rewriting _and_ if it's possible for the most
used scripting engines to implement then we should it ( _if_ anyone has
the time for it ).

My point is that we should not replace a global feature like the
rewriter with one that is scripting-engine dependent.

Thanks,

Robert

Re: Sling 12 themes

[Robert Munteanu]

On Tue, 2018-10-30 at 13:26 -0400, Jason E Bailey wrote:
> 
> - Jason
> 
> On Tue, Oct 30, 2018, at 5:50 AM, Robert Munteanu wrote:
> > Hi Jason,
> > 
> > On Tue, 2018-10-23 at 12:00 -0400, Jason E Bailey wrote:
> > > 1. Creating a resource provider to use as the default resource
> > > provider for the starter installation
> > > 2. Define a Resource 
> > > 3. Define a Resource Type hierarchy
> > > 4. Convert all  generated HTML to HTML5 standards
> > > 5. Fix the website
> > 
> > For 4, is this about the starter only or Sling in general?
> > 
> > For 5 - big +1 :-) . Do you have anything specific in mind?
> > 
> > Robert
> > 
> 
> Statement 4.
> My answer is everything. The Sling site, the generated html that
> comes from the various Sling pieces, anything in the starter. Just a
> whole, all around, let's get with the program. Cause it's kind of
> embarrassing.

Ack, agreed.

> 
> Statement 5.
> Explain why Sling is awesome on the first page, focus on what makes
> it wonderful and push the technology stack down a little bit. Refresh
> the look, make the structure consistent,  add more visual diagrams,
> cross link documentation to the download page so that there's a one
> stop shop for everything that you need. I could go on for a while I
> think.

Yeah, I guess many of us could :-) as the documentation is something
that we don't excel at.

FWIW, I know Chris Millar has some ongoing efforts to restyle the
website, but I don't know how far along he is.

Thanks,

Robert

Re: Sling 12 themes

[Robert Munteanu]

On Tue, 2018-10-30 at 13:18 -0400, Jason E Bailey wrote:
> On Tue, Oct 30, 2018, at 5:50 AM, Robert Munteanu wrote:
> > Hi Jason,
> > 
> > On Tue, 2018-10-23 at 12:00 -0400, Jason E Bailey wrote:
> > > 1. Creating a resource provider to use as the default resource
> > > provider for the starter installation
> > > 2. Define a Resource 
> > > 3. Define a Resource Type hierarchy
> > > 4. Convert all  generated HTML to HTML5 standards
> > > 5. Fix the website
> > 
> > Can you add some more information about 1-3? Are you looking to
> > build a
> > custom resource provider specifically for the starter?
> 
> For 2 and 3. 
> Well 2 is better then what it used to be we actually state what the
> resource needs to supply, but there's gaps around the concept of
> resourceType, and when a specific type is needed or not. Some of this
> comes from me working on a resource provider. Should all resources
> have a resourceType? Our code defaults to the node type if a resource
> type isn't defined. I think there's an argument that we shouldn't do
> that and that by default all resources should have a resourceType and
> a resourceProvider should add one if it hasn't been defined.
> 
> That's where we go into the concept of a resource type hierarchy and
> a type structure. 

Just to try and understand this better - you're saying that instead of
Sling falling back to the jcr:primaryType property in case of JCR
resources, the JCR resource provider should instead synthesize that
property itself, even if it does not exist?

Robert

Re: Sling 12 themes

[Robert Munteanu]

On Tue, 2018-10-30 at 13:10 -0400, Jason E Bailey wrote:
> 
> On Tue, Oct 30, 2018, at 5:50 AM, Robert Munteanu wrote:
> > Hi Jason,
> > 
> > On Tue, 2018-10-23 at 12:00 -0400, Jason E Bailey wrote:
> > > 1. Creating a resource provider to use as the default resource
> > > provider for the starter installation
> > > 2. Define a Resource 
> > > 3. Define a Resource Type hierarchy
> > > 4. Convert all  generated HTML to HTML5 standards
> > > 5. Fix the website
> > 
> > Can you add some more information about 1-3? Are you looking to
> > build a
> > custom resource provider specifically for the starter?
> 
> for statement 1:
> I'm going to try not to wander to much because there's a lot of
> emergent ideas that are all tied together on the mailing list. 
> 
> Let me state my view of Sling:
> Sling is a REST platform that wraps a key-value store that provides
> an easy way to store and retrieve data using a URI and to change how
> that data is presented in a consistent manner.
> 
> Sling provides OOTB
> # Authentication
> # User and Group  Management
> # Scripting Support
> # POST modification
> # Multiple Rendering Support
> # Support for multiple data store back ends, whether it's  local or
> cloud.
> 
> Saying that, some of this isn't true because Sling was tied so
> closely to the jcr in the early days that Sling delegated
> functionality to the jcr that should have been at the Sling
> level.  Part of overcoming that is to have a default data store that
> is used by the starter that is maintained by the Sling team. Ideally
> it should be able to handle a production site. 

It is 100% correct that there is a close relationship between Sling and
JCR/Jackrabbit/Oak. We do rely on the JCR (and sometimes
Jackrabbit/Oak) APIs to implement various pieces of functionality.

In my opinion that's not necessarily a bad thing. Oak is a fast and
featureful persistence engine that happens to be perfectly aligned with
Sling's goals. Well, IIRC Sling was written for Jackrabbit and that's
no accident :-)

That being said, I am not opposed to anyone trying to use another
persistence engine with Sling and we have made some efforts towards
decoupling Sling from JCR.

Let's see where that takes us :-)

Robert

Re: Sling 12 themes[HTL Rant]

[Bertrand Delacretaz]

Hi Jason,

Thank you very much for sharing your thoughts!

On Wed, Oct 31, 2018 at 4:32 PM Jason E Bailey  wrote:
> ...Then BAMM all of a sudden it's the only official way of creating components
> in AEM. There's people posting on Stackoverflow how it's "best practices." 
> Throw
> a stone at an AEM consultant and he'll yelp "HTL"...

AEM is not Sling ;-)

People using Sling are totally entitled to declare some of its modules
"best practices" for their products, which I think is what's happening
here. But in Sling I think we need to stay agnostic to such things.

Of course we need to decide what gets into the default Starter module,
and it's good to be consistent there and don't provide too many
options.

But if there is an option that you'd like to see there and is missing,
please speak up!

Also, it's totally possible to produce alternate default assemblies as
contrib modules - even if it's good to focus on one standard assembly
in terms of integration testing, if someone wants to do the work of
creating and supporting other variants I'm all in favor of that.

-Bertrand

Re: Sling 12 themes[HTL Rant]

[Radu Cotescu]

Hi Jason,

Thanks for taking the time to write such a detailed reply.

> On 31 Oct 2018, at 16:32, Jason E Bailey  wrote:
> 
> First there were the initial use cases that didn't make much sense to me. 
> 
> 1. There wasn't anything else out there that did this. -> (*cough* *cough* 
> thymeleaf)
> 
> 2. That it allowed you to separate front end and back end developers so that 
> back end developers wouldn't be thrown by the complexities of creating html 
> in the manner that the designer wanted. -> I've never experience that, ever. 
> If I had a developer who couldn't figure out how to make html he wouldn't be 
> working for me long. 

I think that here the logic was the exact opposite - empower a front-end 
developer to write the presentation code for a component, given that they have 
some API available  for the dynamic part of the component.

> 
> 3. It allowed it to be pure html with no custom tags. So that you could just 
> take the html that a designer gave you and plug it in -> That didn't last 
> long.

What prevents you from outputting   custom tags? Or why should they not be 
allowed?

> 
> So I was like fine. It'll be a tool in the tool chest and that if it was that 
> good it would eventually be the thing that everyone uses. Then BAMM all of a 
> sudden it's the only official way of creating components in AEM. There's 
> people posting on Stackoverflow how it's "best practices." Throw a stone at 
> an AEM consultant and he'll yelp "HTL" 
> 
> Now, in part I get this. It depends on the use case. If you're a consultant 
> or a freelancer this makes sense. Your dealing with clients who are throwing 
> a design to you that they've mocked up in some design software.  Where they 
> want to have you create a set of pages, this kind of feature makes sense that 
> you could go thrown cut out the html and add functionality to it so that the 
> final page works with the CSS the designer created. 
> 
> That's never been my use case. I've always done long term projects where I'm 
> building up a suite of components that are re-used across tenants. I don't 
> get a request for a page. The designers are in the system and are customizing 
> components that have already been created or working with the authors and 
> developers to create a very specific component that has all of 2 or 3 layer 
> of html.
> 
> Having a separate person to just render that structure in a component would 
> be a waste of time and resources.
> 
> Does that matter? No. Remember the consultants? Remember the only official 
> way of doing things? If I have a problem with a component... why aren't you 
> using HTL? Bring in a consultant, "you can save money/time by using HTL", 
> really I looked at it, it doesn't help me. "But.. but... best practices"
> 
> Then they whip out contextual rendering. Which, quite honestly is great, I 
> don't need to manually do the encode stuff anymore. That alone makes it a 
> nice to use and something to consider. Although it could also have been done 
> in the rewriter and then you would have had encoding done everywhere without 
> regard to the script creating the html but that's a separate conversation.
> 
> So that's why I resent it. I dislike blind followers who use the phrase "best 
> practices" because they can't articulate the real reasons to do things. I 
> resent being told that all of the work that I've been doing should be redone 
> for reasons that don't logistically or financially make sense. Yet at some 
> point I'm going to do just that because at some point my team needs to 
> understand HTL to work with it.
> 
> Heh, the cult of HTL is strong enough I've probably talked myself out of 
> future job positions. But I've never been one not to state an opinion.
> 
> [/RANT]
> 
> - Jason
> 

I have to agree with you here. HTL should not be in itself named a best 
practice without a proper guide on how to use it. I’ve seen tons of poorly 
written HTL, as well as all kinds of hacks (e.g. JSON output through an HTL 
component, XML, you name it).

To play the devil’s advocate here, I think that what consultants tried to say, 
without being able to fully articulate their opinions, is that HTL is 
restrictive enough that it forces you to write cleaner code - you cannot mix 
logic and presentation code in the same file. However, that shouldn’t be 
interpreted as “use HTL exclusively, JSP is horrible” if your shop is able to 
produce clean JSP (or whatever you fancy) scripts, with logic provided by say 
Sling Models. However, I think that there are very few companies that produce 
100% scriptlet-free JSPs, hence why some consultants came up with this black 
and white view of what a best practice for your presentation layer is.

There are two great articles about HTL which everybody in this community should 
read: [0], written by Dan Klco, and [1], written by Jörg Hoh, as a reply to Dan.

Cheers,
Radu

[0] - 

Re: Sling 12 themes[HTL Rant]

[Jason E Bailey]

First there were the initial use cases that didn't make much sense to me. 

1. There wasn't anything else out there that did this. -> (*cough* *cough* 
thymeleaf)

2. That it allowed you to separate front end and back end developers so that 
back end developers wouldn't be thrown by the complexities of creating html in 
the manner that the designer wanted. -> I've never experience that, ever. If I 
had a developer who couldn't figure out how to make html he wouldn't be working 
for me long. 

3. It allowed it to be pure html with no custom tags. So that you could just 
take the html that a designer gave you and plug it in -> That didn't last long.

So I was like fine. It'll be a tool in the tool chest and that if it was that 
good it would eventually be the thing that everyone uses. Then BAMM all of a 
sudden it's the only official way of creating components in AEM. There's people 
posting on Stackoverflow how it's "best practices." Throw a stone at an AEM 
consultant and he'll yelp "HTL" 

Now, in part I get this. It depends on the use case. If you're a consultant or 
a freelancer this makes sense. Your dealing with clients who are throwing a 
design to you that they've mocked up in some design software.  Where they want 
to have you create a set of pages, this kind of feature makes sense that you 
could go thrown cut out the html and add functionality to it so that the final 
page works with the CSS the designer created. 

That's never been my use case. I've always done long term projects where I'm 
building up a suite of components that are re-used across tenants. I don't get 
a request for a page. The designers are in the system and are customizing 
components that have already been created or working with the authors and 
developers to create a very specific component that has all of 2 or 3 layer of 
html.

Having a separate person to just render that structure in a component would be 
a waste of time and resources.

Does that matter? No. Remember the consultants? Remember the only official way 
of doing things? If I have a problem with a component... why aren't you using 
HTL? Bring in a consultant, "you can save money/time by using HTL", really I 
looked at it, it doesn't help me. "But.. but... best practices"

Then they whip out contextual rendering. Which, quite honestly is great, I 
don't need to manually do the encode stuff anymore. That alone makes it a nice 
to use and something to consider. Although it could also have been done in the 
rewriter and then you would have had encoding done everywhere without regard to 
the script creating the html but that's a separate conversation.

So that's why I resent it. I dislike blind followers who use the phrase "best 
practices" because they can't articulate the real reasons to do things. I 
resent being told that all of the work that I've been doing should be redone 
for reasons that don't logistically or financially make sense. Yet at some 
point I'm going to do just that because at some point my team needs to 
understand HTL to work with it.

Heh, the cult of HTL is strong enough I've probably talked myself out of future 
job positions. But I've never been one not to state an opinion.

[/RANT]

- Jason

On Wed, Oct 31, 2018, at 9:58 AM, Radu Cotescu wrote:
> Hi Jason,
> 
> There’s nothing wrong with that. Any Script Engine that we have in Sling 
> is just a tool in the chest. :)
> 
> Can I ask, though, why do you say it was forced on you?
> 
> Thanks,
> Radu
> 
> > On 30 Oct 2018, at 21:07, Jason E Bailey  wrote:
> > 
> > Since this is a public record, I'm going to clarify myself.  I don't 
> > dislike it. I resent it. And the way it felt like it was forced on me for 
> > no good reason.  However, in it's own right,  it's a decent solution.
> > 
> > - Jason
> > 
> > On Tue, Oct 23, 2018, at 12:42 PM, Jason E Bailey wrote:
> >> 1. I don't use HTL
> >> 
> >> 2. When I last mucked with HTL, and this could have changed, it had 
> >> problems itself with HTML5
> >> 
> >> 3. When I've used the rewriter it's because I need something centralized 
> >> that is modifying HTML with out regard to where the  HTML is coming 
> >> from.
> >> 
> >> 4. I dislike HTL
> >> 
> >> 5. I really dislike HTL
> >> 
> >> - Jason
> >> 
> >> On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote:
> 

Re: Sling 12 themes

[Radu Cotescu]

Hi Jason,

There’s nothing wrong with that. Any Script Engine that we have in Sling is 
just a tool in the chest. :)

Can I ask, though, why do you say it was forced on you?

Thanks,
Radu

> On 30 Oct 2018, at 21:07, Jason E Bailey  wrote:
> 
> Since this is a public record, I'm going to clarify myself.  I don't dislike 
> it. I resent it. And the way it felt like it was forced on me for no good 
> reason.  However, in it's own right,  it's a decent solution.
> 
> - Jason
> 
> On Tue, Oct 23, 2018, at 12:42 PM, Jason E Bailey wrote:
>> 1. I don't use HTL
>> 
>> 2. When I last mucked with HTL, and this could have changed, it had 
>> problems itself with HTML5
>> 
>> 3. When I've used the rewriter it's because I need something centralized 
>> that is modifying HTML with out regard to where the  HTML is coming 
>> from.
>> 
>> 4. I dislike HTL
>> 
>> 5. I really dislike HTL
>> 
>> - Jason
>> 
>> On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote:

Re: Sling 12 themes

[Jason E Bailey]

I think this is a legitimate ask. This goes back to a "what is sling" 
fundamental. If Sling is only there to produce HTML and json is a convenience 
then a rewriter for JSON doesn't make sense. If, however, JSON is a truly 
supported output model, then we need to consider how we support such things as 
URL re-writing either universally, or specifically for JSON.

- Jason

On Tue, Oct 23, 2018, at 1:08 PM, Ruben Reusser wrote:
> since we now have sling models and sling model exporters I would also 
> kind of like a rewrite chain on json to shorten URLs for example.
> 
> Ruben
> 
> 
> On 10/23/2018 9:59 AM, Jason E Bailey wrote:
> > It depends on what I'm writing and where, whether it's server side or front 
> > end. But in general I use a combination of html/jsp and models for the 
> > majority of my code. The delta between what the html looks like between 
> > these implementations is usually minor.
> >
> > I do like the contextual awareness that HTL brings, I was doing something 
> > similar in the rewriter before HTL became a thing. But I like it as a tool 
> > in the chest. Not as something that is required.
> >
> > - Jason
> >
> > On Tue, Oct 23, 2018, at 12:50 PM, Carsten Ziegeler wrote:
> >> So what do you like for creating html?
> >>
> >> Carsten
> >>
> >> Am 23.10.2018 um 18:42 schrieb Jason E Bailey:
> >>> 1. I don't use HTL
> >>>
> >>> 2. When I last mucked with HTL, and this could have changed, it had 
> >>> problems itself with HTML5
> >>>
> >>> 3. When I've used the rewriter it's because I need something centralized 
> >>> that is modifying HTML with out regard to where the  HTML is coming from.
> >>>
> >>> 4. I dislike HTL
> >>>
> >>> 5. I really dislike HTL
> >>>
> >>> - Jason
> >>>
> >>> On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote:
>  Why do we need a rewriter if we're using HTL? I think a plugin model to
>  influence or inspect the html using HTL is way more efficient as HTL
>  already knowns the context of an element.
> 
>  Regards
>  Carsten
> 
>  Am 23.10.2018 um 18:02 schrieb Jason E Bailey:
> >
> > On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote:
> >> A couple thoughts from my end:
> >>  - Cleanup of the Rewriter, providing a HTML 5 pipeline
> > I was going to start working on the HTML 5  rewriter next week.
> >
> > - Jason
> >
>  -- 
>  Carsten Ziegeler
>  Adobe Research Switzerland
>  cziege...@apache.org
> >> -- 
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziege...@apache.org
> 

Re: Sling 12 themes

[Jason E Bailey]

Since this is a public record, I'm going to clarify myself.  I don't dislike 
it. I resent it. And the way it felt like it was forced on me for no good 
reason.  However, in it's own right,  it's a decent solution.

- Jason

On Tue, Oct 23, 2018, at 12:42 PM, Jason E Bailey wrote:
> 1. I don't use HTL
> 
> 2. When I last mucked with HTL, and this could have changed, it had 
> problems itself with HTML5
> 
> 3. When I've used the rewriter it's because I need something centralized 
> that is modifying HTML with out regard to where the  HTML is coming 
> from.
> 
> 4. I dislike HTL
> 
> 5. I really dislike HTL
> 
> - Jason
> 
> On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote:
> > Why do we need a rewriter if we're using HTL? I think a plugin model to 
> > influence or inspect the html using HTL is way more efficient as HTL 
> > already knowns the context of an element.
> > 
> > Regards
> > Carsten
> > 
> > Am 23.10.2018 um 18:02 schrieb Jason E Bailey:
> > > 
> > > 
> > > On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote:
> > >> A couple thoughts from my end:
> > >>- Cleanup of the Rewriter, providing a HTML 5 pipeline
> > > 
> > > I was going to start working on the HTML 5  rewriter next week.
> > > 
> > > - Jason
> > > 
> > 
> > -- 
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org

Re: Sling 12 themes

[Oliver Lietz]

On Monday 29 October 2018 11:37:47 Robert Munteanu wrote:
> On Wed, 2018-10-24 at 07:19 +0200, 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.
> 
> +1 to this and also to Konrad's point of listing use cases for the
> rewriter.
> 
> I like the rewriter since it is elegantly decoupled from other parts of
> the request handling process, but at the same time parsing the whole
> HTML response is heavyweight and IMO should be done only in specific
> circumstances.

+1

> -
> 
> Wild idea: would it be possible to provide an optional extension point
> for scripting engines where they could signal that a link is output?
> Then we would have a central place for handling link rewriting.
> 
> I guess for HTL this would not be too hard, and if we cover JSP, HTL
> and maybe Freemarker/Tyhmeleaf this will be useful enough so that we
> can recommend using this instead of the more heavy-weight rewriter.
> 
> Thoughts?

Thymeleaf (and Sling Scripting Thymeleaf) already provides an extension point 
for links:

https://www.thymeleaf.org/apidocs/thymeleaf/3.0.11.RELEASE/org/thymeleaf/linkbuilder/ILinkBuilder.html
https://www.thymeleaf.org/doc/tutorials/3.0/usingthymeleaf.html#link-urls
https://www.thymeleaf.org/doc/articles/standardurlsyntax.html

I'm not sure if it makes sense to fit it in a common (cross-language) 
Scripting API.

Regards,
O.

> Robert

Re: Sling 12 themes

[Jason E Bailey]

- Jason

On Tue, Oct 30, 2018, at 5:50 AM, Robert Munteanu wrote:
> Hi Jason,
> 
> On Tue, 2018-10-23 at 12:00 -0400, Jason E Bailey wrote:
> > 1. Creating a resource provider to use as the default resource
> > provider for the starter installation
> > 2. Define a Resource 
> > 3. Define a Resource Type hierarchy
> > 4. Convert all  generated HTML to HTML5 standards
> > 5. Fix the website
> 
> For 4, is this about the starter only or Sling in general?
> 
> For 5 - big +1 :-) . Do you have anything specific in mind?
> 
> Robert
> 


Statement 4.
My answer is everything. The Sling site, the generated html that comes from the 
various Sling pieces, anything in the starter. Just a whole, all around, let's 
get with the program. Cause it's kind of embarrassing.

Statement 5.
Explain why Sling is awesome on the first page, focus on what makes it 
wonderful and push the technology stack down a little bit. Refresh the look, 
make the structure consistent,  add more visual diagrams, cross link 
documentation to the download page so that there's a one stop shop for 
everything that you need. I could go on for a while I think.

Re: Sling 12 themes

[Jason E Bailey]

On Tue, Oct 30, 2018, at 5:50 AM, Robert Munteanu wrote:
> Hi Jason,
> 
> On Tue, 2018-10-23 at 12:00 -0400, Jason E Bailey wrote:
> > 1. Creating a resource provider to use as the default resource
> > provider for the starter installation
> > 2. Define a Resource 
> > 3. Define a Resource Type hierarchy
> > 4. Convert all  generated HTML to HTML5 standards
> > 5. Fix the website
> 
> Can you add some more information about 1-3? Are you looking to build a
> custom resource provider specifically for the starter?

For 2 and 3. 
Well 2 is better then what it used to be we actually state what the resource 
needs to supply, but there's gaps around the concept of resourceType, and when 
a specific type is needed or not. Some of this comes from me working on a 
resource provider. Should all resources have a resourceType? Our code defaults 
to the node type if a resource type isn't defined. I think there's an argument 
that we shouldn't do that and that by default all resources should have a 
resourceType and a resourceProvider should add one if it hasn't been defined.

That's where we go into the concept of a resource type hierarchy and a type 
structure. 

Re: Sling 12 themes

[Jason E Bailey]

On Tue, Oct 30, 2018, at 5:50 AM, Robert Munteanu wrote:
> Hi Jason,
> 
> On Tue, 2018-10-23 at 12:00 -0400, Jason E Bailey wrote:
> > 1. Creating a resource provider to use as the default resource
> > provider for the starter installation
> > 2. Define a Resource 
> > 3. Define a Resource Type hierarchy
> > 4. Convert all  generated HTML to HTML5 standards
> > 5. Fix the website
> 
> Can you add some more information about 1-3? Are you looking to build a
> custom resource provider specifically for the starter?

for statement 1:
I'm going to try not to wander to much because there's a lot of emergent ideas 
that are all tied together on the mailing list. 

Let me state my view of Sling:
Sling is a REST platform that wraps a key-value store that provides an easy way 
to store and retrieve data using a URI and to change how that data is presented 
in a consistent manner.

Sling provides OOTB
# Authentication
# User and Group  Management
# Scripting Support
# POST modification
# Multiple Rendering Support
# Support for multiple data store back ends, whether it's  local or cloud.

Saying that, some of this isn't true because Sling was tied so closely to the 
jcr in the early days that Sling delegated functionality to the jcr that should 
have been at the Sling level.  Part of overcoming that is to have a default 
data store that is used by the starter that is maintained by the Sling team. 
Ideally it should be able to handle a production site. 

Re: Sling 12 themes

[Robert Munteanu]

On Mon, 2018-10-29 at 12:03 +0100, Radu Cotescu wrote:
> Hi Robert,
> 
> > On 29 Oct 2018, at 11:37, Robert Munteanu 
> > wrote:
> > 
> > Wild idea: would it be possible to provide an optional extension
> > point
> > for scripting engines where they could signal that a link is
> > output?
> > Then we would have a central place for handling link rewriting.
> > 
> > I guess for HTL this would not be too hard, and if we cover JSP,
> > HTL
> > and maybe Freemarker/Tyhmeleaf this will be useful enough so that
> > we
> > can recommend using this instead of the more heavy-weight rewriter.
> 
> Indeed, for HTL this would be a trivial change since the engine
> always knows the context in which it operates. However, keep in mind
> that this is a compile-time operation. If we want to transpose this
> information at run-time, I guess we could write a RuntimeFunction
> handling link outputs, that would in turn delegate to the new link
> rewriter.

Thanks Radu, good to know.

Robert

Re: Sling 12 themes

[Robert Munteanu]

On Tue, 2018-10-23 at 21:17 +0200, Jörg Hoh wrote:
> Am Di., 23. Okt. 2018 um 16:29 Uhr schrieb Robert Munteanu <
> romb...@apache.org>:
> 
> > I think it would be an interesting and worthwhile exercise to see
> > what
> > various contributors would like to see as the major themes of Sling
> > 12.
> > 
> > 
> I would like to have some cleanup done
> * get rid of dependencies to old versions (e.g. we still have modules
> depending on Oak 1.4)

Is that a bad thing per se? It would be unadvisable at runtime, but on
the other hand it keeps the imports relaxed, and therefore allows
consumers that use old Oak versions to keep working.

> * Would be great to improve consistency in terms of tests and test
> frameworks, so we have examples for writing tests properly (both unit
> and
> integration tests)

Yes, that is something which would be great.

> 
> And of course the documentation can always be improved. Would
> absolutely
> love if we could also have the "old" documentation for reference
> (there are
> people out there which cannot always use the most recent version of
> Sling,
> therefor having the old docs available would be beneficial (next to
> the old
> API docs).
> 

Do you mean the Javadocs or the reference documentation? Old versions
should still be available in any case.

Thanks,

Robert

Re: Sling 12 themes

[Robert Munteanu]

Hi Jason,

On Tue, 2018-10-23 at 12:00 -0400, Jason E Bailey wrote:
> 1. Creating a resource provider to use as the default resource
> provider for the starter installation
> 2. Define a Resource 
> 3. Define a Resource Type hierarchy
> 4. Convert all  generated HTML to HTML5 standards
> 5. Fix the website

Can you add some more information about 1-3? Are you looking to build a
custom resource provider specifically for the starter?

For 4, is this about the starter only or Sling in general?

For 5 - big +1 :-) . Do you have anything specific in mind?

Robert

Re: Sling 12 themes

[Radu Cotescu]

Hi Robert,

> On 29 Oct 2018, at 11:37, Robert Munteanu  wrote:
> 
> Wild idea: would it be possible to provide an optional extension point
> for scripting engines where they could signal that a link is output?
> Then we would have a central place for handling link rewriting.
> 
> I guess for HTL this would not be too hard, and if we cover JSP, HTL
> and maybe Freemarker/Tyhmeleaf this will be useful enough so that we
> can recommend using this instead of the more heavy-weight rewriter.

Indeed, for HTL this would be a trivial change since the engine always knows 
the context in which it operates. However, keep in mind that this is a 
compile-time operation. If we want to transpose this information at run-time, I 
guess we could write a RuntimeFunction handling link outputs, that would in 
turn delegate to the new link rewriter.

Cheers,
Radu

Re: Sling 12 themes

[Robert Munteanu]

On Wed, 2018-10-24 at 07:19 +0200, 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.

+1 to this and also to Konrad's point of listing use cases for the
rewriter.

I like the rewriter since it is elegantly decoupled from other parts of
the request handling process, but at the same time parsing the whole
HTML response is heavyweight and IMO should be done only in specific
circumstances.

-

Wild idea: would it be possible to provide an optional extension point
for scripting engines where they could signal that a link is output?
Then we would have a central place for handling link rewriting.

I guess for HTL this would not be too hard, and if we cover JSP, HTL
and maybe Freemarker/Tyhmeleaf this will be useful enough so that we
can recommend using this instead of the more heavy-weight rewriter.

Thoughts?

Robert

Re: Sling 12 themes

[Georg Henzler]

I totally support the idea of having better typed support for resource 
paths and resource urls. I have seen many bugs in projects because 
people naively operate on string urls (ignoring special cases around 
query, fragment, selectors, encoding)... I would love to see a 
ResourceUrl class (@Jörg I think this name is good) that supports 
operations like setSelectors(), setResourcePath(), setFragment(), etc. 
We could then even enhance the resourceResolver API a little bit to 
allow rr.resolveToResourceUrl(). The rewriter pipeline could also use 
this abstraction (instead of dealing with strings only).


On 2018-10-24 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



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

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

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
> 

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

Re: Sling 12 themes

[Carsten Ziegeler]

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

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 

Re: Sling 12 themes

[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

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
provide that functionality as Sling is focusing on the server side.


Missing a point here I think. If you are focusing on link rewriting,

that

is something that can only occur on the server side.  Helps 

Re: Sling 12 themes

[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.
> >>
> >> 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
> >>> provide that functionality as Sling is focusing on the server side.
> >>
> >> Missing a point here I think. If you are focusing on link rewriting,
> that
> >> is something that can only occur on the server side.  Helps with
> >> multi-tenancy and cross linking.
> >>
> >
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: Sling 12 themes

[Carsten Ziegeler]

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
provide that functionality as Sling is focusing on the server side.


Missing a point here I think. If you are focusing on link rewriting, that
is something that can only occur on the server side.  Helps with
multi-tenancy and cross linking.





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

Re: Sling 12 themes

[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
> > provide that functionality as Sling is focusing on the server side.
>
> Missing a point here I think. If you are focusing on link rewriting, that
> is something that can only occur on the server side.  Helps with
> multi-tenancy and cross linking.
>

Re: Sling 12 themes

[Jörg Hoh]

Am Di., 23. Okt. 2018 um 16:29 Uhr schrieb Robert Munteanu <
romb...@apache.org>:

>
> I think it would be an interesting and worthwhile exercise to see what
> various contributors would like to see as the major themes of Sling 12.
>
>
I would like to have some cleanup done
* get rid of dependencies to old versions (e.g. we still have modules
depending on Oak 1.4)
* Would be great to improve consistency in terms of tests and test
frameworks, so we have examples for writing tests properly (both unit and
integration tests)

And of course the documentation can always be improved. Would absolutely
love if we could also have the "old" documentation for reference (there are
people out there which cannot always use the most recent version of Sling,
therefor having the old docs available would be beneficial (next to the old
API docs).

-- 
Cheers,
Jörg Hoh,

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

Re: Sling 12 themes

[Jason E Bailey]

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 
> provide that functionality as Sling is focusing on the server side.

Missing a point here I think. If you are focusing on link rewriting, that is 
something that can only occur on the server side.  Helps with multi-tenancy and 
cross linking.

Re: Sling 12 themes

[Konrad Windszus]

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. 

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 provide 
that functionality as Sling is focusing on the server side.
Konrad

> Am 23.10.2018 um 19:08 schrieb Ruben Reusser :
> 
> since we now have sling models and sling model exporters I would also kind of 
> like a rewrite chain on json to shorten URLs for example.
> 
> Ruben
> 
> 
>> On 10/23/2018 9:59 AM, Jason E Bailey wrote:
>> It depends on what I'm writing and where, whether it's server side or front 
>> end. But in general I use a combination of html/jsp and models for the 
>> majority of my code. The delta between what the html looks like between 
>> these implementations is usually minor.
>> 
>> I do like the contextual awareness that HTL brings, I was doing something 
>> similar in the rewriter before HTL became a thing. But I like it as a tool 
>> in the chest. Not as something that is required.
>> 
>> - Jason
>> 
>>> On Tue, Oct 23, 2018, at 12:50 PM, Carsten Ziegeler wrote:
>>> So what do you like for creating html?
>>> 
>>> Carsten
>>> 
 Am 23.10.2018 um 18:42 schrieb Jason E Bailey:
 1. I don't use HTL
 
 2. When I last mucked with HTL, and this could have changed, it had 
 problems itself with HTML5
 
 3. When I've used the rewriter it's because I need something centralized 
 that is modifying HTML with out regard to where the  HTML is coming from.
 
 4. I dislike HTL
 
 5. I really dislike HTL
 
 - Jason
 
> On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote:
> Why do we need a rewriter if we're using HTL? I think a plugin model to
> influence or inspect the html using HTL is way more efficient as HTL
> already knowns the context of an element.
> 
> Regards
> Carsten
> 
>> Am 23.10.2018 um 18:02 schrieb Jason E Bailey:
>> 
>>> On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote:
>>> A couple thoughts from my end:
>>> - Cleanup of the Rewriter, providing a HTML 5 pipeline
>> I was going to start working on the HTML 5  rewriter next week.
>> 
>> - Jason
>> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>>> -- 
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
> 

Re: Sling 12 themes

[Ruben Reusser]

since we now have sling models and sling model exporters I would also 
kind of like a rewrite chain on json to shorten URLs for example.


Ruben


On 10/23/2018 9:59 AM, Jason E Bailey wrote:

It depends on what I'm writing and where, whether it's server side or front 
end. But in general I use a combination of html/jsp and models for the majority 
of my code. The delta between what the html looks like between these 
implementations is usually minor.

I do like the contextual awareness that HTL brings, I was doing something 
similar in the rewriter before HTL became a thing. But I like it as a tool in 
the chest. Not as something that is required.

- Jason

On Tue, Oct 23, 2018, at 12:50 PM, Carsten Ziegeler wrote:

So what do you like for creating html?

Carsten

Am 23.10.2018 um 18:42 schrieb Jason E Bailey:

1. I don't use HTL

2. When I last mucked with HTL, and this could have changed, it had problems 
itself with HTML5

3. When I've used the rewriter it's because I need something centralized that 
is modifying HTML with out regard to where the  HTML is coming from.

4. I dislike HTL

5. I really dislike HTL

- Jason

On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote:

Why do we need a rewriter if we're using HTL? I think a plugin model to
influence or inspect the html using HTL is way more efficient as HTL
already knowns the context of an element.

Regards
Carsten

Am 23.10.2018 um 18:02 schrieb Jason E Bailey:


On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote:

A couple thoughts from my end:
 - Cleanup of the Rewriter, providing a HTML 5 pipeline

I was going to start working on the HTML 5  rewriter next week.

- Jason


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

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

Re: Sling 12 themes

[Jason E Bailey]

It depends on what I'm writing and where, whether it's server side or front 
end. But in general I use a combination of html/jsp and models for the majority 
of my code. The delta between what the html looks like between these 
implementations is usually minor.

I do like the contextual awareness that HTL brings, I was doing something 
similar in the rewriter before HTL became a thing. But I like it as a tool in 
the chest. Not as something that is required.

- Jason

On Tue, Oct 23, 2018, at 12:50 PM, Carsten Ziegeler wrote:
> So what do you like for creating html?
> 
> Carsten
> 
> Am 23.10.2018 um 18:42 schrieb Jason E Bailey:
> > 1. I don't use HTL
> > 
> > 2. When I last mucked with HTL, and this could have changed, it had 
> > problems itself with HTML5
> > 
> > 3. When I've used the rewriter it's because I need something centralized 
> > that is modifying HTML with out regard to where the  HTML is coming from.
> > 
> > 4. I dislike HTL
> > 
> > 5. I really dislike HTL
> > 
> > - Jason
> > 
> > On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote:
> >> Why do we need a rewriter if we're using HTL? I think a plugin model to
> >> influence or inspect the html using HTL is way more efficient as HTL
> >> already knowns the context of an element.
> >>
> >> Regards
> >> Carsten
> >>
> >> Am 23.10.2018 um 18:02 schrieb Jason E Bailey:
> >>>
> >>>
> >>> On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote:
>  A couple thoughts from my end:
>  - Cleanup of the Rewriter, providing a HTML 5 pipeline
> >>>
> >>> I was going to start working on the HTML 5  rewriter next week.
> >>>
> >>> - Jason
> >>>
> >>
> >> -- 
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziege...@apache.org
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Sling 12 themes

[Carsten Ziegeler]

So what do you like for creating html?

Carsten

Am 23.10.2018 um 18:42 schrieb Jason E Bailey:

1. I don't use HTL

2. When I last mucked with HTL, and this could have changed, it had problems 
itself with HTML5

3. When I've used the rewriter it's because I need something centralized that 
is modifying HTML with out regard to where the  HTML is coming from.

4. I dislike HTL

5. I really dislike HTL

- Jason

On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote:

Why do we need a rewriter if we're using HTL? I think a plugin model to
influence or inspect the html using HTL is way more efficient as HTL
already knowns the context of an element.

Regards
Carsten

Am 23.10.2018 um 18:02 schrieb Jason E Bailey:



On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote:

A couple thoughts from my end:
- Cleanup of the Rewriter, providing a HTML 5 pipeline


I was going to start working on the HTML 5  rewriter next week.

- Jason



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


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

Re: Sling 12 themes

[Carsten Ziegeler]

Why do we need a rewriter if we're using HTL? I think a plugin model to 
influence or inspect the html using HTL is way more efficient as HTL 
already knowns the context of an element.


Regards
Carsten

Am 23.10.2018 um 18:02 schrieb Jason E Bailey:



On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote:

A couple thoughts from my end:
   - Cleanup of the Rewriter, providing a HTML 5 pipeline


I was going to start working on the HTML 5  rewriter next week.

- Jason



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

Re: Sling 12 themes

[Jason E Bailey]

On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote:
> A couple thoughts from my end:
>   - Cleanup of the Rewriter, providing a HTML 5 pipeline

I was going to start working on the HTML 5  rewriter next week.

- Jason

Re: Sling 12 themes

[Jason E Bailey]

1. Creating a resource provider to use as the default resource provider for the 
starter installation
2. Define a Resource 
3. Define a Resource Type hierarchy
4. Convert all  generated HTML to HTML5 standards
5. Fix the website

- Jason

On Tue, Oct 23, 2018, at 10:29 AM, Robert Munteanu wrote:
> Hi,
> 
> Now that Sling 11 is out, we should be thinking about Sling 12 already
> :-) .
> 
> Each Sling release brings in hundreds of individual changes in the form
> of bug fixes and incremental improvements. On top of that, we also have
> major features or themes for the release, such as:
> 
> * updating to OSGi R7 (Sling 11)
> * Github migration (~Sling 10)
> * Refreshing the default ACL setup (Sling 11)
> * Enhanced Java 9+ support (Sling 10,11)
> 
> I think it would be an interesting and worthwhile exercise to see what
> various contributors would like to see as the major themes of Sling 12.
> 
> So, fire away :-)
> 
> Thanks,
> 
> Robert
> 
> 

Re: Sling 12 themes

[Daniel Klco]

A couple thoughts from my end:

   - Integration with Apache OpenWisk
   - expose Apache Sling content and output via dedicated endpoints and
  functions
  - Add an integration layer for jobs to be invoked from Sling and
  completed in OpenWisk
  - Cleanup of the Rewriter, providing a HTML 5 pipeline
   - Security features -- try to make it easier to make a "default"
   installation of Sling secure:
  - Login failure lockout
  - Filter selectors / suffixes
  - Deduplicate slashes
  -
  https://speakerdeck.com/0ang3el/hunting-for-security-bugs-in-aem-webapps


On Tue, Oct 23, 2018 at 10:30 AM Robert Munteanu  wrote:

> Hi,
>
> Now that Sling 11 is out, we should be thinking about Sling 12 already
> :-) .
>
> Each Sling release brings in hundreds of individual changes in the form
> of bug fixes and incremental improvements. On top of that, we also have
> major features or themes for the release, such as:
>
> * updating to OSGi R7 (Sling 11)
> * Github migration (~Sling 10)
> * Refreshing the default ACL setup (Sling 11)
> * Enhanced Java 9+ support (Sling 10,11)
>
> I think it would be an interesting and worthwhile exercise to see what
> various contributors would like to see as the major themes of Sling 12.
>
> So, fire away :-)
>
> Thanks,
>
> Robert
>
>
>