Labs:

The goal for the lab on 11/20 is to set up a writable directory on the server and use it to store files that contain temporary state information. Also we'll make some changes in the classroom example to verify that you understand how that process works.

• Work individually but feel free to help each other as needed.

• Connect to the server and cd into your public_html directory.

  • Type mkdir statefiles. This will create a directory named statefiles.

  • Type chmod 777 statefiles. This makes the directory readable, writeable, and executable to the world. We need this so we can use perl to create a file inside that directory and then write to it.

  • Do ls -l to verify that statefiles has been created with the correct permissions.

• Download pizza4.cgi and defaultDecodingRoutine.pl, move them to the server and get it working. Remember all the things you have to do to move an executable file to the server. You will also need a writeable order.txt file on the server. It should be empty to start and put it in your cgi-bin directory. Finally you will need to change all instances of /home/jimmy/etc. to /home/yourname/etc. There are only a couple of these so it's not too bad, but note that the more there are the bigger pain this would be.

• Add a new pizza size to the data portion of the code. Note that the new size must appear more than one place in the data. The fact that the code can accept predictable changes in the data is a sign of a good design.

• Change $dataDir, currently set to an empty string to be the full path to your statefiles directory ending in a /. In my case this is /home/jimmy/public_html/statefiles/. In real life we would probably have separate directories for data vs state information but this will do for lab. Your order.txt file should now show up in your statefiles directory.

• Use $datadir to replace all instances of /home/yourname/etc./ Note that if we wanted to change directories again we'd only have to change this one line.

• Finally change the subroutine readState so that it accepts the directory and file to be read as separate parameters. This will allow us to reuse this code with any state file in any directory. Recall that if two parameters are sent they'll be received $_[0] and $_[1].

• Send me the link to your cgi code and attach it to the e-mail as well.

The goal for the lab on 11/6 is to accept forms submitted from a web page and record the data from the form on the server.

• Work individually but feel free to help each other as needed.

• Add two forms to your Dogs example, one that submits data via get and one that submits data via post. You can use exactly the same form twice if you wish. The goal is to make sure both get and post work correctly. The form(s) must have at least two elements, one of which must be a text box.

• Use the boiler plate code discussed in class to read the submitted forms into a hash table.

• Add code that will both

  • Append the results to a text file. This can just be the submitted values on separate lines.

  • Return a web page to the user confirming what was submitted. This page must exhibit understanding of the form names and their values, and it should be more individualized than just printing the name-value pairs. For example, if the textbox's name is dogname and the user submitted Rover then the web page might include something like Your dog's name is Rover. While you can use the example from class for inspiration make yours a little bit different at least.

• Send me the following:

  • The link to your html file so I can submit the forms and see what comes back.

  • The link to your text file so I can see the data accumulate in it.

  • The perl code as an attachment.

The goals for the lab on 10/28 are to learn how to write to files and to learn how functions work in perl. That combination will allow us to develop a hit counter.

• Work individually but feel free to help each other as needed.

• Write perl code that could be used in your Dogs example as a hit counter. You'll need both a hits.pl and a hits.txt file for this. Both should be in your cgi-bin directory (or some subdirectory).

  • Start with hits.txt containing just the number 0.

  • In hits.pl, write a subroutine named getCurrentHits that will read that file and return its contents.

  • Write another subroutine named writeCurrentHits that takes a parameter and writes that parameter's value to hits.txt. Note that we want to overwrite whatever was in the file before.

  • Your "main" program should look something like this:

    • $hits = &getCurrentHits;
      $hits++;
      writeCurrentHits($hits);
      print $hits;

  • Test your perl code to be sure that it works.

• Send me the link to your perl code and also attach it to the message.

• That's it for the basic lab. For the HW I'll be adding the requirement of a hit counter in your volleyball code. Continue if you want some practice that'll prepare your for that and for some extra credit as well.

• For a small amount of extra credit, include the hit counter as a SSI in your dogs code. Recall that this requires a number of extra steps.

  • Your perl code must have the two lines of boilerplate at the top and must be executable on the server.

  • You need to transfer it to the server with the ASCII button pressed.

  • Your html code must either have the .shtml extension or be executable on the server.

  • You will also need to make hits.txt writable by the world. The most reliable way to do this is to use chmod 666 hits.txt.

• Send me the links to both your html and perl code and attach the perl code as well.

The goal for the lab on 10/21 is to learn how arrays work in perl.

• Work individually but feel free to help each other as needed.

• Write a perl program, call it array.pl, that accomplishes the following.

  • Read a data file (it could be your dogs.txt file from before), that has data spread over separate lines, into an array. Then output the array in reverse order. Do the output two different ways: Once using a normal for loop and once using the combination of foreach and reverse.

  • For example if the input looks like:

    • Rover
      Lassie
      Hershey

  • Then the output should appear twice and look like

    • Hershey
      Lassie
      Rover

  • Be sure to write the code so that you wouldn't have to change it if you added a fourth dog to the file.

• Attach the perl file and send it as e-mail. Also send me the link (this just lets me know where it is on the server so I can go run it if I need to).

The goals for the lab on 10/9 are to learn more about Perl, particularly wrt if statements, while statements and reading from files.

• Work individually but feel free to help each other as needed.

• Write a perl program, call it ifandwhile.pl, that accomplishes all of the following.

  • Includes a loop that takes input from the user. All the negative numbers will be added up into one sum. All the positive numbers in another. Inputting 0 will terminate the loop. Once the loop terminates, print both sums. Example: the user inputs 5, -3, -2, 4, 3, 0 all on separate lines. The output should be something like

    • The sum of the positive numbers is 12.

    • The sum of the negative numbers is -5.

  • Take your dog (cat, professor, whatever) data from earlier labs and put it in a text file as shown in class. In particular the data from each dog should be on a different line. Read the file and build a string that consists of each line of the file separated by "|". Print the string.

• Attach the perl file and send it as e-mail. Also send me the link (this just lets me know where it is on the server so I can go run it if I need to).

• If you want to work ahead the next lab will be to write the string obtained above to your dogs.html file as a server side include. This will allow us to update the dog data just by changing an entry in the data file. Your next HW will include accomplishing the same task for the volleyball player data.

The goals for the lab on 10/7 are to learn more about Perl, particularly how scalar variables and interpolation work, and to learn a little about how SSI's (server side includes) work.

• Work individually but feel free to help each other as needed.

• Write a perl program, call it add3.pl, that both

  • Takes three numbers as input, adds them up and prints the sum.

  • Takes a string as input, splits it up into three substrings, and outputs the result. You decide what the separator should be.

• Note that we can't serve the above program up in a browser as getting input from the user would be very different in that case. This means you don't need the two lines of boilerplate at the top.

• Load it onto the server to test it. As noted in class it's best to use perl -w add3.pl to test

• Outside of lab, make a copy and play around with that code as much as you like, to get a better feel for how things work in perl.

• The rest of this lab is our first example of a server side include.

• Create a perl file that just prints something without any input. You could use your simplehello.pl file from last time if it's working now. If you go with a new file, the usual rules about moving it to the server apply: Transfer it in ASCII mode, put it in the cgi-bin directory, make it executable, include the two lines of boilerplate at the top. Keep this really simple. Just one print line in addition to the boilerplate.

• Create both an shtml file and an html file that includes the above perl file as shown in class. Move these to your pub_html directory. You decide whether to use the file or virtual approach. Note that the shtml file shows the output of the perl code right away. Before the html file will work you will need to make it executable. You do this the same way as with perl files. Change into the correct directory and use chmod +x yourfilename.html.

• Note: If the server were set up to check every html file for server side includes before serving them up, it would slow things down substantially. We have ours set up to check all shtml files and executable html files for such includes. This approach is pretty standard on Apache servers.

• Send me links to the add3.pl file, to your html file, and to your shtml file. Also attach all three of those files to the e-mail. (I'm not sure yet whether it'll be easier for me to look at this kind of code through e-mail or directly on the server, so we'll use this lab to check that out).

The goals for the lab on 10/2 are to learn a little bit about Perl, make sure your account on the INFD server is working properly with respect to Perl, and get a taste of how cgi programming works, both in general and with Perl.

• Work individually but help each other out as much as you like.

• Create a file named simplehello.pl and have it print one line as in class.

• Move it to the server. Perl code will run just about anywhere on the server, but later we'll want to use it in web pages. To facilitate the latter do two things as you transfer the file:

  • Push the button labeled ASCII before you transfer the file.

  • Move the file into the cgi-bin directory in your account.

• You accomplished the above by using Secure Shell File Transfer. Bring up a plain old Secure Shell.

• Change into your cgi-bin directory as shown in class. cd pu* followed by cd cg* should do it.

• Type perl simplehello.pl. Your one line should print out. Any problems, let me know.

• Type chmod +x simplehello.pl to tell the server the file contains executable code.

• To tell the server to actually run the perl code in a browser instead of just displaying it we need two lines at the top of the file. Copy these lines from the handout into your simplehello.pl file.

• Transfer it to the server. Be sure the ASCII button is still pressed. Be sure to move it into the cgi-bin directory. You shouldn't have to chmod again since you're replacing the file, not making a new one. Further experimentation shows this is spotty. So chmod again if you need to.

• Run it using perl as you did before and serve it up in a browser. Check the source code through the browser. This is the acid test that your server account is set up correctly so let me see the results.

•  Download hello.pl.

• Move it to the server as you did the earlier file. Make sure the ASCII button is still pressed, move it to the cgi-bin directory, and change its mode.

• Run it using perl hello.pl and serve it up in a browser. Check the source code through the browser. This is just for more practice.

• Modify hello.pl to use the print <<HELLO technique discussed in class, then make some changes to the html code. Move the new file to the server.

• Again check that it works via perl and through a browser. Send me the link.

The goal for the lab on 9/24 is to apply the string manipulation techniques to the Dogs example. This will better set the stage for reading a string sent from the server to be decoded by javascript on the client side.

• Same partners, just submit one version at the end.

• Start with your dog  code as one of you had it last time.

• Put a string on the html page that represents your three or more dogs (cats, college profs, whatever). Something like: Rover;Arf;rover.jpg|Lassie;Timmie;lassie.jpg| etc. should work for this.

• Read the string into a javascript variable, split it up into parts and use it to build the array of dog objects.

• Note that the concepts here are the same as the lab from last time except that we use the individual bits of information to build Dog objects instead of writing them to the screen.

The goal for the lab on 9/22 is to explore some of javascript's string manipulation capabilities. We'll use them to read a compound string off the page and break it into its component parts.

• New partners, just submit one version at the end. Allen & Lewis, Bowen & Hutcherson, Cody & Lanham, Finley & Mincey, Ramey & Robbins, Greene solo, Phifer & Grant, Dukes?

• Start with an empty template.js. In this case put any string on the html page that has at least 3 parts divided by vertical lines (you could change the delimiter if you wish), and whose parts in turn are further subdivided into at least 3 substrings separated by a delimiter of your choosing (as long as its different from the first one). Break the large string into its substrings and print them out on the page. After each of the substrings, print its parts on separate lines.

  • Sample input: Mary had a little lamb.|Its fleece was white as snow.|Everywhere that Mary went|The lamb was sure to go.

  • Output, split first on vertical lines, then on spaces:

    • Mary had a little lamb.

    • Mary

    • had

    • a

    • little

    • lamb.

    • Ditto for the other parts.

The goal for the lab on 9/18 is to build on the previous lab to illustrate how the onmouseover event can be used with a javascript array of objects to change an image. You'll need to keep the list of dog names from before, but you don't have to keep the barking functionality if you don't want to. I'm really only interested in the pictures for today.

• Same partners as last time.

• A reasonable place to start is with your code from last time. I believe everyone successfully completed that lab.

• Use the class discussion to add an image to each dog in your array of dog objects. These don't actually have to be pictures of dogs. We just need a different picture for each element of the array.

• Put an html image element on the screen. It can start off either blank or with any image you want.

• When the user hovers over the name of a dog the image on the screen should change to the one for that dog.

• Post the result on the INFD server. Send me one message from the team telling me where it is.

• The rest of the lab has to do with your individual accounts on the INFD server, so I need each of you to do this. You can help each other, but I'll need two responses at the end.

• Add an index.html file to your public_html directory. This can be anything you want except it can't be your volleyball page or have any reference to your volleyball pages. This is to keep people from being able to navigate through all the directories on your web site, and in particular to look at the code for your volleyball site.

• Move your volleyball pages into some subdirectory of your public_html file. Make the name of this directory something that's not easy to guess. Not your name, not volleyball, not eagle digs. Again this is to make it hard for others to track down and look at your code.

• Change the title of your volleyball site to anything except Eagle Digs. The reason for this is that once the official site goes public we want search engines to find it, not your individual, experimental versions of the site. Send me the link to your new site.

The goal for the lab on 9/16 is to build on the previous lab to illustrate how the onmouseover event can be used with a javascript array of objects.

• Same partners as last time.

• A reasonable place to start is with your code from last time. I believe everyone who was there successfully completed the lab or came very close. If not, you can start from  templatejs.html.

• Use one of the two methods shown in class to get your dog (or cat or whatever) from last time to make its sound when the mouse is hovering over its name. Don't just use an alert as shown in class; have some other element on the page change instead.

• Post the result on the INFD server. Send me one message from the team telling me where it is.

• Write an e-mail message to your volleyball team partner. You should introduce yourself, explain what we're planning to do, and generally be charming. Suggest a plan for further communication. CC me on the note.

The goal for the lab on 9/11 is to get a web page on the INFD server that shows the construction and use of javascript objects.

• A reasonable place to start is again to download and rename templatejs.html.

• Your page should have a section that will display a collection of dogs and the sounds they make. (Actually there's nothing special about dogs; you could use cats or some other animal if you prefer, but I'll assume dogs in the discussion below.)

• The HTML code should have a header saying something like Here are a bunch of dogs and the sounds they might make. Then there should be an empty element where the javascript code will place the dogs' names and sounds.

• The javascript code should initialize an array of Dog objects. There should be at least three dogs in the array, each with its own name and sound.

• There should be a loop that prints the dog information, one line per dog, to the page. For example the first line might read Rover says ARF! Use the length feature of Array objects so that you don't have to change the loop every time you add or remove a dog.

• Once it's working, I recommend you move it to both of your accounts on the INFD server so you're both sure to have the code, but I only need you to send me one of the links.

The goal for the lab on 9/2 is to get a web page on the INFD server that exhibits some javascript code. It would be natural for you to use the volleyball page you're working on for HW to accomplish this, but any page that meets the below requirements will do.

• To get started download templatejs.html. This code reminds you how to include javascript code in an HTML file in a way that will still certify as standard, and shows how to reference an external javascript file. Copy and paste what you need from this file to get started.

• Your page should have a section that will display one of at least two pictures. Write javascript code that will randomly choose the picture that is displayed when the page loads.

• You can test this code to your heart's content on any machine. Once it's working, move it to both your accounts on the INFD server and send me the links. Again, send me both links, even if the code is identical.

• Note that once we get to serious server side programming you won't be able to test your code on our lab machines. You'll need to move your work to the server each time you make a change, but for now life is a bit easier.

The goal of the lab on 8/28 is to get a web page onto the INFD server that is divided into sections using the HTML div element and that uses an external style sheet to control those elements. My recommendation is that you do this with your volleyball page that you're working on for the homework assignment, but any new page will do (e.g. you can't just point me to your Hangman project from last term or any other page you've done in the past). There should be at least three div elements. Use the style sheet to arrange these on the page. And there should be

• A tag-selector: a style based on an html tag. E.g. give all paragraphs a particular style.

• A class-selector: a style based on a class you invent. One possibility here would be a player class, but that's just an example.

• An id-selector: a style based on ids. This would be the natural way to arrange the divs.

• A pseudoclass selector specifically for hovering over links. Last semester we changed the size, but that may be a little too obtrusive. I'd recommend a change in color or font, but you get to choose. Include at least one link on the page to test this.

These styles can be very simple for the lab. I just want to be sure you can still do them. For the hw assignment I'll look for a little more creativity.

When you've finished, move your files to the INFD server and e-mail me the link to the html document. Note that all labs and all hw should include the boilerplate at the top that specifies the most rigorous standard will be met, and should include the icons/links at the bottom that allow that claim to be easily checked.

The goal of the first lab (8/26) is to put an HTML page up on the INFD server. A secondary goal is for me to collect some updated info about you. So....

• Please send me e-mail (mckimj@winthrop.edu) that includes your

• Name as you'd like me to address you.

• Specialty within INFD.

• How you spent your summer vacation. 

• Interests. Tell me something that will help me get to know you better. I'm especially interested in any extra curricular activities at Winthrop.

• The e-mail should also include the link to the web page you create on the INFD server. See below.

• See above for teammates. One person should be the driver and do all the typing on the official version, the other should kibitz. This is pair programming and while it can occasionally be frustrating for the kibitzer, studies show that it is a very productive way to both learn and produce software. At the end you should both have web pages on the INFD server. It could be the same page on both sites, or you can individualize a little. You should drive when getting the page to your site. You should kibitz when your partner is trying to do likewise.

• Make a directory on your Z drive for all the work you do for this class. You can call it anything you want, but I recommend csci241. You may wish to make a subdirectory for each separate assignment, but I'll leave that to you.

• Download template.html into your csci241 directory (or subdirectory) on your z drive. Note: Just save it at this point. If you open it first the system assigns a different name to it and you may get confused later.

• If you double click on the file, it should pop up in Internet Explorer. You can use Mozilla if you prefer. Last semester we found Mozilla provided more support for finding errors than IE. We will endeavor to write code that works in both these as well as all other common browsers.

• All you should see at this point are the icons that point you to w3.org's validation pages.

• To edit the code, right click on the icon and select "open with" Expression Web. You may have to browse a bit to find Expression Web.

• Click the Code button in the bottom left of the screen to be sure you're in Code mode. We will always work in Code mode in this course. (If you work in Design mode, Expression Web will add all kinds of ugly code to your page and we'll quickly lose control (and you'll lose points when I see that ugly code in your work).

• You should now have Expression Web up showing the code for template.html and a browser up showing the presentation of that code.

• Change the name of the file to volleyball.html. Then make some minor changes to the code itself. Change the title of the page and add something in the body. Save your change and refresh the page in your browser. You've now tested your page and it's ready for publication.

• Now upload your file to the INFD server:

  • Click on SSH, on your desktop. There should be two, either will work. (Note: I've just discovered it won't be so easy this first day. I'll show you how to find the executable today in lab. We just have to burrow into the file system a bit.)

  • Click on "quick connect".

  • The name of the server is infd.birdnest.org and your user name is the same as for your main Winthrop account. Your current password is csci241. You are connecting to a Linux (not Windows) machine and Linux is particularly case sensitive so be sure everything is in lower case. (Note there could also be first day glitches here. In theory everyone should have an account on the INFD machine accessible in this way. Let me know if there are problems.

  •  If necessary, click on 'file transfer'.

  • On the left hand side you should see the local machine, on the right you should see your account on the INFD server. Drag and drop volleyball.html into the public_html directory on the server.

  • To bring that page up in a browser, use http://infd.birdnest.org/~youraccountname/volleyball.html

  • Don't forget the ~. It's crucial when talking to Linux/Unix machines.

• Check that the code still validates. Always check validation before handing in your code. If it doesn't validate, fix it on your z drive then transfer the file to the infd server.

Homework Assignments:

Assignment #5. Due midnight 12/8.

1. Include at least two elements on your Get Well form. Do a client side check that both parts of the form have been properly filled out. You get to decide what "properly" means as long as both parts of the form are checked. If there's a problem present an appropriate error message to the user. If all is well, submit to the server side.

2. On the server side, show the information provided by the user and offer them the choice of confirming it or returning to the previous page to change their submission. If they confirm then go ahead and submit to the server again. Note that this step will require maintaining state in some way. You get to choose how you do this.

3. On the third page, thank them for their submission, append their submission to a file and offer them the opportunity to view all the submissions to the file so far.

4. As always, meeting the bare requirements nets you a middle B. You need some extras either in substance or style to raise your grade beyond that. E.g. js code in a separate file, additional form elements in the get well card, adding some style to the confirmation pages, etc.

5. E-mail me the link to your site, but also attach your perl code.

Extra credit opportunities (these are due midnight 12/10):

1. Put an image element on the main page. Rotate a variety of team images through this element, based on a timer.

2. Do some research to add appropriate links to the main page. Possibilities include the Big South volleyball pages, winthropfans.com, volleytalk, Rich Kerns.

3. Add a link to the picture in the player's section. This link could just take you to that player's personal page, but you might be able to come up with something more imaginative.

4. Design a place for a schedule as part of your site. Each entry in the schedule should include the date, time, opponent and venue (home or away) for the game. Read the schedule from a file in order to display it. The file needs to be set up in such a way that it is easy for a nontechnical person to go in and change the schedule.

5. I'm interested in anything you think of doing, but you should talk to me first before trying something not on this list.

Assignment #4. Due midnight 11/11.

1. Move your players' data from the HTML page where it currently resides to a text file on the server. Put each player's info on a separate line. Write perl code to read that file into one large string. Then use an SSI (server side include) to include that string (invisibly) in your main volleyball html page. If you do this right the perl code should write a string that looks just like the string you had to type in for the previous assignment. Your js code should then pick that up, and all should work as it does now.

2. As discussed in class, the reason for setting the code up this way is so that a nontechnical content expert can update the web page, by changing one data file. This technique and others like it are the common ways that web sites keep their data current.

3. Add a hit counter to your volleyball page. It's up to you to find a suitable place on the page for the counter to go. Generally speaking, these should be subtle and be towards the bottom of the page.

4. Kellie Sellers recently underwent surgery for a knee injury. Include a form on your volleyball page that allows fans to offer her best wishes for recovery - a get well card of sorts. The actual form should be submitted using the "put" method, but the underlying code should work regardless of whether "get" or "put" is used. As the forms are submitted append the get well messages to a file. The idea is that the file will grow as more messages come in. Spend some time thinking about how the file needs to be set up. In particular it needs to be clear where one message ends and the next begins.

5. Once a form is submitted, there needs to be some acknowledgement of that fact. This can be done with a Perl generated web page that just says something like "Thanks for your good wishes, we'll pass them on to Kellie". That's the basic requirement, I'm hoping you'll do a little better than that.

6. As usual, meeting the basic requirements nets you a middle B. You have a lot of leeway wrt how the hit counter is set up, how the form is set up, the format of the "get well Kellie" file, and the acknowledgement. I'll be looking at how well you accomplish those tasks when it comes to adding points to your base grade.

7. I don't think we need to have presentations of these assignments, so don't worry about that.

8. Send me the link to your page and attach the perl code to the message.

Assignment #3. Presentations in class on 10/14. You can do some fixing up after that. E-mail me the links to the code on the INFD server by midnight that night. Also send the link to hamus14@yahoo.com. That's Steve Polhamus, our volleyball liaison. He gets the final say on whether your individual player page is ready for prime time.

1. Fix any problems from last time. This includes any css issues that are causing significant differences in viewing through IE and other browsers. Come see me for help on this or any other issue if you need to, but also remember that most of y'all solved similar problems successfully last year in your Hangman code. All the final hangman code that was submitted to me is here so you can investigate how you and others solved such css problems before.

2. Add at least two attributes to the Player object. One of these should be displayed when the picture of the player is displayed. The second should be a URL for the player. For your player this should be the address of the page you've written. For the other players you can use the profiles on the athletic web site.

3. Clicking on the player should now take the user to the URL discussed above. Do this by adding to the javascript code that writes out the list of players. You can do it with anchors, you can do it by listening for the onclick event, or you may come up with another way. Anything that works and looks good is fine.

4. Instead of typing all the player info into the javascript code as you build the Player's array, read this information from a long string on the html page. This is similar to what we did in the last Dogs lab. In the next HW assignment we'll use a server side include to put this string on the page, but for now you'll have to type it yourself.

5. Finish up your individual player's page. In the top left corner of the page display at least two links. One back to the main Eagle Digs page and one to the player's profile on the official athletic site. At the bottom of the page, mention your name as the author. How exactly you do this is up to you.

6. Include at least two pictures on the page that are different from the headshot we're already displaying. Ideally, one of these would be the player in action on a volleyball court and the other would be a more personal shot. If you can't get the latter, use two action shots. Remember there are lots of action shots available here.

6. More pictures are probably better. Remember that the above are the minimal requirements. Doing a good job meeting these gets you a middle B.

7. Coding notes: All the code you write for this course needs to be written by you. In particular, you should not be using Expression Web or any other tool to generate html or css code.

Assignment #2. This is now the full assignment, due midnight Thursday, 9/25, with presentations on the following Tuesday, 9/30.

The first part of the assignment deals with the javascript code. Create a Player object and give it at least two attributes: a name and a headshot image. That second attribute should really be the image, not the file name or url. Modify your array of Images from the first assignment to be an array of Players. Use it so that whenever the headshot of a player is shown on the screen, it is accompanied by the player's name as a caption.

Somewhere on your site you should still have a players' section that when loaded shows one randomly selected player image and name. In that same section you should have a list of player names. Moving the mouse over the name should change the image and caption to that player's image and name. For the moment clicking on the name could link to the player's official profile on the athletic site, but as you know we hope to replace these with our own specialized pages.

From a coding point of view we want to set this up so that we only type a player's information (for now just the name and image info, but later perhaps much more) once. Then anytime we want to access any bit of player info we should be able to pull it out of the Player array. Then if a new player is added or an existing player needs to be deleted we need only change the Player array. Later we'll set it up so that the Player array itself is built automagically from some server side file or database, but for now we'll just type the info we need as part of the javascript file. But we'll just type it once.

For the second part of the assignment we now have a go from the volleyball staff in that they have agreed the players will feed us appropriate personal (but not too personal) information so that we may put up an individualized web site for each one. We'll assign student-player partnerships tomorrow (9/16) in class. I want to leave this part of the assignment as open ended as possible as I'm really looking for you and your player to be creative as possible. Nevertheless, several notes:

• I've assured the coaching staff that you will send e-mail to your player within the next couple of days to get things rolling. From there on it's up to you and your player to figure out how to communicate. The two of you may decide that you'll meet face to face; you may decide that you'll put together a questionnaire and e-mail it to her; you may decide to have one or more phone conversations. It's up to the two of you.

• Student-athletes are extremely busy, especially in-season as volleyball is now. You must therefore understand that you need to make very efficient use of whatever time the player can give you. They will be asked to provide a minimum of half an hour to you. (Given my experience with volleyball players in the past, most will be willing to do much more than that, but you need to plan as though a half hour is all you'll get.) Whether that's spent in one lump or spread over a few e-mails, text messages, etc. is up to the two of you.

• Every page should have a link back to your main Eagle Digs page.

• While the idea is to have a personalized page, we don't want to encourage stalkers, so no personal contact information on the page. No e-mail address, no phone numbers, definitely no street address, nothing along those lines.

As always, grades will be assigned numerically, but will be in the B range if you meet the basics of the assignment, in the A range for going beyond the basics, planning for the future, trying some things out, attractive look and feel, and in the C range or below if the product falls short of expectations.

Assignment #1, due midnight Thursday, 9/4. Each team should select one member to present their site the following Tuesday (9/9). Five minutes should be sufficient.

    Design and implement a layout for a home page for a Winthrop volleyball fan website that includes all the following elements:

1. A welcome area.

2. A set of links to general volleyball pages, including sites on history, rules, and terminology. Include at least three well chosen links.

3. A news area. This should be the showcase of the main page. The volleyball staff will be feeding us news bulletins throughout the Fall and we'll add them here.

4. A section for the players. This should include a list of the players' names, with links to their pictures. You can download pictures of most of the players from the official volleyball site. Click on roster and then click on the player. The freshmen may not have pictures yet, but the others should.

5. In or near the players' section, show an image of a player. The player should be randomly chosen at first. Once the page is loaded let the user decide which player is displayed by clicking on her name.

In terms of coding elements:

1. For now, you can do this in just one page. In the future we may want a very simple welcoming page with links to news, players, related links, etc. But for now one page is good.

2. Write an external CSS file. There should be separate styles for each of the main sections of the page: Welcome, External links, News, and Players. Use the HTML div element to divide the page into sections.

3. We will need some javascript code to deal with the player/picture combinations. In particular store all the pictures of the players in an array as we did with our hangman images. When you list each player name do so in an HTML element that listens for an onclick event. When the event occurs pass the number of the image you want displayed to the event handler. For example, if Shannon Sitzmann's image is the 0th element of the array, then in the html element for her name you would include something like onclick = displayImage(0). Then write the displayImage code so that it displays the image whose number is passed to it.

Grading: As always, all code should be clearly written with good choices for names of styles and variables. Indenting should be used to set off nested elements. Javascript code should be well documented. A good rule of thumb is a comment on each routine and on each major control structure. Figure on a C if most of the requirements are met, a B if all are met in a minimal fashion, and an A if all requirements are met, but with additional creativity, planning for the future, and generally going beyond the minimum. Grades on assignments will normally be numerical, the above are just general guidelines. I hope there won't be many, if any, grades below C's, but obviously these go to projects that meet relatively few requirements and/or are late. One member of the team will present your assignment the class day after it's due. I'm not looking for anything deep here. This is what we did. This is how we did it. Here's a problem we ran into and solved. Any questions. These will be worth a small part of each assignment. I fully expect you'll get full credit for the presentation just about every time. I will keep track to make sure that each student makes their share of presentations.

Notes: These are notes from various class meetings.

8/26:

This semester's project: We have been asked to develop a fan site for the Winthrop volleyball team. We'll start with client side work: HTML, CSS, Javascript. This will serve as a review of last term's work, but also allow us to explore some more advanced features of these languages, particularly Javascript. We'll then move to the server side, eventually setting up a database of fans, so we can greet each by name, keep track of their favorite players, etc.

On working with a partner:

Strict paired programming calls for one person to do all the typing whilst the other kibitzes (that is, makes suggestions, catches typos, etc.) This technique is becoming widely used for software development in both education and industry, because it has been found to enhance learning in the former and to reduce bugs in the latter. Early on in this course, you may wish to work in just this way, but it means that your and your partner's code will be exactly alike. Later on, particularly as we change partners, you will likely want your project to have your own style, so you'll want your product to differ from your partner's. At that point, in lab, I expect you to work on one person's version first, then switch to the other's. Both of you are responsible for making sure both versions work.

No sharing of code with anyone except your partner. Get help from your partner, from me, from passive sources such as your text, tutorials on the internet, etc.

Implicit in every assignment is that you work hard with your partner. If you're the stronger person on a team I expect that you explain as you go, solicit suggestions from your partner, and so on. If you're the weaker person on the team I expect you to demand such explanations and work hard to contribute. Every time we switch partners I will ask you to evaluate your previous partner, so I will get a pretty good idea of who's behaving appropriately and who's not. Note that these evaluations will not affect either your or your partner's grades. You are required to do them, but I will use them only to have a heart to heart with anyone who is consistently receiving problematic evaluations.