TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Richard L. Conn" <[log in to unmask]>
Reply To:
Richard L. Conn
Sat, 11 Sep 1999 21:55:39 -0400
text/plain (106 lines)
The upcoming Ada and Software Engineering CDROM (which will be
distributed to all SIGAda 99 attendees) will have material on
this topic, so you can look there for more details.

Basically, we have this in a nutshell:

1. Any HTML form is of the following format (in HTML)
  <form method="POST" action="~URL to data server~">
  ... form-oriented tags and normal HTML tags ...
  <input type="submit" value="text on SUBMIT button">

where ~URL to data server~ is the URL of your Ada program, acting as a data
server.  I referenced the POST method here, but GET works just as well.
What POST does is send the data from the form into standard input of the
data server, where GET sends the data from the form into a (sometimes
very long) command line.  The Ada program is a normal Ada program, residing
in a Common Gateway Interface directory or subdirectory.

The INPUT tag causes a SUBMIT button to be displayed with the indicated
text.  When the user presses this button, the data in the various fields of
the form (text boxes, etc) is encoded into one of the enctypes and sent to
standard input of the data server indicated in the URL (in this case, an
Ada program).  I forget the name of the "standard" enctype offhand.

2. Once the Ada program (acting as a data server) receives the
data, it simply decodes/parses it and performs its function (stores data,

3. The Ada program should usually send a message back to the user,
the transaction.  To do this, the Ada program has to compose a web page
HTML) and simply send it to standard output.  The only hitch is to remember
start that web page with:
  Content-type: text/html
  ... blank line ...
  ... your program-composed HTML ...

That's about it ... no rocket science here.  Most of the tricks I had to
deal with were within the Ada program, addressing issues surrounding the
problems associated with multiple copies of the same program running at the
same time.  All data files had to be unique, and any generated scripts had
to have unique names as well.

Richard Conn, ASE and PAL Manager

> -----Original Message-----
> From: Team Ada: Ada Advocacy Issues (83 & 95)
> [mailto:[log in to unmask]]On Behalf Of Philip Johnson
> Sent: Saturday, September 11, 1999 6:39 PM
> To: [log in to unmask]
> Subject: Re: How to provide Ada with the best possible GUI. was RE: Two
> interesting approaches to job hunting and more
> > I believe that it would be very useful for my work, which is medical
> > research, and others if you would share how you have Netscape Forms
> > communicate with an Ada program. Is your work under Windows or
> some flavor
> > of UNIX? Evidently one can refer to a self-host or something
> like that in
> > UNIX. I can not do this in either Windows 98 or DOS, my preferred
> > environment.
> The platform we are building the application on is Miltope SPORT
> with Windows 95.  we also run our Stimulation lab [simulation-
> based test flow verification] on laptops running Windows 98.
> Our system is captive so we are not concerned with Web-type
> security so we essentially turn all security off.  This allows us to
> read and write to local files for transaction logging etc.
> We build our various forms within html pages and control the
> dataflow between the user, the forms and the Liveconnect interface
> with Javascript. The interface to the native code applications is
> through a Liveconnect plugin.  Some of the native applications are
> standalone and we simply provide the user interface to invoke
> them.  The main diagnostic test application is built as a dynamic
> linked library (dll) which is linked into the Liveconnect plugin.  This
> is standard (sort of) Netscape plugin techniques.
> The native applications are language independent due to the our
> approach.  They can be written in any language as long as a dll
> can be generated.
> > I hope that XML is flexible enough that a Client-only environment can be
> > specified. Windows Explore now has vector graphics, which I
> hope are based
> > on the XML standard.
> We currently use HTML and some DHTML.  We are looking at XML
> for future implementations but have not made a definite decision.
> Phil Johnson
> [log in to unmask]