Martin,
If what you want to avoid if the "if". Maybe UrlRenderer can
be split-ed into two sub-renderers. E.g. Have interface
IUrlRenderer {
boolean canRenderUrl(); // decides if it can renser URL.
String renderUrl(URL url);
}
and UrlRenderer contains a list of two IUrlRenderers... DefaultUrlRenderer
(previous behavior), and a new CalculatedUrlRenderer (before
DefaultUrlRenderer). This way it might be easier to plug new "special
cases" in the future. But that might be over-killing?
On Fri, Feb 22, 2013 at 3:08 PM, Martin Grigorov <[email protected]>wrote:
> Hi,
>
> At
> https://issues.apache.org/jira/secure/attachment/12570471/WICKET-4907.patchyou
> 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 ?
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com <http://jweekend.com/>
>
--
Regards - Ernesto Reinaldo Barreiro
Antilia Soft
http://antiliasoft.com/ <http://antiliasoft.com/antilia>
