As I see it, PackageResourceReference shouldn't be doing url decoding
looking for the resource style/variant/locale, instead, its internal state
should be enough to resolve a PackageResource. The consequence for such
change would be in ResourceMapper which depends upon
PackageResourceReference to map a resource that will return a
PackageResource based on the style/variant/locale in the url. To
exemplify, if we mount a resource as:
app.mountResource("/style.css", packageResourceReference);
A request to "/style.css?-yellow" will return the yellow-styled css, but
after the proposed change it will only return the css resolved by
packageResourceReference internal state. To enable users to keep mounting
package resources to a specific url as it's done today, I propose that we
implement another IRequestMapper that takes as parameters only the scope
and name of the resource. To users, the api would be something like:
app.mountResource("/style.css", Page.class, "file.css");
Like ResourceMapper, the new mapper will also return a
ResourceReferenceRequestHandler with a PackageResourceReference, but this
time all the url decoding would be done inside a mapper (in
BasicResourceReferenceMapper or the new mapper), and like in
BasicResourceReferenceMapper, the new mapper would also create and cache a
PackageResourceReference with enough state so no url decoding will be
needed there. Given the impact in ResourceMapper, the proposal is for
Wicket 11.
Pedro Santos
On Sun, Nov 10, 2024 at 9:48 PM Pedro Santos <pedros...@gmail.com> wrote:
> Hi, currently the code to get a specific PackageResource needs to decide
> if its style will come from the PackageResourceReference, from the session,
> or from the URL. Taking a look at the
> PackageResourceReference#getCurrentStyle [1]:
>
> private String getCurrentStyle(UrlAttributes attributes) {
> String currentStyle = getCurrentStyle();
> return currentStyle != null
> ? currentStyle
> : attributes != null
> ? attributes.getStyle()
> : null;
> }
>
> It seems that the style in the URL is the last one to get used, so I
> wonder if the expectation in the test case [2] is right (I think it is) and
> if it's ok to change the PackageResourceReference keeping the test
> expectation during the work to remove the duplicated resource URL
> attributes decoding logic in the ticket WICKET-7129 [3].
>
> 1 -
> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/request/resource/PackageResourceReference.java#L221
> 2 -
> https://github.com/apache/wicket/blob/a5e43aeed041e0366d01a1a35aa48ed1bf62a581/wicket-core-tests/src/test/java/org/apache/wicket/core/request/resource/PackageResourceReferenceTest.java#L442
> 3- https://issues.apache.org/jira/browse/WICKET-7129
>
> Pedro Santos
>
