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
