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
