=====
CS 328 - Week 14 Lecture 2 - 2025-04-30
=====

=====
TODAY WE WILL
=====
*   announcements
*   continue WHIRLWIND TOUR of intro to client-side JavaScript
*   prep for next class

=====
*   should be working on Homework 11
    *   at-least-first-attempts due by 11:59 pm Friday, May 2

    *   submit early, submit often

*   should be reading/working through zyBooks Chapter 7 - 7.1, 7.7, 7.8, 7.9
    *   talking about some of this now!
    *   deadline for credit for its activities: 11:59 pm Friday, May 9

*   Homework 11 IS the last homework;
    *   I will post a bonus-hw-points thing to give a little more
        JavaScript practice to those who might want it

=====
event-driven programming in JavaScript
=====
*   event-driven programming: execution does not just start at a main
    function as in, say, C++; instead, what is done and when is determined
    or driven by events and user interactions

    event: something that happens such as a user clicking a button,
           checking a checkbox, etc.

    event-driven program: program WAITS for some event to occur,
        and then REACTS to it, via code (event handlers) written
	to respond to that particular event

*   in JavaScript,
    here's a typical way to respond to an event:
    
    1. decide which element or widget we want to respond to
    2. write a JavaScript function with the code doing the desired response
    3. attach that function to the appropriate event attribute of
       that element or widget

*   HTML elements can have special event attributes that represent
    actions that can be done on that element,
    whose value is expected to be a function with what's to be
    done when that event happens to that element

    these event attributes' names start with on:
    onclick  oninput onchange onsubmit etc.

    *   when you set an event attribute for an element,
        it can be said to now be listening for that event on
	that attribute

*   but we are trying to write unobtrusive-style JavaScript --
    SO: we will add these event attributes containing JavaScript
    IN the head element using the Document Object Model (DOM)

=====
strict mode
=====
*   to enforce strict mode (supported starting the ECMASCript 5),

    put EXACTLY the following as the VERY TOP of your:
    *   JavaScript file (.js file)
    *   or script element
    *   or function body

"use strict";

=====
HTML button
=====
*   a general button!
*   it has content! <-- that will appear atop the button by default
*   it is an inline element

=====
GOOD PRACTICE when MODIFYING the Document Object Model's (DOM's) document
    object
=====
*   it is considered good practice NOT to modify the CURRENT document
    until that document has been loaded

    *   JavaScript DOM window object represents the browser window

    *   the event corresponding to a window's being finished loading
        the current document is the load event,

	so we can make window's onload attribute have the action to
	be done when the document is loaded

    *   window.onload = function()
                        {
                            ...
                        };

        (can also set it to a named function, as well)

=====
script attributes async="async" and defer="defer"
=====
*   [note: adding after class, so you'll find it here if referencing
    this later - it is also mentioned in the Week 14 Lab Exercise
    handout]

*   NOTE that, for external JavaScripts, it is also USEFUL to add 
    ONE of these ADDITIONAL attributes (written using the 
    course-required strict style):

    async="async"
    defer="defer"

    *   BOTH of these tell the browser it is SAFE to 
        continue parsing HTML while this external JavaScript is 
        being downloaded; 

        (that is, both are assuring the browser you are using 
        good modern practice of NOT modifying the DOM until the 
        page is loaded)

    *   async="async" 

        ...means that this external JavaScript can be downloaded 
        at the same time as HTML parsing and other JavaScript downloads 
                    
        (for example, it does not depend on anything from a 
        previous JavaScript)

    *   defer="defer" 

        ...means that, while it can be downloaded at the same time 
        as HTML parsing, the JavaScripts need to be executed 
        in the order their script elements appear (for example, 
        because one uses a function from an earlier one)

=====
validating a form using a JavaScript
=====
*   client-side JavaScript CAN prevent a form from being submitted
    to the application tier.

    *   you give the FORM element an attribute named
        onsubmit

    *   when someone tries to submit that form,

        IF that onsubmit's event handler/function returns true,
        the form's name=value pairs WILL be submitted to the
	application tier.

        IF that onsubmit's event handler/function returns false, 
        the form's name=value pairs will NOT be submitted
	to the application tier.

    ====SEVERAL CAVEATS ====

    *   this is good to do,
        BUT it does NOT mean the application-level can avoid ANY of the
        usual checking for bad input, bad stuff, etc.
        (the request may be coming from a page other than this one...!)

    *   if there is a an HTML element or attribute that verifies
        the thing on the client tier, that's a better choice than
        using JavaScript
        *   e.g., when the user is to enter a numeric value,
    
            it is better to use an input of type="number"

            than to use an input of type="text" and then use
	    JavaScript to make sure they enter a number;