Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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,

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes[HTL Rant]

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

Re: Sling 12 themes[HTL Rant]

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

Re: Sling 12 themes[HTL Rant]

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

- 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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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.

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

Re: Sling 12 themes

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

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

Re: Sling 12 themes

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,

Sling 12 themes

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