Looking for method to call browser repetitively per HTML form
Terence
for the usual familiar web enquiries. Related programs already do data
capture from physical documents.
I am missing one tool to integrate both methods into a single data
processing system.
Can anybody suggest a way to call a browser (to do the HTML work) to
repetitively (by creating results files with sequentially increased ID
number as part of the namea) and capture data from the use of an
existing HTML coded form (matching a series of real paper documents)
and so data enter and store the data locally?
Fortran is well capable of calling other programs; i just don't see
how to attack ths case and pass a file name to the (any selected)
browser.
Terence
Part of the solution may include a system call within the Fortran
program to accomplish the following (using Opera as an example
browser):-
C:\FORTRAN>c:\progra~1\opera\opera file:\\localhost\c:\data
\myform.html
This works as a single call; the resulting file can be e-mailed (which
helps solve the collection part of the file amalgamations), but is
obviously not efficient nor does it address the problem of the output
file name.
Now, if I could only pass a parameter to define the output file name.
A clumsy solution is to dynamically modify a template HTML code to
include an output file name and so execute a different source code for
each result file name needed.
frank
You could write this as something for your own amusement, usable only on
your machine, but I think the amusement would be heightened if it worked
on all windows machines. I find it now pleasant that I have no nothing
to do with ms anymore. So it would be even more amusing for me if it
would work on my ubuntu OS as well. I think this minimal portability is
achievable.
Instead of calling a browser you could call a syntax that has the
faintest idea what a "browser" is. Maybe you could call the browser off
a system command. Invoke a batch file.
Idunno. Those are my first guesses. Cheers,
--
frank
"Rape: is it too much to ask for corporations who bid on federal
contracts to refrain from?"
user1
> Now, if I could only pass a parameter to define the output file name.
Have you tried using hidden input fields in whatever form you are
sending to the browser ? If the web form is being dynamically written by
a Fortran cgi program, it shouldn't be hard to embed hidden inputs that
would pass information onto the next submission.
snip from http://htmlhelp.com/reference/html40/forms/input.html
" The hidden input type allows authors to include form data without
having it rendered to the user. This is particularly useful in form
applications that span several HTML documents; user input can be carried
from form to form by hidden INPUTs. Some generalized CGI scripts use
hidden INPUTs to define variables for the script, as in the following
example, which defines a recipient and subject for the e-mailed contents
of a form "
e p chandler
"Terence" <tbwr...@cantv.net> wrote in message
news:74716fdc-0063-4ec0...@a39g2000pre.googlegroups.com...
try
'start fubar123.htm'
with call system() or i=system().
As for sending data back, without using a web server and CGI (common gateway
interface)? Yes you can.
Change the file extension from .htm to .hta. This waives many security
checks.
Write some javascript that invokes methods of an Active-X object (ye olde
Scripting.FileSystemObject):
---- start ----
<script>
var s=prompt('prompt text','default answer')
var fso = new ActiveXObject("Scripting.FileSystemObject")
var FileObj = fso.OpenTextFile("C:\\temp\\log.txt",2,true,0) //
write,create,ascii
FileObj.write(s)
FileObj.close()
</script>
---- end ----
see
http://www.activewidgets.com/javascript.forum.6714.20/writing-to-a-text-file.html
for more examples, including using a form. Note that some of the code will
work and some of it won't.
HTH (I've done this stuff in VBA before but not from a web page).
--- elliot
Terence
> Terence wrote:
> > Now, if I could only pass a parameter to define the output file name.
>
> Have you tried using hidden input fields in whatever form you are
> sending to the browser ? If the web form is being dynamically written by
> a Fortran cgi program, it shouldn't be hard to embed hidden inputs that
> would pass information onto the next submission.
>
>
> " The hidden input type allows authors to include form data without
> having it rendered to the user. This is particularly useful in form
> applications that span several HTML documents; user input can be carried
> from form to form by hidden INPUTs. Some generalized CGI scripts use
> hidden INPUTs to define variables for the script, as in the following
> example, which defines a recipient and subject for the e-mailed contents
> of a form "
I studied this reference, but I am not using a web-site to host the
document, only internal local networked computers, nor have a cgi
interpreter. The important point is not "how to write to file" but
"how to store the compaoung response code generated by filling the
form as a local file, without trying to post it somewhere". In other
words a replacement for the "On Submit" btton action of POSTING to one
of "WRITE this.form" to [filename].
i STUDIED THIS, BUT i AM NOT USING A WEB-SITE, NOR HAVE A CGI
INTERPRETER
Terence
> "Terence" <tbwri...@cantv.net> wrote in message
> for more examples, including using a form. Note that some of the code will
> work and some of it won't.
>
> HTH (I've done this stuff in VBA before but not from a web page).
>
> --- elliot
This reference is interesting ( a lengthy Forum history of postings
which vary from "you can't" to "yes you can" and "yes you can only do
it on IE or under these modified security option settings ...".
But crucial seems to be the naming of the document to HTA and not HTM
(or HTML).
If anyone has more in this vein, better still a tested script, please
post.
Is there an alternative to the POST action for "ON SUBMIT"?
Terence
I wrote this twice, in lower case, and still find it got posted the
"aborted" first time and not written the "trusted" second time!
AGAIN:-
"I studied this (and didn't see "compounded" spelled wrongly), and
don't wish to use a web-site host for simple in-house data collection,
nor have a cgi interpreter".
user1
I see. So it seems that what you want to do is wrap a GUI around a set
of Fortran programs by using html forms, but you do not wish to have
these forms processed on a web server through the cgi interface.
I have never tried such a thing, but I imagine embedding JavaScript as
per Elliot would be your best hope.
user1
>
> Is there an alternative to the POST action for "ON SUBMIT"?
Tried google with "javascript save form data". The first hit seems to be
along the lines suggested by Elliot.
e p chandler
On the page I referenced above is a script by soumya sen.
This script takes data from a form, retrieves variables by name and writes
them on separate lines to the selected file.
Clicking the submit button calls a function which does the actual work.
onclick="Writedata()" is actually a bit of javascript embedded INSIDE an
HTML tag. Don't ask me why, but it works!
----- start text -----
<html><head>
<script language="javascript">
function Writedata()
{
var fso = new ActiveXObject("Scripting.FileSystemObject");
var write_id;
write_id = document.getElementById('write_id').value ;
alert('The data has been written to \n' + write_id);
var s = fso.CreateTextFile(write_id, true);
s.WriteLine(document.getElementById('name_id').value);
s.WriteLine(document.getElementById('id_id').value);
s.Close();
}
</script>
</head>
<body>
name : <input type="text" name="name" value="" id="name_id"><br/>
Address : <input type="text" name="id" value="" id="id_id"><br/>
Write file to : <input type="text" name="write" value="" id="write_id"><br/>
<input type="button" onclick="Writedata()" value="submit">
</body>
</html>
----- end text -----
When saved as an .hta file, it works for me:
IE 8 under Vista SP2 & XP SP3
IE 6.0 under Win98SE
IE 5.5 under Win95
--- elliot
user1
[snip]
>
> I am missing one tool to integrate both methods into a single data
> processing system.
>
The more I think about this, the more I suspect that the one tool you
are missing is in fact a web server. It could be a small server running
only on localhost.
David Duffy
> [snip]
Yes, and it could be the calling fortran program, if this would not be too
inefficient (and tedious, if you have to write code for multiple platforms).
David Duffy.
Terence
I visited a Dell shop today and checked out how DOS runs under Windows
V7.
It won't give full screen as such, but you can set up a very wide and
very deep DOS window (about 170 ch by 60 rows or more) and vary the
text character size to get an approximation.
Of course, this is the first version of V7; maybe more facilities will
be offered later.
This is relevant. You see, I'm not wrapping a GUI around Fortran
programs to fill in HTML forms; to the contrary, I am trying to wrap
my Fortran programs, which already contaain a lower level complete GUI
that handles screens and forms, to call a still lower HML/Java service
to store the data locally (when actually the current program logic is
to send the HTML captured data to any other site where still more
Fortran programs interpret the individually transmitted coded result
files.
The idea is for any user to have full control over the HTML form
generation, use, capture, interpretation and processing (which may be
on separate multipl computers, or with some central local networked
storage).
I like the ideas and example given. I am sure there is a well-tested
transportable sloution that doesn't REQUIRE IE, but works on other
browsers too.
user1
You could also bind up a port with netcat and capture the http request
when the form is submitted.
Here's a sample form -
<html>
<head>
<title>Test Page</title>
</head>
<body>
<form action="http://localhost:8080/" method="post">
What is your name: <input type="text" name="name" />
What is you favorite color: <input type="text" name="color" />
<input type="submit" />
</form>
</body>
</html>
Here is the netcat example and captured result. I suppose netcat could
be launched by a system call from Fortran. The output could be
redirected to a file. ( nc -l -p 8080 > somefile.out )
C:\temp>nc -l -p 8080
POST / HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.13)
Gecko/2
009073022 Firefox/3.0.13 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
name=John+Doe&color=Green
C:\temp>
Terence
This script below (E.P. Chandler et al), STORED AS FILE TYPE ".HTA"
worked and stored a file.
1) The firewall warned about possible malicious script, which after
bieng told to accept, then later accepted all other scripts from the
same directory.
2) the "Alert" keyword did nothing I could detect.
3) the use of \\ or // in the file name works either way.
4) clicking on the hta file avoided calling a browser as so is an
obvious mechanism possibility for use as a SYSTEM called file; the
actual form sequence (ID) number could be input by the operator as
just one of the questions to be answered.
**
4) The resulting file was just lines of ascii fields, NOT, as I had
hope, to be in the "normal" Modzilla format for form data as shown by
a real example as follows:-
id=TEST4++&01%2F03-00=+1&01%2F04-01=+1&01%2F04-02=+2&01%2F04-03=
+3&01%2F04-04=+
4&01%2F04-05=+5&01%2F05-00=+1&01%2F06-01=+1&01%2F06-02=+2&01%2F06-03=
+3&01%2F06-
05=+5&01%2F07-01=+1&01%2F07-03=+3&01%2F08-00=+1&01%2F09-01=
+1&01%2F09-02=+2&01%2
F10-00=+2&01%2F11-RR=+1.+Done+as+agreed+in+ascii (...more)
So my last (?) puzzle is how to get the usual form date format above,
for which standard programs exist for parsing and extracting ascii,
value, texts and binary data resposes.
-----SOURCE--------
<html>
<head>
<script language="javascript">
function Writedata()
{
var fso = new ActiveXObject("Scripting.FileSystemObject");
var write_id;
write_id = document.getElementById('write_id').value ;
alert('The data has been written to \n' + write_id);
var s = fso.CreateTextFile(write_id, true);
s.WriteLine(document.getElementById('name_id').value);
s.WriteLine(document.getElementById('id_id').value);
s.Close();
}
</script>
</head>
<body>
name : <input type="text" name="name" value="" id="name_id"><br/>
Address : <input type="text" name="id" value="" id="id_id"><br/>
Write file to : <input type="text" name="write" value="C://data//
terry2.att" id="write_id"><br/>
<input type="button" onclick="Writedata(this.form)" value="STORE">
</body>
</html>
e p chandler
1. Feel free to remove the "cruft" form the code. I posted exactly as it was
listed.
2. try escape(s) OR encodeURI(s) where s is a string. It does hex encode
special characters, but I see it does not give the exact encoding you used.
[escape is deprecated in favor of encodeURI].
3. Perhaps there is a different function that does exactly what you want.
--- Elliot
David Duffy
> You could also bind up a port with netcat and capture the http request
> when the form is submitted.
Not that I'm actually recommending it ;)
http://www.qimr.edu.au/davidD/Sockets/httpserver.f95
--
| David Duffy (MBBS PhD) ,-_|\
| email: dav...@qimr.edu.au ph: INT+61+7+3362-0217 fax: -0101 / *
| Epidemiology Unit, Queensland Institute of Medical Research \_,-._/
| 300 Herston Rd, Brisbane, Queensland 4029, Australia GPG 4D0B994A v
e p chandler
"David Duffy" <dav...@orpheus.qimr.edu.au> wrote in message
news:hdaran$jip$1...@air.soe.uq.edu.au...
Somehow I think that the original problem has gotten out of hand. At least
no none has asked to include XML in the process. (grin).
user1
>
>
> Somehow I think that the original problem has gotten out of hand. At
> least no none has asked to include XML in the process. (grin).
>
Not really. Html forms are best processed server side, and it is rather
difficult to put anything into an html page that will create or modify a
disk file on the client side.
Dave Allured
If I understand correctly, you are talking about capturing data from the
web via HTTP form calls. I have had good luck with lynx for this on two
platforms, called in command line mode from a shell script. It supports
both POST and GET form methods, as well as programmable output file
names.
Another command line tool, curl, may also have these capabilities; you
might look into that. Lynx seems rather old fashioned to me these days,
curl might be better now.
It should be fairly simple to do the same thing controlled from Fortran,
rather than shell script, via system calls. HTH.
--Dave
Terence
No, "actually". Forms are best processed on the machine wehre the data
is entered, or else on a machine on the lsame in-house network.
All the forms proecessing that I do has been going on since forms by e-
mailing was possible.
It's actually very easy, especially when the form is generated by the
same organisation that is using it to capture data.
So, instead of sending data via e-mail back to the same computer via
the internet, it makes more sense (in case of outages and efficiency)
to write to disk WHAT HAS TO BE ALREADY IN MEMORY held by the bowser.
I posted an the java forum with no luck yet and HTML searches seems
fina that this question is not presented.
user1
>
> No, "actually". Forms are best processed on the machine wehre the data
> is entered, or else on a machine on the lsame in-house network.
Sigh. You seem to be missing the point. The server is just a program
that could indeed be running on the same machine where the data is being
entered.
Good luck.
Steven Correll
> So, instead of sending data via e-mail back to the same computer via
> the internet, it makes more sense (in case of outages and efficiency)
> to write to disk WHAT HAS TO BE ALREADY IN MEMORY held by the bowser.
> I posted an the java forum with no luck yet and HTML searches seems
> fina that this question is not presented.
If you can write files directly from the browser without running a web
server, that's fine, but I think it might help to point out why you're
encountering obstacles. From the start, web browsers were, for
security reasons, designed not to be able to access arbitrary files
unless the user indicated explicitly that s/he wanted to do so.
Imagine what would happen if, when you click on an unfamiliar link
supplied by Google, the resulting web page could, without asking you,
maliciously overwrite any file to which you have access.
(Notice that the HTML element to upload a file always pops up a dialog
box whose appearance can't be restyled, and that file downloads pop up
a similarly fixed dialog. The goal in both cases is to avoid accessing
the file system without an acknowledgement by the user that s/he
really wants to do so.)
Browser-based Java runs in a "sandbox" that prevents file access.
Microsoft ActiveX, in contrast, opens holes in the security barrier
which may permit access to files behind the user's back, but that
remains controversial. Of course, with plug-ins, all bets are off,
which is why they're an endless source of security breaches.
If you were to entertain the idea of running a web server, on the same
machine as the browser, to receive the form data and store it into a
file, you wouldn't need a complicated one like IIS or Apache. Sun has
written a simple server in 451 lines of Java code (http://java.sun.com/
developer/technicalArticles/Networking/Webserver/) and it could well
be coded in Fortran instead, although with Fortran the programmer must
handle the system-dependent details of networking sockets.
user1
>
> If you were to entertain the idea of running a web server, on the same
> machine as the browser, to receive the form data and store it into a
> file, you wouldn't need a complicated one like IIS or Apache. Sun has
> written a simple server in 451 lines of Java code (http://java.sun.com/
> developer/technicalArticles/Networking/Webserver/) and it could well
> be coded in Fortran instead, although with Fortran the programmer must
> handle the system-dependent details of networking sockets.
Yes, and don't go thinking that web servers are monster resource hogs.
Personally, I use TinyWeb to post html forms to localhost, and process
the form data via a mix of C and Fortran programs. Looking at my task
manager, the TinyWeb server is using 1604K memory while idle. In
contrast, an idle Firefox browser is using 24,560K memory.