On Sun, May 28, 2017 at 8:44 AM, Alistair Grant <akgrant0710@gmail.com> wrote:

(Moving to pharo-users as Serge suggested)

Sending the email also made me realise that it would be possible to
check for the presence of a particular node while waiting for Chrome to
load the page, which would avoid the long timeout.�� I'll look at adding
this later.

Cheers,
Alistair

On Sun, May 28, 2017 at 10:49:14AM +0700, serge.stinckwich@gmail.com
wrote:
> 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

>
>�� 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
>
>

>�� 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