Hi Peter,
On 11 Jan 2015, at 12:47, PBKResearch <peter@pbkresearch.co.uk> wrote:
Sven
Apologies for the delay in replying.
Basically, the relative argument can be anything that occurs in a LINK tag in an HTML document. This can be anything from a file name to a complete address with only the 'http:' missing.
I have found a couple of examples in a document from the Wikipedia 'Wiktionary', where I show in the attached workspace file the absolute address, the two relative addresses and the effect of combining using Url class>>#combine:withRelative and ZnUrl>>#inContextOf:. In each case the output of the Url class>>#combine:withRelative is the expected result; in the first case ZnUrl>>#inContextOf: gives the expected result, in the second it does not.
The relative address in the second case seems a bit odd (why not include the 'http:' and make it absolute?), but it actually occurs (quite often in Wiktionary files at least) and the code needs to be able to deal with it.
The problem is that ZnUrl>>#inContextOf: works with 2 parsed URL objects. However, relative URLs are not proper URLs and cannot be parsed nor represented as such. For example, 'foo/bar/readme.txt' and '/foo/bar/readme.txt' are the same. Relative URLs only exist while parsing and must then be resolved. Section 5 of RFC 3968 explains in details how to do that. This will have to be added to ZnUrl or to a helper class, but that will take some time. Luckily there are test cases in the document. Thanks for the feedback. Sven
Hope this helps.
Peter Kenny
-----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe Sent: 10 January 2015 22:56 To: Any question about pharo is welcome Subject: Re: [Pharo-users] Problem due to deprecation of class Url in Pharo 3 and Moose 5.0
Peter,
On 10 Jan 2015, at 23:30, PBKResearch <peter@pbkresearch.co.uk> wrote:
Yes change the code of the Parser not to use old code. As I pointed out, the Parser is a large and complex package, and I am not the author, so this is easier said than done. It seems a bit odd to dismiss code which worked OK in Moose 4.9, but not in Moose 5.0, as 'old code.' It is code which has no functional equivalent in the new code, as Sven has confirmed.
Could you explain what arguments were given to the combine and what the expected output was/should be ? How does it use path merging ?
Thx,
Sven <CombineRelWithAbs.ws>