===== CS 328 - Week 14 Lecture 1 - 2024-04-22 ===== ===== TODAY WE WILL ===== * announcements * a few JavaScript functional programming features * (review?) event-handling in JavaScript * validating a form with JavaScript * prep for next class ===== * should be working on Homework 11 * at-least-first-attempts due by 11:59 pm on FRIDAY, May 3 * should be reading/doing activities in zyBooks Chapter 6 - More PHP and Chapter 7 - JavaScript Fundamentals * deadline to complete these: 11:59 pm pm Friday, May 3 ===== * one more CS FACULTY CANDIDATE should be giving their TEACHING TALK during this Wednesday's CS 328 class: * Wednesday, April 24 (May 1 candidate dropped out) * the FIRST 45 minutes will be their talks, FOLLOWED by CS 328 course material for the REST of those class sessions * RECORDINGS will be posted to supplement for the missed class time * Because of the importance of student feedback on these candidates, you will receive 2 clicker questions' credit for attending their talks * (and there WILL be at least one actual clicker question during the class material following) * Let me know if you have any questions about this!! ===== two tips for debugging (client-side) JavaScript * because JavaScript errors can be very "quiet"... * JSLint - https://www.jslint.com/ * browsers typically have tools! e.g.: Chrome, View->Developer->JavaScript Console * When my JavaScript does not seem to be doing anything, I tend to first check the JavaScript console or some such console in the browser I am using, and if that does not help, try to figure out which checkboxes to specify in JSLint to try to get further ideas about what might be going wrong! ===== thing 1 - JavaScript has significant functional programming features! ===== * like what? for example: anonymous functions! function ( ) { ... } ...just leave out a function name! ...this is an expression whose type is function, and can be assigned to a variable, passed as an argument, assigned to an element's attribute, etc.! let looky = 3; // looky's value is 3 looky = "moo"; // now looky's value is "moo" looky = function() { alert("Called by a function with no name!"); }; // now looky's value is that anonymous function! // if you pass looky as an argument now, you pass this // function as an argument! ===== thing 2 (review) - event-driven programming in client-side JavaScript ===== * event-driven programming - execution driven by events and user interactions WHEN a user clicks on something, THEN something happens; program essentially waits for a user action, then responds to it; * there are numerous models for event-driven programming -- often, code called event handlers are written to, well, handle events; * in client-side JavaScript, here's how that works: * decide which element or control to respond to * write a JavaScript function with the code to be executed when an event on that element or control occurs * attach that function to the element or control's event ...in HTML, elements have attributes that correspond to particular types of events; these attribute start with on - onclick, onsubmit, onmouseover, etc. ...you attach a function to the element by giving it an on-attribute whose value is the desired JavaScript function ...and if we are trying to use unobtrusive-style JavaScript, we add these on-attributes to elements in the head element. * BUT it is considered rude to modify the current document before it has been finished being loaded; fortunately, there's a DOM object named window that corresponds to the browser window, and you can assign a function to its onload attribute to be executed on the event of loading the document into the window being completed window.onload = function()... ===== 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 function returns true, the form's name=value pairs WILL be submitted to the application tier. IF it 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;