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
