Hi Peter, > On 11 Jan 2015, at 12:47, PBKResearch <pe...@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-boun...@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 <pe...@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>
