Giving a second thought, it's possible to maintain the current api and yet
move the url decoding to ResourceMapper. There it would create/cache a
PackageResourceReference for each style/variation/locale found in the url,
and return it in the ResourceReferenceRequestHandler. In this alternative,
we would need to make PackageResourceReference a final class, since the
newly created one will not guarantee to be of the same subtype as the one
in the ResourceMapper.
Pedro Santos
On Fri, Nov 15, 2024 at 8:38 PM Pedro Santos <pedros...@gmail.com> wrote:
> 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
>>
>
