==== 2020-sep-04 (Fri) === running php via the web [see also: lecture-notes "running php via the web"] I’ll look at your php homework files on the host: itec-php01.radford.edu
 If I request the URL itec-php01.radford.edu/~ibarland/itec325/hw02/file.php then the server is configure to find the file: /dynamic_php/itec325/hw02/file.php Make sure the file is readable-by-other (and executable too is okay) AND ITS ENCLOSING FOLDERS are executable-by-other (and readable too is okay) (know how to use `ls -ld` and `chmod` to ensure this) == Task to do today: Create a php file and the above enclosing folders, and make sure you can view it via the URL on itec-php01. (If it doesn't, then pay attention to the error -- is it "file not found" [you don't have the file in the right place… or IT doesn't have your account set up correctly for ITEC students] vs "not authorized" [file is there, but some persmission is wrong]. You can also test by trying a file right in your ~/dynamic_php/file.php w/o any intervening folders.) === How to test a form-handler == Understanding how values get put into $_POST: Apache does it! The php server, when it gets a request for foo.php file, chooses to *run* foo.php (and serve back whatever that file printed). IF the server sees that the http-request-packet included form info, THEN BEFORE it runs the php program it does following: it runs the php == testing our form-handler: WE will write the following programs, to test our form-handler: ~~~~ form-handle-test2.php ~~~~ form-handle-test0.php ~~~~ form-handle-test1.php ~~~~ form-handle-test1.php ~~~~ Now I can test my form-handler easily: I just run `form-handle-test2.php` from the command line. Reasons why testing like this is good/handy: - I can easily see what my form-handler does with different inputs, *without* having to go hand-type anything into a form, or even visit the page. - I can test my form-handler INDEPENDENTLY of any network/web/file-permission issues. - I can also run that test-handler via the web, thereby also testing the web-connection. - I can test for attackers who are submitting key/value pairs that couldn't come from a innocent use of the my own form. [The attacker can bypass the form entirely, and still submit to the form-handler!] [Real-world note: `curl` in addition to running such programs entirely separate from web, a web-firm would also want to auto-test their pages w/o needing to go to the URL from a browser "manually". So, you'd run `curl`, which is a *program* that can request URLs (including headers and form-data). That way you can fully automate your test suite: make `curl` requests with different form data, and then have a program that examines the resulting html to make sure certain things do/don't appear in it.] ==== 2020-sep-07 (Mon) (sanitizing html) ==== 2020-sep-09 (Wed) function foo( string $name, boolean $hasFun, int numGameConsole = 1 ) : string { .... } test( foo("ian", false), "haha" ); test( foo("ian", false, 1), "haha" ); test( foo("ian", false, 17), "whoa" ); Imagine a table of radio-buttons: like dislike meh never-been cfa x dalton x wendy's x freds'wraps test( radioTable( ['cfa', 'dalton', "wendy's", "fred's wraps"], ['like', 'dislike', 'meh', 'never-been'] ), ...desired-result...); // one example of what we'd like to render: like meh dislike cfa o o o dalton o o o test( radioTable( [], ['like', 'dislike', 'meh'] ), << like meh dislike DESIRED-RESULT ); test( radioTable( ['cfa'], ['like', 'dislike', 'meh'] ), << like meh dislike cfa DESIRED-RESULT ); test( radioTable( 'dining-preferences', ['cfa', 'dalton'], ['like', 'dislike', 'meh'] ), << like meh dislike cfa Dalton DESIRED-RESULT ); (recall, later the form-handler will look up $_POST['cfa'], which would hold the value "like" if selected) $_POST = { 'name' => 'Ian B', 'state' => 'VA', 'dining-preferences' => { 'cfa' => 'like', 'dalton' => 'meh', ... 'au bon pain' => 'meh' }, 'on-campus' => 'yes' } ============== those were test cases ================ now, let's write radioTable: radioTable( 'dining-preferences', ['cfa', 'dalton'], ['like', 'dislike', 'meh'] ) radioTable( 'dining-preferences', ['CoD', 'FF MXM'] ['xbox', 'ps4', 'switch'] ) // Return the html for a table of radio-buttons, // where each row is a single bank of buttons (with a `$rowHeader` as the row's title) // (and we have many rows). // // radioTable : string, string[], string[] --> string function radioTable( string $name, array $rowHeaders, array $columnHeaders ) : string { $headerRow = headerRow( $columnHeaders ); $rows = ""; foreach ( $rowHeader AS $rowHeaders ) { $rows = $rows . radioTableRow( $name, $rowHeader, $columnHeaders ); } return "\n$headerRow$rows
"; } ==== 2020-sep-25 $allErrors = addStringInvalidMsgToArray( $formInfo, 'quest', 20, true, $allErrors ) but hey, our real error-message-creation-function was `stringInvalidMsg`; shouldn't our functino `allErrors` have 3-4 lines like: $theQuestErrMsgOrFalse = stringInvalidMsg( $formInfo['quest'], 20, true ); if (is_string($theQuestErrMsgOrFalse)) { $allErrors['quest'] = $theQuestErrMsgOrFalse; } In php (but not most other langs): if you declare a var `$x` outside of a func, then inside the function you need to either: - declare `global $x;` or use `$GLOBALS['x']` Note: php considers a few variables as special "superglobals" -- ie. $_POST, $GLOBOALS ==== 2020-oct-09 ==== 2020-nov-02
// What I want: ">
Here's what to do, if you need xslt to compute an attribute-value:
Γ G

Some Kids

  • , who is ...
==== 2020-nov-06 rather than year_built + 2020 year_built + 2020 // we ASSUME built B.C. 2020 - (-year_built) or better yet (not *assuming* @era = BCE) 2020 - ((if @era='BC' then -1 else +1) * year_built) Hey, in addition to the above, there's a "-1". Why? built in 2000 BCE, and currently 2020 CE: isn't the year-standing 2020-(-2000) ? Note: no year 0 (!) -- straight from 1BCE to 1CE. ==== 2020-nov-08 vs.