.. index::
single: web page; basics
Web page Basics
===============
.. _Format-of-Web:
Format of Web Page Markup
-------------------------
Documents can be presented in many forms. A simple editor like Idle
or Windows' Notepad produce plain text: essentially a long string
of meaningful characters that appear in the final text you view.
Documents can be displayed with formatting of parts of the
document. Web pages allow different fonts, italic, and boldfaced
emphases, and different sized text and paragraph layouts. Microsoft
Word, Libre Office, and OSX Pages, all display documents with various
amounts of formatting. The syntax for the ways different systems
*encode* the formatting information varies enormously.
If you look at an old Microsoft Word .doc document in a plain text editor
like Notepad, you should be able to find the original text buried
inside, but most of the symbols associated with the formatting are
unprintable gibberish as far as a human is concerned.
.. index::
web page; tags
<...> web page tags
tags in web pages
Hypertext markup language (HTML) is very different in that regard.
It produces a file of entirely human-readable characters, that
could be produced with a plain text editor, but the *markup*
parts of the file do not appear directly in your browser,
but *instruct* the browser how to format the page.
For instance in HTML, the largest size of a heading with the text
"Web Introduction", would look like
Web Introduction
The heading format is indicated by bracketing the heading text 'Web
Introduction' with markup sequences, beforehand, and
afterward. All HTML markup is delimited by *tags* enclosed in angle
brackets, and most tags come in pairs, surrounding the information
to be formatted. The end tag has an extra '/'. Here 'h' stands for
heading, and the number indicates the relative importance of the
heading. (There is also h2, h3, .... for smaller headings.) In the
early days of HTML, editing was done in a plain text editor, with
the tags being directly typed in by people who memorized all the
codes!
We will use little enough of the markup that the very limited introduction
in :doc:`htmlsource`, along with samples that show easily modified examples,
will cover all the markup you need for the course.
.. index::
web page; Kompozer
Kompozer
With the enormous explosion of the World Wide Web, specialized
software has been developed to make web editing be much like word
processing, with a graphical interface, allowing formatting to be
done by selecting text with a mouse and clicking menus and icons
labeled in more natural language. The software then automatically
generates the necessary markup. In this tutorial,
a possible example for Windows users and Macs
that are NOT upgraded to the Catalina OSX version,
is the free, open source Kompozer from
https://sourceforge.net/projects/kompozer/. It downloads the appropriate version
for either a Windows machine or Mac with operating system version *before* Catalina. Users of Catalina, or later OSX versions, can look at the introduction
to the Mac app TextEdit in :doc:`htmlsource`.
If your operating system fits, you might download Kompozer,
if you are not already using another environment that lets
you see both the unformatted plain text and the formatted view.
An alternative for the simple markup needed for exercises is to modify example html source code
using the ideas in :doc:`htmlsource`.
.. index::
single: web page; static
.. _Introduction-to-Static:
Introduction to Static Pages in Kompozer
----------------------------------------
If you cannot run Kompozer, you can see the parallel
html source discussion in :doc:`htmlsource`, and skip this section
that is specifically on Kompozer.
This section introduces the Kompozer web page editor to create
*static* pages. A *static* page is one that is created ahead of time
and just opened and used as needed. This is as opposed to a *dynamic* page,
which is a custom page generated by software on demand, given some input
parameters.
You can open Kompozer and easily generate a document with a heading,
and italic and boldfaced portions....
Kompozer is used because it is free software, and is
pretty easy to use, like a common word processor. Unlike a common
word processor you will be able to easily look at the HTML markup
code underneath. It is not necessary to know a lot about the
details of the markup codes for HTML files to use Kompozer, but you
can *see* the results of the markup.
We will use static pages later as a part of making dynamic pages,
using the static pages as templates in which we insert data
dynamically.
To creating static web pages
#. However you start Kompozer, go to the menu in Kompozer and select
:menuselection:`File --> New`.
You will get what looks like an empty document.
#. Look at the bottom of your window. You should see a **Normal**
tab selected, with other choices beside it, including a **Source**
tab. Click on the **Source** tab. You should see that, though you
have added no content, you already have the basic markup to start an
html page!
#. Click again on the Normal tab to go back to the Normal view (of
no content at the moment).
#. Assume you are making a home page for yourself. Make a title and
some introductory text. Use regular word processor features like
marking your title as Heading 1 in the drop down box on a menu bar.
(The drop down menu may start off displaying 'Paragraph' or 'Body
Text'.) You can select text and make it bold or italics; enlarge it
... using the editing menu or icons.
#. Before getting too carried away, save your document as
home.html in the existing
*www directory under your earlier Python examples*. It will save a
lot of trouble if you keep your web work together in this www
directory, where I have already placed a number of files that you will
want to keep together in one directory.
#. Just for comparison, switch back and forth between the Normal
and Source views to see all that has gone on underneath your view,
particularly if you edited the format of your text. Somewhere
embedded in the Source view you should see all the text you
entered. Some individual characters have special symbols in HTML
that start with an ampersand and end with a semicolon. Again,
it is more important the understand that there are two
different views than to be able to reproduce the Source view from
memory.
#. You can use your web browser to see how your file looks outside
the editor. The easiest way to do this is to go to the web
browser's menu and select something like
:menuselection:`File --> Open File`, and find the home.html
file that you just wrote. It should look pretty similar to the way it looked in
Kompozer, but if you had put in hyperlinks, they should now be
active.
The discussion of web page editing continues in
:ref:`Editing-HTML-Forms`, but first we get
Python into the act.
.. index::
single: web page; document naming conventions
.. _Editing-and-Testing:
Editing and Testing Different Document Formats
----------------------------------------------
.. note::
In this chapter you will be working with several different types of
documents that you will edit and test in very different ways. The
ending of their names indicate their use.
Each time a new type of
file is discussed in later sections, the proper ways to work with
it will be repeated, but with all the variations, it is useful to
group them all in one place now:
...Web.py
*My* convention for regular Python programs taking
all their input from the keyboard, and producing output displayed
on a web page. These programs can be run like other Python
programs, directly from an operating system folder or from inside
Idle. They are *not* a final product, but are a way of breaking
the development process into steps in a testable way.
...cgi
Python program to be started from a web browser and run by a web server.
You will develop code using a local web server on your own machine.
...html
Web documents most often composed in an editor like
Kompozer. By *my* convention, these have a sub-categories
...Template.html
not intended to be
displayed directly in a browser, but instead are read by a Python
program (...cgi or ...Web.py) to create a template or format string
for a final web page that is dynamically generated inside the
Python program.
Other files ending in .html are intended to be directly viewed
in a web browser. Except for the simple static earlier examples in
:ref:`Introduction-to-Static`, the pages for this course
are designed to reside on
a web server, and include forms that can pass information to a Python CGI
program (...cgi).
.. index::
double: web page; localhost
To make this work on your computer:
#. Have all the web pages in the same directory as the example
program localCGIServer.py. It is easiest to leave it in the www
subdirectory of your examples directory.
#. Looking ahead to when we get to using a server dynamically
(:doc:`dynamic`):
#. Include the Python CGI server programs in the same directory.
#. Have localCGIServer.py running, started from a directory window,
*not from inside Idle*
#. In the browser URL field, *the web page file name must be*
*preceded by* ``http://localhost:8080/``. For example,
http://localhost:8080/adder.html would refer to the file
adder.html, in the same directory as the *running*
localCGIServer.py. The URL may either by an html file or
possibly a CGI file. For example, http://localhost:8080/now.cgi
would call the file now.cgi (assuming it is in the same directory as
the running localCGIServer.py).
#. Most often CGI programs are
referenced in a web form, and the program is called *indirectly* by
the web server. CGI programs can be edited and saved inside Idle,
but they do *not* run properly from inside Idle. They must be run
via the server/browser combination. More on this later.