WebViewer InnerHTML

[andries]

Hi

I am trying to get the innerHTML of my webviewer, as the data is set by JavaScript.

Is there any possibility to achieve this?

I was thinking of using the following technique:

Set the URL to : javascript:a=document.body.innerHTML; ... and then grab it with the GetLayoutObjectAttribute function.

but I have the feeling this is not going to work

[TheTominator]

Scraping the Web Viewer for information will only provide the source HTML (or other code) BEFORE the rendering/processing engine has interpreted it. Thus you will get access to raw HTML with all the tags, CSS formatting, and JavaScript commands.

You will not get formatted text (bold, italics), page layout, graphics, or the results of JavaScript commands. The last one is the real bummer for me. I really would like to be able to farm out certain complex processing tasks to the JavaScript engine and obtain the calculated results for me to assign back to a FileMaker field, but alas that is not possible yet without a plug-in.

[andries]

thanks for the reply... this is indeed a bummer...

I was inspired by the following post: http://filemakerforums.com/forum/showtopic.php?tid/210471/fromactivity/forum/

but there it fails loading my webviewer...

Edited March 12, 2010 by Guest

[andries]

Actually I found a way to grab some content created by JavaScript in FileMaker.

The trick is to create a dynamic HTML link "" with javascript. This HTML link refers to the same page, but adds POST parameters to it. For example "http://localhost/~user/test.html?Script=Test&ScriptParam=testscriptParam". If the users clicks on this link, it will reload the same page in the webviewer, but now you can get the new url with GetLayoutObjectAttribute ( "wv" ; "source" ), and parse the required script and scriptname. Or any content you want to grab from the webviewer.

If you create a "webviewer listeren" in an unstored calc, you can trigger a script using a free plugin as DoScript or something else.

Edited March 15, 2010 by Guest

[TheTominator]

Harvesting the parameters sounds like a neat way to do it. Very clever. I'll try that.

(This is using the GET action and not POST actually.)

[TheTominator]

Actually I found a way to grab some content created by JavaScript in FileMaker.

The trick is to create a dynamic HTML link "" with javascript. This HTML link refers to the same page, but adds POST parameters to it. For example "http://localhost/~user/test.html?Script=Test&ScriptParam=testscriptParam".

After working with this for a little while it seems that this method requires the page to be fetched from an actual web server. Specifying the URL for the Web Viewer with the method of "data:text/html,the page source code" doesn't do what is required to get calculated data back encoded in the URL.

[TheTominator]

Actually I found a way to grab some content created by JavaScript in FileMaker.

The trick is to create a dynamic HTML link "" with javascript. This HTML link refers to the same page, but adds POST parameters to it. For example "http://localhost/~user/test.html?Script=Test&ScriptParam=testscriptParam". If the users clicks on this link, it will reload the same page in the webviewer, but now you can get the new url with GetLayoutObjectAttribute ( "wv" ; "source" ), and parse the required script and scriptname. Or any content you want to grab from the webviewer.

If you create a "webviewer listeren" in an unstored calc, you can trigger a script using a free plugin as DoScript or something else.

You can have the JavaScript automatically "click the link" for you when the page loads on its own using the JavaScript line

window.location = "http://localhost/~user/test.html?Script=Test&ScriptParam=testscriptParam";

instead of creating a link anchor.

Then immediately after the web viewer finishes displaying the original JavaScript, the GetLayoutObjectAttribute ( "wv" ; "source" ) command will give you the URL with the parameters encoded.

If you add an OnRecordLoad trigger to the Layout and put in a Pause Script step before finding the value of GetLayoutObjectAttribute ( "wv" ; "source" ), the calculated JavaScript data should be available without user intervention.

[andries]

- the post thing... I actually know this... dumb dumb dumb

- about the javascript action: will try this

- indeed it only works if you host it on a server ( but as I work on a Mac, I always put my HTML pages on my server, and send the params with data from FM via the GET method to my HTML page)

- Using the unstored calc to trigger a script in FileMaker directly from the webviewer works, but only after you force the unstored calc to refresh...

Edited March 16, 2010 by Guest

[andries]

Actually I am also really wondering how difficult it can be for FileMaker to introduce this feature to get the innerHTML, they are already rendering the page, so they know what the innerHTML is.

Second question I have. On a Mac I always assumed that it was Safari that was used for the webviewer (and IE on Windows machines). Is this correct? However I found out that for example with the ckeditor WYSIWYG editor this editor works perfectly in Safari, but if you load the page in the webviewer not all functionalities are working. So now I think that it is not entirely true that it is simply Safari is used but may-be some light version of it. Is this correct?

[TheTominator]

Actually I am also really wondering how difficult it can be for FileMaker to introduce this feature to get the innerHTML, they are already rendering the page, so they know what the innerHTML is.

There's the rub. FileMaker is actually not doing the rendering. FileMaker is providing the space on the Window and farming it out to a third party library to do the rendering. FileMaker doesn't know what's in the web viewer directly. It only knows the bits of meta information that the third-party library is offering back (url & source) to go along with what it is drawing in the window. The window could be text, graphics, sound.

Second question I have. On a Mac I always assumed that it was Safari that was used for the webviewer (and IE on Windows machines). Is this correct?

I would expect that it is the WebKit framework (library) that is doing the rendering on the Mac. This is the same framework that Safari is built on, but the WebKit used by FileMaker may be out of sync with the WebKit built-into Safari.

It is possible that WebKit is also used on the Windows version of FileMaker since that code is cross-platform, but it is also possible that an IE library is being used for the rendering.

[andries]

thanks for the reply! It is a pitty that not much information about this subject is available...