• Login
  • login to access premium content (it's free).

HTML/OS Case Study for Beginners

Contributed by Darryl Kissinger

About This Document

Even after 14 years working with HTML/OS I still often feel like a beginner. That initial feeling of exhilaration at having found a super-easy-to-use yet powerful tool for building web-based applications is almost daily regenerated as I continue to explore a seemingly endless potential to create useful software built with HTML, CSS, Javascript, and HTML/OS Otags. In this document I explain how HTML/OS was used to solve some specific business problems, and hopefully in the process also pass on some useful methods as well as my personal enthusiasm for HTML/OS.

Overview of Contents

Content sections generally follow a time sequence of presentation, with first-developed case applications covered first. To the degree the case study system development followed a typical business system development cycle, studying the case in time sequence may help the reader deal first with those types of problems that typically occur early in a development process, and progress from there. Time sequencing also takes advantage of the fact that the case study programmer started the project as a beginner, so the beginning reader may follow along with his learning curve.

What’s so easy about HTML/OS?

The answer to this question would have been hard to explain to me as a beginning web programmer, even though I had already worked in several non-web oriented programming environments where months of continuous ramp-up time was typical for professional programmers to become effective in a new language environment. My actual experiences trying to get started with other web environments set the stage for the amazement I felt after completing my first web-based application with HTML/OS.

The built-in database system is an important contributor to making HTML/OS easy. This ease does come at the cost of not being SQL or ODBC-compliant, which may potentially be a serious problem for some users. However, in terms of ease of use for the user who does not need the universality of these standards, a lot is gained by having database access methods embedded in the language, as well as the ability to maintain the database from within the HTML/OS environment.

Other contributors to making HTML/OS easy: the simple structure of HTML/OS code that runs before page creation (underlay), during page creation (inlay), and upon a form submit button being clicked (on-click overlay); the session environment that is automatically created and maintained through all subsequent page changes after simply accessing a start link (without relying on client cookies); the private folder environment which can protect page files at an increased level of security; a rich library of tags, called otags or overlay tags, that deal with many common business-oriented tasks with simple syntax and straightforward parameters.

Why was HTML/OS selected?

The first website we developed using HTML/OS was originally a static website, meaning it consisted entirely of HTML, CSS, and Javascript files and no server-side programming or database. In addition to products and services being described on the static website, emails were sent out using mailing list software, periodically letting prospects and customers know about new offers and updates to existing products, among other things. Landing page forms were used to collect contact information by forwarding emails to company mailboxes where the information was read and manually entered into a local database used by the mailing list software.

Automating this process was the first task for which a client-side programming language was evaluated. Several environments were quickly investigated, ending with an online demonstration of HTML/OS, immediately after which the few lines of code needed to perform the needed function were created and the problem was solved. The solution was easy to understand, quickly created, and implemented within a few minutes, while the competing solutions never made it out of the investigation stage.

Applications

The following section describes some of the business problems encountered by the website owners and the associated solutions created using HTML/OS, starting first with earlier, simpler applications and progressing to more recent additions. These descriptions represent how the problems were actually solved, with no attempt to note where the solution was the most efficient or best practice at the time, or how it could have been improved then or might be written better now. This level of analysis will be left to those better qualified to pursue it. So I encourage the reader to consider that in every case there may very well be a better way to get the desired result. In any case I hope these descriptions might help in some way to provide a point of reference along the path to finding the best solution.

1) Form Content Storage and Retrieval

Website pages consisted of HTML, CSS and Javascript files displaying information about products and services, contact information, and forms to fill out for more information. The forms were set up to send emails to a company mailbox and from there the form field contents were manually entered into a local database from which daily reports were printed.

The company wanted to eliminate the manual entry step and have the data automatically entered into a database from which daily reports could be printed.

Solution Summary

The website consisted entirely of HTML, CSS and Javascript files with no server-side programming or database. Since form submissions were being serviced by the web server, a server-side language seemed like the best candidate for automating data collection because there was no requirement to continue using the database currently in use to store form submission data.

After several weeks of investigation, HTML/OS was selected and the environment was installed in less than an hour. A database with the appropriate fields to store the form data was created within a few minutes. With a few hours more work the solution was completed by adding a form handling routine in an on-click overlay in the form file, and writing a report using a new HTML page added to the website’s new private directory.

Solution Details

The new database was named “email_login” because its main function was to capture contact email addresses, and it was anticipated that a user login capability would be added to the site soon, and a place would be needed to store that information. As it turned out, the user login credentials were not added to this file, but more form fields were added regularly as Marketing found new uses for the database. The original version of the file consisted of about 20 fields (shown below) although it eventually grew to its current size of 184 fields.

A form handling routine was added to the page that displays the form, and the link the user clicks to get this page was changed to an HTML/OS start link.

Here’s the start link added to the landing page for the user to access the form page. The start link activates the HTML/OS engine and a new session is opened. Request Info

In the info-request-form.htm form page body the form fields are named the same as the field names in the database. Only four of the fields are shown below, but all 20 could be included in the form if desired. Notice the hidden field EL_DATE_WRITTEN. This field is not displayed in the browser, but its value is supplied by the HTML/OS TODAY tag so the date can be written to the database.

 <body>
  <form action=“process_form”>
   Name<input name=“EL_EMAIL_ADDRESS” size=“50” maxlength=“60”><br>
   Title<input name=“EL_NAME” size=“50” maxlength=“60”><br>
   Email Address<input name=“EL_EMAIL_ADDRESS” size=“50” maxlength=“60”><br>
   <Input type=“hidden” name=“EL_DATE_WRITTEN” value=“<<TODAY>>”>
   <input type=“submit” value=“submit”>
  </form>
 </body>

After the tag in the info-request-form.htm form page, the following on-click overlay processes the form. Notice the overlay name processform matches the action parameter in the form tag. The DBADD tag writes a record to database emaillogin using the data in the variable names that match the email_login database field names (the same names used in the form fields above). 

</html>
<<overlay process_form
 add_status=DBADD(“/apps/dbcons/email_login”)
 GOTO “info-request-form-thankyou.htm”
>>

Finally, a page was created to display the records added, including statements like the following. Notice reportlist items in the displayed table refer to column numbers that match the field numbers in the emaillogin database.

<<
  report_search=‘EL_DATE_WRITTEN=“‘+TODAY+’”’
  report_list=DBSEARCH(‘/apps/dbcons/email_login’, report_search, ‘1’, ‘100000’)
  report_count=dbresults[2,1]
  IF report_count>0 THEN
   DISPLAY ‘<table align=“center”>’ /DISPLAY
   FOR NAME=index VALUE=1 TO report_count DO
    DISPLAY ‘
     <tr>
      <td>’+report_list[18,index]+’</td>
      <td>’+report_list[3,index]+’</td>
      <td>’+report_list[2,index]+’</td>
      <td>’+report_list[6,index]+’</td>
     </tr>
    ‘ /DISPLAY
   /FOR
   DISPLAY ‘</table>’ /DISPLAY
  /IF
>>

Result

Landing pages referenced by marketing emails can now contain forms that reference an HTML/OS overlay where form data is automatically written to a database, and a page can be accessed that displays a report of the current day’s form submissions.

Comments

The description of this solution was kept very brief because it’s the first one. The actual solution included additional features including field content validation and feedback, email notification that a form submission has taken place, and a report options screen for specifying data selection and sorting parameters.