Does Xojo have the tools and functions to save a web page as a text file once loaded into the WebHTMLviewer?
Let me look through my recent posts… I posted something similar in the past…
basically you get the page source from the DOM of the WebHTMLViewer, trigger a xojo event to load it into a variable to make it accessible, then save it.
Keep in mind that you can’t save it directly to the users hard drive. You’ll probably need to send it to the server and then have the user download through a webfile again.
Yes, my request is looking a little doubtful as I am thinking of every action as being local, not web deployed.
It is probably much easier to fetch it again with HTTPSocket.
Oh… the intent is to save the file locally, not server-side. If you want to save locally, make the content a WebFile server side, and display a “Save” button or popup asking if the user wants to save the file, then issue the download to the browser.
Server side, use getElementById(’ + webhtmlviewer.controlid + ').*
-contentWindow.body.innerHTML
-document.innerHTML
or any variety of Dom elements which you wish to use, and store it in a WebFile. This is the same technique (with a .htaccess and robot.txt file) that I use to create static pages so that search engines can still crawl Xojo web apps (not crawlable on their own).
If you do a forum search for “getelementbyid” there are dozens upon dozens of examples and variations of the Javascript.
Alternatively, as Mitchel said, use a httpsocket to obtain the page as a string, and store it in the webfile, as well as issue it visually to the user by loading the string into the webhtmlviewer using the LoadPage(string) function. This case does not allow the user to interact with the Iframe if any user input or forms are involved though, without first intercepting the form posts and propagating the httpsocket with the form data, etc. If the content in the iframe is a secured page (https), it gets a bit tricker.
[quote=202331:@Matthew Combatti]Oh… the intent is to save the file locally, not server-side. If you want to save locally, make the content a WebFile server side, and display a “Save” button or popup asking if the user wants to save the file, then issue the download to the browser.
Server side, use getElementById(’ + webhtmlviewer.controlid + ').*
-contentWindow.body.innerHTML
-document.innerHTML
or any variety of Dom elements which you wish to use, and store it in a WebFile. This is the same technique (with a .htaccess and robot.txt file) that I use to create static pages so that search engines can still crawl Xojo web apps (not crawlable on their own).
If you do a forum search for “getelementbyid” there are dozens upon dozens of examples and variations of the Javascript.
Alternatively, as Mitchel said, use a httpsocket to obtain the page as a string, and store it in the webfile, as well as issue it visually to the user by loading the string into the webhtmlviewer using the LoadPage(string) function. This case does not allow the user to interact with the Iframe if any user input or forms are involved though, without first intercepting the form posts and propagating the httpsocket with the form data, etc. If the content in the iframe is a secured page (https), it gets a bit tricker.[/quote]
Actually, I suspect security protocols will limit access in JavaScript to the content of an iFrame DOM if it is not on the same domain as your web app. HTTPSocket or SecureHTTPSocket then becomes the only game in town.
I have found using HTTPSocket is subject to throttling (I guess for load balancing purposes) on larger files but on small files are very fast. Is there a way of passing through HTTP data from a back-end server to a client via a Xojo stand alone app in the middle without the payload being throttled?
Does this have to do with the thread’s topic ?
If it’s a large file and HTTPSocket is the answer where responses must belong to the same domain as the Web app (which could be standalone) then I guess it is… The question has been on my mind for a while though.
The fastest way will always be to make the large file directly available through a URL. The question was how to get the text from what is displayed in a WebHTMLViewer which is an iFrame, and normally JavaScript does not have access to the DOM of an iFrame if it is not on the same domain (as far as I know), so HTTPSocket seems like the only way.
But if you simply want to serve files to the client, no need to go through the app, unless you want to mask the URL of the file, or if you want to hide it away from HTTP access.
To serve software customers buy on my sites, I use an app derived from the Downloading example in Xojo, which serves files that are placed away from public_HTML. It creates a WebFile which then is served by the app as you describe. Some amount of buffering and the very serving process means potential slow down that a direct download will not have. I would not call it throttle, though.
For really big files, you can still place them on public_HTML, and use .htaccess to set a login and password to the directory for your client. All you has to do is to add or remove keys in .htpasswd through FolderItem/TextInputStream/TextOutputStream.
That’s something like what I’m doing Michel only with content not binaries. It may be the throttle is in the StandAlone Web App not the HTTPSocket itself. I was thinking I could bypass the Session object and get via a HandleUrl or SpecialHandle URL routine for the bigger files to see if it would make a difference but I haven’t been able to get the classic HTTPSocket working outside of a Web page. I am yet to give the New Framework socket a go via code instantiation in the handleURL event which might do the trick for large files…
Whatever the method you use, going through an app is inherently slower than a direct download. If you want to control access, consider the protected directory route. It will be way easier and more reliable.
should not has to be as simple as ?
dim iText as string
iText=htmlviewer.text
I cannot find a HTTPSocket in the webapp library
HTTPSocket is the same in Web and Desktop. Drag a generic object to your web page and make it’s super HTTPSocket.
http://documentation.xojo.com/index.php/HTTPSocket
As for saving the content of a WebHTMLViewer, if the content is not on the same domain as your app, you can forget it. For security reasons, the browser won’t give you access to the WebHTMLViewer, which technically is an iFrame. There is no workaround.