RU beehive logo ITEC dept promo banner
ITEC 325
2017spring
ibarland

home—lects—hws
D2L—breeze (snow day)

hw02
arrays; a simple form
and multiple files

Due 2017.Feb.09 (Thu) in class (For section-11: due Thu 23:59)

suggestion:Complete #1-5 by Tues, so you can ask questions in class.
Submit on D2L a copy of your four files utils.php, utils-test.php, silly.php, and (after completing #8) silly-handle.php. (You can also provide a css file, if separate.) No hardcopy necessary. Hardcopy of your files, for on-campus students The files silly.php (and, silly-handle.php) should also be viewable on the web, as discussed below.

  1. For this homework, create a directory ~/dynamic_php/itec325/hw02/. Re-organize our hw01-solution into two parts:
    1. A file utils.php, which contains the definition of pluralize,
      2. and
    2. A file utils-test.php, which contains the unit-tests for pluralize (and, any for other function we add to utils.php). Of course, this file should require_once the file utils.php.

  2. (5pts) Write a function test : ANY, ANY → void which determines if the first value (an actual test-result) is equal to the second value (the desired test-result). If the two are not equal, it should print a message saying that a test failed. If the two are equal, it should merely print “.”. (Note that this is the only functions we'll write all semester, whose purpose is to print something rather than return a value.)

    We'll use this function to make our testing more convenient. For example, your tests from hw01 could be replaced with lines like “test( pluralize(4,"cow"), "4 cows" );”. This way, only tests that fail get printed, and we don't need to visually scan through lots of output about successful tests — if you see “......” you know you're good. (And if any test failed, you'll get an error message blaring at you, that you can't miss.)

    Optional (for slight extra credit): These further features make test even more useful:

    1. (2pts)recommended When testing functions which return html, it's a bit annoying if a test were to fail due only to whitespace (e.g. our function returned two spaces where the expected-output only had one space, or had a newline). SO: before comparing strings, collapse all groups of one-or-more whitespace characters to a single space1. (Hint: use preg_replace('/\s+/', ' ', …), but only call it your if your two inputs is_strings.) You may want to also trim whitespace from the start and end of each string.

      Note that rectifying whitespace is particularly helpful when you are comparing test-cases-written-on-a-Windows-system (where a newline uses two bytes), and then running the code on php.radford.edu (a UNIX machine, where any newlines are one byte). (Alternately, you can also run dos2unix on files that were originally created in Windows.)

    2. (2pts) In the UNIX philosophy, it's nice to only see printed messages when something goes wrong. Add a “switch”, so that you can get this behavior if you like: either a third, optional argument to test, or define a named-constant2 or global-variable3 just before your definition of test. Then, by changing that one boolean value it controls whether or not successful-tests print nothing, or print “.”. (Be sure that test always prints something when a test fails, though!)
    3. (2pts) Add an optional third parameter: a boolean to decide if you really want to “normalize” string whitespace, or not. Its default value should be false.
    4. (2pts) You may add further features if you like, such as keep a counter of how many tests have been made, and then any failing-tests can include the test-number as well as other details. (Myself, I made an additional function testResults, which prints those statistics.)
    (You don't need to have test-cases for test itself; since it's a void function that prints, it's not suitable for unit-testing. This means you need to be extra careful to make sure it really does work as you expect.)

    Put this function into utils.php -- it is a utility function-definition. It doesn't go in utils-test.php. because it is not itself testing anything (it's a function that your unit-tests will call to help them do their job!)

  3. (5pts) Move your hw01 test cases into utils-test.php, and re-write them to call test instead of doing any printing directly.
  4. (5pts) Make a file silly.php which:
    1. Prints a web-page. A silly, exceedingly short web-page.
      Of course, it should be proper (x)html(5), as one of the standard-requirements for this class. Mostly, that means making sure every tag closed (including br and p tags), and every attribute should have a value, enclosed in quotes).
    2. It must call pluralize, hyperlink, and thumbnail somewhere.
    3. It should contain “<?php” exactly once at the very top, end with “?>”, and be filled with echo statements in between.
  5. (5pts) Make sure silly.php is runnable via the web at https://php.radford.edu/~yourUserName/itec325/hw02/silly.php. You'll also be doing this for most all the future homeworks.
  6. (10pts) Write a function table_r (“table, aligned right”): It takes an array of strings, and returns a string that is HTML for a table with one column; each row is one of the array's values, right-aligned.

    example of table with one columns, which is right-aligned For example, given an array containing "out of stock", "2.75", and "n/a", it would return HTML that would render similar to the table at the right. Your table doesn't have to look exactly like this, but the entries should be aligned to the right. For full credit, include a css class for such a table.

    hint:To make the next problem easier, apply the CSS to individual cells, not the row or entire-table.

  7. (10pts) Now, generalize the above function so that if an array entry's key is a string (rather than numeric), the corresponding row has two columns — the key, followed by the value.

    example of table with two columns, the 2nd column being right-aligned For example, given an array containing "Snickers" => "out of stock", "Milky Way" => "2.75", and "happiness" => "n/a", it would return HTML that would render similar to the table at the right. If (while making test cases and thinking about any odd inputs) you want to either document what odd-but-legal inputs do, or you want to document a pre-condition about what you consider a requirement for a legal input, please do so.

    Note that your previous test-cases from #6 should be unchanged — when passed an array with numeric indices, table_r should give the same result as before. (You will just turn in this single, more general version of your function, not two versions of it.)

  8. (10pts) Finally: Upgrade silly.php so that it is a form. It should have an input for the user's name, and at least one other input plus a submit-button. After submitting, the user should see a page which addresses them by name, and prints out the other user-provided piece of information as well. Do not use var_dump($_POST). (However, if you like you can pass $_POST to some other function you've written which accepts an array of key/value strings.)

    Remember that silly.php (or its handler) is not the same as making unit-test cases.

Standard Homework Requirements

For all assignments in this class (and all your classes, as appropriate):

  1. Your primary file (utils.php in this case) must start with a comment containing: Your name; the class/semester; the URL of this assignment page.
  2. Every function should be commented with a short (1-sentence) description, (which mentions every parameter by name), and should indicate the types of the parameters and the return-type.

  3. You do not need to check for invalid-inputs to your functions. E.g.: if I ask for a function taking in (say) a number and a string, and you repeat in your function-comment that your function handles a number and a string, then you don't need to check for being given incorrect inputs — that's the caller's problem, not yours. Similarly for more refined types like "non-empty-string" or "integer in the range [1,12]": if it's in the comments as a pre-condition, that'll suffice.4

    (We'll talk about validating input received from the (external, untrusted) user later.)

  4. Any HTML/XML for this class should follow the following common guidelines: We'll require these even where it's not strictly needed for (mere) HTML5 compliance.

1Why not collapse whitespace to nothing at all? This is tempting, since an actual&desired output of "<ul></ul>" and "<ul>\n</ul>" would then be considered okay. However, this allows false-negatives: getting "hit here" when expecting "hi there" wouldn't register as an error. (… I guess the best of both worlds might be, after collapsing whitespace, make another substitution which removes any space right before/after any "<" or ">", as well as on either side of the the "=" between an attribute and its value? That still has allows some false-negatives, but not as many. It's much harder to this exactly get right though, if just using regular expressions.)      ↩
2You can make named-constants with php's global keyword.      ↩
3 In php, global variables are a bit odd, in that: if you have a function which wants to reach out and use a global variable (defined outside the function), you have to use the keyword global.      ↩
4 While the defensive-programming can be helpful in bigger projects (esp. in untyped languages like php), it's never interesting code. If you DO want to do the checks anyway, that's fine, but do all the type-validation right away (before you enter the 'real' function-logic), and throw an error if something goes wrong (don't continue and return some sort of odd, undocumented answer). For example: 
function foo( $someNum ) {
  // optional error-check:
  if !(is_numeric($someNum)) { throw new InvalidArgumentException( 'foo: expected number, given ' . $someNum ); }

  // ...now put your real code, uncluttered by further type-checks.
}
(Ideally, you'd include the type-requirements in comments, and then a tool would automatically generate the above boilerplate error-checking for you. That's what Java's type-system gives you, for example.)      ↩

home—lects—hws
D2L—breeze (snow day)

©2017, Ian Barland, Radford University
Last modified 2017.Feb.09 (Thu)		 Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu		 Rendered by Racket.