Le 10/1/15 11:41, PBKResearch a écrit :
Hello
I have run into a problem in moving some existing work from earlier
versions of Pharo/Moose. I have found a work around, but I wonder if
there is a tidier way of handling it.
I make frequent use of Todd Blanchard’s HTML parser and validator,
HTMCSS
(http://smalltalkhub.com/#!/~ToddBlanchard/HTMCSSValidatingParser),
which was originally written for Squeak but has performed without
trouble on earlier versions of Pharo. When I try to use it on Moose
5.0, I get frequent warning messages about Url being deprecated. I
have made the problem go away by commenting out the deprecation
warning in Url class>>new, but I wonder what should be done on a more
permanent basis.
Yes change the code of the Parser not to use old code.
The problem arises because HTMCSS does not just parse the original
HTML file; it also loads and parses any referenced CSS files. (This is
a function I could do without, but I don’t fancy trying surgery on a
complex package where I only partly understand the workings!) It
constructs the full address of the CSS file by combining the root
address of the HTML with the relative address of the CSS, using Url
class>>combine:withRelative:, and in the course of this it invokes Url
class>>new; hence the deprecation message.
use ZnURL
The deprecation message says Url has been replaced by ZnUrl, but this
is clearly not a simple replacement of one message by an equivalent;
there is no ZnUrl class>>combine:withRelative:, for instance.
Sven will certainly comment but I guess that there is certainly the same
behavior.
The tidiest solution would no doubt be to find an equivalent method in
Zinc, which I am sure exists, and then modify the HTMCSS code to use
it. I have tried to find an equivalent, but Zinc is a large and
complex system and I rapidly got lost.
It should be in ZnURL
is it not addPathSegment:?
from class comment
ZnUrl new
scheme: #https;
host: 'encrypted.google.com';
addPathSegment: 'search';
queryAt: 'q' put: 'Smalltalk';
yourself.
host: looks like the root
addPathSegment: looks like https://encrypted.google.com/search
I wonder more broadly about the strategy of deprecating functions
which are required by legacy packages, as in this case. Should there
at least be a way of overriding deprecations? (I suppose that is what
I have done by commenting it out, but it seems crude.)
Thanks in advance for any help or suggestions.
Peter Kenny
