Thank you guys for your contributions, but I think that this kind of discussions should be done on pharo-users mailing-list, not here.
pharo-dev should be use only if you contribute to core-pharo. Thank you Envoyé de mon iPhone > Le 28 mai 2017 à 10:22, askoh <[email protected]> a écrit : > > Wonderful contribution. Having full control of an internet browser will give > Smalltalk more freedom to innovate. > > Now, can we make Pharo be a web server on demand? Then we can give anyone a > URL and they can see the app or info we want to present. Pharo can > communicate with anyone using a browser either automatically or under > developer control. > > All the best, > Aik-Siong Koh > >> On May 27, 2017, at 3:23 PM, Alistair Grant [via Smalltalk] <[hidden email]> >> wrote: >> >> Hi Torsten and All, >> >> Quick Introduction for those not familiar with Pharo-Chrome: >> >> Pharo-Chrome enables Pharo to control and query Chrome / Chromium, in >> particular to retrieve the DOM of a page. This is useful as many modern >> pages are just a template which then loads some javascript to >> asynchronously build the DOM, meaning that the ZnEasy / Soap combination >> doesn't get the bulk of the information on a page. >> >> >> >> Pharo-Chrome is now mostly working, i.e. it is possible to open >> a connection to Chrome, navigate to a requested URL, wait for it to >> load, retrieve the DOM and then navigate the DOM using a subset of the >> Soap API, e.g. #findAllStrings:, #findAllTags:, attributeAt:, etc.. >> >> GoogleChrome class>>exampleNavigation has been updated to retrieve the >> DOM from http://pharo.org. >> >> GoogleChrome class>>get: is analogous to ZnEasy class>>get:, although it >> returns a ChromeNode, not an html string. >> >> I wasn't able to get rid of the delay while waiting for the page to >> finish loading. This actually makes sense, since, as mentioned above, >> many modern pages build the DOM asynchronously, so there's no clear >> indication of when it is complete. The default delay is currently 2000 >> milliseconds, which is about twice the maximum I saw needed (983ms), but >> this can be changed (ChromeTabPage>>pageLoadDelay:). >> >> I had three use cases for this library: one which works with >> ZnEasy+Soap, one that used to work with ZnEasy+Soap, but doesn't due to >> a page redesign, and one which I hadn't got working before. All three >> are working now. >> >> Unlike Soap, I've currently modelled the nodes as a single class, and >> have only implemented a subset of Soap's methods, but is enough for what >> I need. >> >> I've introduced a dependency on the Beacon logging framework. I find it >> useful, but can remove it if you don't want the additional dependency. >> (I'm planning to add some GoogleChrome specific logging classes and use >> those to better understand what pageLoadDelay should be). >> >> I was focussed on trying to understand the events that Chrome generates, >> so documentation is still lacking (read "missing" :-)). >> >> I'll generate a pull request after some more testing, tweaking and >> documenting, but if you would like to take a look, the code is available >> at: >> >> https://github.com/akgrant43/Pharo-Chrome/tree/development >> >> I haven't yet updated BaselineOfChrome with the Beacon dependency. I >> did merge in your two commits from May 23. >> >> If you, or anyone else, finds this useful, I welcome any feedback. >> >> P.S. I've just realised that I need to tidy up #sendMessage:, >> #sendMessageDictionary and #sendMessageDictionary:wait:. I'll do that >> as part of the genral tidy up. >> >> Cheers, >> Alistair >> >> >> # vim: tw=72 >> On Sun, May 21, 2017 at 09:37:56PM +0000, Alistair Grant wrote: >> >> > Hi Torsten, >> > >> > On Fri, May 19, 2017 at 09:20:48PM +0000, Alistair Grant wrote: >> > > >> > > On Fri, May 19, 2017 at 10:50:41PM +0200, Torsten Bergmann wrote: >> > > > Hi Alistair, >> > > > >> > > > cant look right now but two things: >> > > > >> > > > - there are also events in the protocol - if we could hook Pharo >> > > > into them >> > > > this would solve the problem without abusing delay (because then >> > > > you will >> > > > get informed when the page loading is finished) >> > > >> > > That would be great. It will be a while before I get a chance to look >> > > at this (I want to finish some proposed changes to the FileSystem >> > > packages first), but I'll try and include it then. >> > >> > I've got basic event listening working. It requires that all messages >> > are read asynchronously, so I'll need to change the interface to handle >> > that. >> > >> > Knowing when a page has finished loading isn't quite as simple as >> > looking for an event - a page can consist of multiple frames, and >> > notifications are delivered for each frame. The page I'm interested in >> > has around 25 frames. >> > >> > If anyone has a good design pattern for writing an asynchronous >> > WebSocket client please let me know, I don't have anything concrete in >> > mind. >> > >> > Thanks, >> > Alistair >> > >> >> >> If you reply to this email, your message will be added to the discussion >> below: >> http://forum.world.st/Chrome-DevTools-Protocol-and-Pharo-tp4947589p4948458.html >> To unsubscribe from Chrome DevTools Protocol and Pharo, click here. >> NAML > > View this message in context: Re: Chrome DevTools Protocol and Pharo > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
