CS 242 Fall 2011 : Assignment 3.1 | charlie on software

CS 242 Fall 2011 : Assignment 3.1

This page last changed on Oct 10, 2011 by cemeyer2.

Assignment 3.1 – Creating a Portfolio


Code Complete Chapters 10 and 11: General Issues in Using Variables; The Power of Variable Names


W3Schools.com XML Tutorial


This is the first week of a multi-week assignment where you will be building a portfolio to show off all of the code that you have written over the course of the the semester. We will start this will with basic PHP and XML, and move on to other web technologies such as JavaScript, HTML, XSL, and SQL in future weeks.

This assignment is due at 10:00 AM CST on Thursday, October 13th, 2011 in a folder in SVN called Assignment3.1.

Don’t fall behind

This is the first week of a multi-week assignment and the output you generate this week is the input for next week’s assignment. If you fall behind this week, you will not be able to work on next week’s assignment until this week is complete. That also means that even if you have an excused absence from section for this week, you still are expected to have a working version of this assignment so you can proceed with next week’s assignment.

Getting Started

For this assignment, you should work with your cpanel account. Each of you should have accounts by now. If you do not have access, please email the course staff ASAP. Instructions on what services are available as well as how to access them are located at https://wiki.engr.illinois.edu/display/engineeringit/Web+Hosting+for+Student+Projects. We will only be using the basic PHP functions this week, but in future weeks we will use more.

Using your own environment

You are more than welcome to use your own Apache/PHP environment to develop this assignment, but in the end, it must run on the university cpanel server. So, feel free to develop elsewhere, but test and deploy on your cpanel account. This is to ensure that there are no issues that arise from technical difficulties when we are trying to evaluate your work each week.

Your task for this week is to take a raw XML file representing your work so far this semester and transform it into a nicely formatted XML document that we will transform to HTML next week.

You are free to design the look of your own portfolio however you like. We will use XSLT next week to generate the actual HTML to display. However, XSLT is not good for making large changes in structure – with XSLT, the generated HTML largely follows the structure of the XML. This week, you need to take the XML from subversion and convert it to an XML structure that better represents how you want the portfolio to look. So you need to think about the layout you want and choose the XML structure based on that. We give an example below. (In future weeks, we will have you add a commenting feature, so in designing your layout you should keep that in mind, even though it won’t be included just yet.)

Getting the raw data

You will need to get access to a machine that has the svn command line program on it. The EWS linux machines have it already installed. To get the raw data, enter the following command:

This will save the log and listing of your repository into a file called “svn_log.xml” and “svn_list”. You will need to transfer these files to somewhere readable on your cpanel account. See the svn log documentation or run the command svn help log to get more details on the svn log command. See similar pages for svn list help.

The format of the file is something like:

SVN log output:

SVN list output:

Your job for this week is to read in that data, parse it with the PHP XML parser that you customize, then output it as a new XML file. It is up to you to determine the format of the new XML file, but here is one suggestion:

Here is a brief description of this particular XML output. You are free to come up with whatever output you wish, but it must have all of the basic information we have here.

  • The title is the title of each of your projects
  • The date is the most recent date of commit for that project
  • The version starts at 1.0 for the first commit, and increments by 0.1 for each additional commit to that project
  • The summary is the most recent commit message for that assignment
  • The size is the size of the file, as reported by the list output
  • The doctype is one of code, test, image, documentation, etc (feel free to add as many doctypes as you wish). This will be parsed based on file extension and location in the repository.
  • The path is the path to your files in SVN. This can be relative or absolute
  • The versions tag contains all of the revisions to that particular file. There is one version tag per version of each file
    • The number is the revision number for that commit
    • The author is the netid of the committer
    • the info is the commit message for that revision
    • The date is the date of that commit

You need to parse the raw data and transform it into this type of format. You will need to account for the differences in the file structures and write your code accordingly. It is up to you to decide from which of the two input files you want to take each of the pieces of data from (there is some overlap). Feel free to go above and beyond and add more information from the input files into your output. We are transforming these two input XML documents into one in order to provide an easier input into next week’s assignment where we will be displaying the results graphically using an XSLT transform.

How to do it

We want you to write in an Object-Oriented fashion this week. That is, you should have classes representing all of your basic data objects (one for a project, one for a revision, one for a file, etc), one for your parser, one for your output engine, etc. You can use the built-in XML processor that PHP provides as the basis for your parser project. Here is an example of the constructor and a parse function for an object that parses one XML (yours will need to parse two XML files):

We then create functions named tag_open, tag_close, and cdata which the parser calls on each part of the document tree as it parses. For instance:

We ask you to encapsulate your parser in an object because it will need to maintain state as it parses and builds up a data structure.

Once you have the data structure built up in memory, you will need to output the xml back to the user. You should look up the PHP documentation for DOMDocument. Build on a DOMDocument object from your data structure and then call ->saveXML() on it to produce nice results. You can echo this text back to the user.

Your main PHP file that the user loads up in their browser to get the formatted XML back might be something like:

Why use PHP?

We realize you could easily use another language for this assignment, maybe the same one you used for assignments 2.X, but in order to form one cohesive software portfolio for this assignment, we want you to do it all in PHP. In future weeks, we will be adding some graphical style as well as other dynamic features to the portfolio and they will all be implemented with a variety of technologies, but glued together with PHP. If you were to do this in a language other than PHP this week, every time you wanted to update your portfolio you would have to run your other language XML processor, then manually feed that into the rest of the portfolio project. By using only PHP from the start, when you update your portfolio in future weeks, all you will have to do is upload new XML files dumped from SVN.


This assignment is particularly tricky to test using unit tests, so for this week we encourage you to write more integration style tests. You should be able to construct several small input XML files by hand and verify that your code produces the proper data structure in memory, then outputs the proper converted XML back to the user. You should test for all possible corner cases you can think of, such as:

  • multiple revisions for a file
  • multiple revisions for multiple files
  • files in conflicted SVN states
  • files that were SVN merged
  • files that were deleted
  • etc…


Criteria Weight Comment
Basic preparation 1  
Cleverness 1  
Code submission 4 submitted on time and to the correct location
Decomposition 4  
Documentation 2  
Effort 1  
Naming 2  
Overall design 3  
Participation 3 How you critique others code.
Presentation 2 How you critique your code.
Requirements – Parsing 5 Proper use of parser and proper OO approach
Requirements – XML output 3  
Testing 3  
Document generated by Confluence on Feb 22, 2012 18:09

  1. No comments yet.

  1. No trackbacks yet.