I think that the three issue could be solved also introducing an
interface for those resource references that want to directly render
their URL. Something like:
public interface IResourceRefUrlGenerator
{
public Url getUrl();
}
Then, inside ReqyestCycle's method renderUrl we can check if resource
reference implements this interface and if so, we can delegate Url
generation to it.
I've attached my patch at WICKET-4907
Hi,
At
https://issues.apache.org/jira/secure/attachment/12570471/WICKET-4907.patch you
may see a patch that fixes https://issues.apache.org/jira/browse/WICKET-4942
, https://issues.apache.org/jira/browse/WICKET-4907 and
https://issues.apache.org/jira/browse/WICKET-4903
The problem is that I don't feel very proud of the solution.
UrlResourceReference's (URR) purpose is to make it possible to use a
ResourceReference when all you have is a url (absolute or relative)
There solved problems are:
1) UrlRenderer#renderUrl() is used after a IRequestMapper resolves a Url.
This breaks the provided url in URR by relativizing it
2) Until now URR was handled by BasicResourceReferenceMapper which is
wrapped by ParentFolderPlaceholderProvider and leads to prefixes like "::"
in the generated url
And what I don't feel happy with is CalculatedUrl. This is a specialization
of Url which UrlRenderer does not try to render. Just returns it as it is.
Do you have better ideas how to tell UrlRenderer to not touch the Url when
it comes from UrlResourceReference ?
