=====
CS 328 - Week 4 Lecture 1 - 2025-02-10
=====
=====
TODAY WE WILL:
=====
* announcements
* CLIENT tier: a FEW more HTML form widgets
* prep for next class
=====
* should be starting Homework 3!
* all files are submitted on nrs-projects using
~st10/328submit
* BUT! Problem's 1's "second database" files are
submitted with a homework number of *** 33 ***
and Problems 2-onward use a homework number of *** 3 ***
* (it is very reasonable to have .sql files in a
directory that is not under public_html,
so remember to run ~st10/328submit from each
directory that has files to submit)
* if you haven't finished them yet,
should still be reading/working through Chapters 1 and 2
of the course zyBooks
* we'll start our coverage of PL/SQL on Wednesday
* there is not a zyBooks chapter for this;
* I will be posting some resources to supplement the
in-class examples
=====
comment about the label element
=====
* it DOES have two approaches to logically connecting a label
to a form widget:
* label may have a for attribute whose value is the
value of the id attribute for the desired widget
* label may have the desired widget as part of its
content
* both work! (and both are acceptable for CS 328!)
BUT, the for-attribute approach is easier for use with CSS,
so I tend to use that approach...
=====
reminder: fieldset element
=====
* purpose: to logically gather parts of
a form that belong together
* block element, but it CAN be within a form element
(and a fieldset can be within another fieldset element,
also)
* default formatting is a thin border around the elements
within it
* if you nest a legend element within a fieldset,
that legend's content will be text appearing on
that fieldset's thin border
=====
input type="text" - a few more useful attributes
(some may work in other widgets, also)
=====
* optional size attribute - suggests how wide the textfield
should *display*, roughly in characters
(approximate!) <-- especially when a NON-monospaced font it involved!
* does not affect how MUCH the user can attempt to enter!
* optional maxlength attribute - specifies the maximum number
of characters that CAN be typed in that field
* this DOES affect how much the user can attempt to enter!
* optional required attribute
* a so-called binary attribute -- it either is there
or not
* for strict-style, give it a value that is the same
as its name
attr="attr"
* in non-strict style,
<input type="text" required name="blah" .../>
in strict-style,
<input type="text" required="required" name="blah" .../>
* there are more fun attributes!
e.g., pattern for specifying a regular expression for
the desired input from the user
* from MDN, https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/pattern:
"The pattern attribute, when specified, is a regular
expression which the input's value must match for the value to
pass constraint validation. It must be a valid JavaScript
regular expression, as used by the RegExp type, and as
documented in our guide on regular expressions."
* so: its syntax is indeed JavaScript's regular expression syntax
* for example:
pattern="[A-Za-z].*"
...matches any string that starts with a letter, followed by
zero or more of any other characters
[A-Za-z]
This will match any string that starts with a letter character
(uppercase OR lowercase)
.
Matches any single character, EXCEPT...
*
...means the previous thing may appear 0 or more times, so
.* means 0 or more of any characters.
=====
radio button - input element with type="radio"
=====
* good for a choice of EXACTLY one option from
a smallish set of options
* smallish? Because need room on the form for
the radio button and its label for EACH option
* in a logical set of radio buttons,
selecting one automatically unselects any
other
* input element with type="radio"
* all of the inputs with type="radio" and the
**SAME** name attribute value will be considered
a logical set
* ...and selecting one will unselect any other
selected
* and that name attribute's value will be the
name in the single name=value pair sent for this
logical set of radio buttons
* should each have a (different!) value attribute,
and that will be the value in the name=value pair for
this logical set of radio buttons when the form is
submitted
* good style: in each logical set of radio buttons, specify a
default radio button to be initially selected by giving it the
attribute checked="checked"
* then the user can't accidentally submit a form
with NONE of the radio buttons in a logical set
selected!
* ideally, this default would be a common
choice that users make
* for each radio button, should have a logically-connected
label element to label the radio button
=====
checkbox - input element with type="checkbox"
=====
* good for a choice of ZERO OR MORE options from
a smallish set of options
* smallish? because, here also, need room on the
form for the checkbox and its label for EACH option
* each checkbox can selected or unselected independent
of all others
* input element with type="checkbox"
* if you include check="checked", that checkbox will be
initially checked
* (as a form designer, use your power for good, not evil!
...don't try to TRICK the user into checking a checkbox
by initially checking it, unless you honestly think that
will benefit//be convenient for the user)
* should have a name attribute!
* its value will be the name in the name=value sent if
this checkbox is selected when the form is submitted
* what will the value be for a selected checkbox's name=value pair?
* IF there is NO value attribute for that checkbox, it will be value on
anchovies=on
* IF there is a value attribute, it will be that value attribute's
value
* IMPORTANT to remember:
if a particular checkbox is NOT selected when the form is submitted,
NO name=value pair is sent for that checkbox!
* for each checkbox, should have a logically-connected
label element to label the checkbox
=====
* See MORE form widgets in zyBooks Chapter 2,
and we'll be trying out those discussed today and more from
Chapter 2 on upcoming lab exercises and homeworks.
=====
* Wednesday: we'll start our in-class discussion of PL/SQL!