[
https://issues.apache.org/jira/browse/WICKET-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572871#comment-17572871
]
Peter Lamby commented on WICKET-6993:
-------------------------------------
Hi [~mgrigorov],
the PR got rather big :D.
I splitted the PR in multiple smaller commits. Each with a small description to
aid understandability: [https://github.com/apache/wicket/pull/529/commits]
The first Commit in this series introduces a Unit Test that exposes the
problem:
[https://github.com/apache/wicket/pull/529/commits/29bd0899b8350d3af96b151e2727ad8e428ffcdb]
Feel free to just pick this commit from the patch series. Let me know if a
quickstart is still required with the unit test present.
I'll try to clear up my description.
When I create an org.apache.wicket.request.resource.ResourceReference like this:
{code:java}
new ResourceReference(HelpResourceReference.class, "help", locale, null,
"single-e-inside") {code}
Wicket internally encodes and decodes the variation. What wicket (and the
application) sees at the end is the variation "single-e~inside". In my case
this prevents the resource to be found on the disc.
What I expected is that wicket does not modify the variation. (Which it usually
doesen't, except in the cases detailed in the UnitTest).
Wickets encoding scheme has a problem with multiple "-" or with single letters
in the variaten separated by "-".
I tried to fix this encoding scheme at first. But I saw no way to do that
reliably. I always found a variation that broke my fixes.
After some playing around with the code I ended up with what you see now. A
rather large rewrite of the resource encoding scheme.
> Why the page became stateful ? It has "?2" now
The "2" is not the page version. It's not stateful. But I can see how the name
is confusing. What you see is the new string encoding scheme. As detailed in
the javadoc comments in
[https://github.com/apache/wicket/pull/529/commits/0246fa059f483fdf62f7dabbd86a16a77220132e]
the parts of the resource are now encoded as
"<string-length-encoded-in-base-ten-ASCII>~<string-data>" which results in
"2~en" to encode "en". This makes parsing vastly easier. We just have to parse
the length up to a "~" and then just read the next n chars. This fixes the
problems caused by the earlier decoding algorithm which used regex.
> Why do we need the "null"s ?
Wicket passes the entire resource definition as a single String
<localPart><stylePart><variationPart>. With a string like "2~en3~abc". It is
not clear what the original String was.
local = en
style = abc
variation = null
or
local = null
style = en
variation = abc
or
local = en
style = null
variation = abc
The encoding is just ambigous. Adding an explicit "null" now enables us to
correctly decode the string in (hopefully) all cases.
> Resource Variations containing a single character are not correctly decoded
> ---------------------------------------------------------------------------
>
> Key: WICKET-6993
> URL: https://issues.apache.org/jira/browse/WICKET-6993
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 8.14.0, 9.10.0
> Reporter: Peter Lamby
> Priority: Minor
>
> A resource variation containing a single character in the middle is encoded
> as follows:
> single-e-inside => single~e~inside
> When the variation is decoded again the following variation is produced
> single-e~inside => single-e~inside
> A similar issue exists with an attribute like double--separator
>
> The effect is that resources with a variation like that do not work correctly
> in wicket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
