It wouldn't be better to add a method that can provide information concerning what must be done instead of adding more class/interface verification? I'm sorry if I'm being a little annoying with this, but every time I look inside the code I see instanceof everywhere and the last time that I check, this is not the most efficient thing. It would probably be better if you try to start thinking on a different approach before the framework starts to become heavy.
Cheers -----Original Message----- From: Martin Grigorov [mailto:[email protected]] Sent: 25 February 2013 20:40 To: [email protected] Subject: Re: Review request for UrlResourceReference On Mon, Feb 25, 2013 at 8:49 PM, Andrea Del Bene <[email protected]>wrote: > 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. > This looks better than my approach! Thanks! > I've attached my patch at WICKET-4907 > >> Hi, >> >> At >> https://issues.apache.org/**jira/secure/attachment/** >> 12570471/WICKET-4907.patch<https://issues.apache.org/jira/secure/atta >> chment/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- >> 4942> , >> https://issues.apache.org/**jira/browse/WICKET-4907<https://issues.ap >> ache.org/jira/browse/WICKET-4907>and >> >> https://issues.apache.org/**jira/browse/WICKET-4903<https://issues.ap >> ache.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 ParentFolderPlaceholderProvide**r 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/>
