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 <cziege...@apache.org > <mailto:cziege...@apache.org>> 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 <mailto: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 <mailto:cziege...@apache.org>
