|
home—lects—hws
D2L—breeze (snow day)
Due 2015.Feb.09 (Mon) 11:00 Submit on D2L, and a bring hardcopy of your four files utils.php, utils-test.php, silly-page.php, and index.php to the following class. The files should also be viewable on the web, as discussed below.
For this homework, create a directory ~/dynamic_php/itec325/hw02. It will contain four files (three of which are similar to hw01):
This time, your tests should be (mostly) silent on success,
and only print output when a test fails
(such as utils-test-v2_php.txt).
Remember to use
Optional: If you want you can make tests either print “.” or nothing, depending on (say) some named constant. You can create named constants viadefine : e.g.define( 'QUIET_ON_SUCCESS', someBool ); . Regardless of this flag, failed tests should always print a loud message.
secret agenda: I'm hoping that typing all the tests becomes so much typing that you get fed up and automated it by writing your own function — something liketest( $actual, $expected ) .
This time, silly-page.php should be mostly not enclosed in
Note that this is just a regular ol' function that takes in strings and returns strings!
The fact that the strings happen to have angle-brackets in them means that the result might
be useful to people generating html, but the function itself does't really care.
(You don't need to come up with additional test cases, but you do need to actually include these tests or their equivalent. You can assume that neither string is ever empty.)
Note how the input strings don't contain any quote-characters, but the returned result does (since HTML attributes must be quoted). I recommend that your generated html uses single quote marks around attributes, but you'll get full credit for either single- or double-quote marks, as long as it is valid HTML. Make sure your test case(s) express exactly what you want the desired output should be!
Make the above into a runnable
test-case for
You don't need further test-cases for this problem.
Pay close attention to the exact spacing you want to have.
As discussed in class,
I recommend using single-quotes (
For full credit, your function should call
For example,
given an array with
For full credit, this function should involve a call to
if (strtotime('2015-Feb-05 14:00') <= time() && time() < strtotime('2015-Jun-01 00:00')) { echo "<hr/>"; echo "<h3 id='file1'>", hyperlink("file1"), "</h3>"; echo highlight_file( 'file1', true ); //... repeat(?) for each file in this hw, including this index.php itself. } else { echo "(Source files viewable from 2015-Feb-05 until 2015-Jun-01 only.)"; } |
Before the full listing, have a table of contents:
an unordered list containing items like:
Notes:
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.3
(We'll talk about validating input received from the (external, untrusted) user later.)
1When having a list of more than 2 items, I personally recommend using the Oxford comma (or, see wikipedia) but I will leave it to your preference. ↩
2 You presumably want to check that your file-sources really are visible only after the due-date. To test this, first write the code so that it only even mentions index.php itself, and make sure it turns but that the source file is not publically displayed. Add the other files, and confirm that the source files are still not displayed. Then: temporarily change the date to 2013 (instead of 2015) and verify that the source-files display; then immediately change the date back and re-verify that they are not being displayed. ↩
3 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. } |
home—lects—hws
D2L—breeze (snow day)
©2014, Ian Barland, Radford University Last modified 2015.Feb.09 (Mon) |
Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu |