* course text, chapter 2, and chapter 6 sections
6.1 and 6.2, are a NICE "strict" HTML5 intro
for basics and forms;
hyperlinks!
* a element - a for ANCHOR
with an href attribute whose value is
where the hyperlink should lead
that destination can be expressed as a relative
file name (relative to the location of the
containing page) OR as a URL
This is a link to <a href="http://www.w3c.org">
W3C</a>.
* style: use link text that DESCRIBES
the page being linked to;
line breaks -- <br />
* class style: use <br/> <br />
lists! (these are block-level)
* unordered list ul
ordered list ol
definitions list dl
both and ul and ol:
the list items are li elements
but definition lists, dl element,
contain dt elements for the terms being
defined,
and dd elements for the definitions
you can nest these
* there are ways to express special characters
usually either by a unicode or a symbolic
means;
< for the plain < characters when you
DON'T mean opening a tag!
& is an ampersand...!
* for content where you just want the line
breaks you typed, use the pre element
for "short snippet" of code,
the code element is preferred, but does
NOT preserve spaces and line breaks --
for blocks of code,
this is a good idea:
<pre><code>
for (int i=0; i<3; i++)
{
cout << "Hello world!" << endl;
}
</code></pre>
tables...
* appropriate for tabular data
* table element
tables tend to have rows, put in tr elements,
and rows are made up of
table data, td elements,
and table headers, th elements
you CAN use a caption element -- right
after the table start tag --
to indicate the caption of a table;
td and th elements can have rowspan
and colspan attributes to indicate
a column that spans multiple rows
or a row that spans multiple columns
FORMS!
URL
browser/client --------> web server/application
HTML+
browser/client <-------- web server/application
form data
browser/client ---------> web server/application
^
|---> data server
response/output
browser/client <-------------- web server/application
* so -- since we're going to be using
a web interface on the client tier
in our particular n-tier applications,
we'll be using HTML forms frequently
on the client tier;
* [course text, p. 206]
"An HTML form is a group of controls that
allows a user to submit information to
a web server"
* make sure you note: only control elements
WITHIN a form element are "part" of
that particular form instance...!
* the form, when submitted, may provide
query parameters to the application tier --
name=value pairs, if you will --
when these are transmitted using a
method of "get", you actually see
these at the end of the URL:
? then name=value pairs separated by &
http://www.google.com/search?q=miserable+failure&start=10
form element:
* numerous optional attributes, but one required
attribute: action attribute, whose
value is the web server's target URL to which the
form data should be submitted
<form action="http://blah">
</form>
* if you don't have a method attribute, a method
of "get" looks like the default,
and that's when you get the query parameters at
the end of the the action URL when the form
is submitted
(use method value of "post" when you'd like
that information sent "separately")
some form controls:
* a submit! (because a CS 318 code style standard
is going to be (at least until we get to Ajax...)
that ALL forms should have at least one submit
button!!
the input element is used for SEVERAL controls;
...you indicate which with a type attribute
(if you omit, you get a single-line textfield)
<input type="submit" />
* want different text than the default?
set the value attribute to the desired
label text
* typically a submit button doesn't NEEED to send
a name=value pair, SO they don't typically
have a name attribute.
(but if they do, then they will --
the given name as the name,
and its label as its value)
single-line textfield
* input element with no type attribute,
or a type attribute whose value is "text"
* NEEDS to have a name attribute -- so that
textfield's value when the submit button is
clicked will have a name for a submitted
name=value pair!
* MANY optional attributes are also possible --
see p. 211