Final ReportWith any project that has many people working on it, inevitably someone becomes out of touch with what is happening. With a webpage, it is too easy for a person to lose track of what is being done to the webpage. In order to allow the different people to see changes that have occured to the webpage, without that person having to search throughout the webpage and try to remember what they saw before, the program I wrote allows individuals working on VRV-ET webpages to ask for information on the pages and recieve information about the changes and updates to those pages. First Thoughts on the ProjectThe first design of the program was straight-forward. It would keep track of the changes made to a webpage (the text, graphics, the order of the webpages) and then show those changs in a tree form with the index at the top and a note that says a change has been made somewhere in the tree below the index, and then you could open the directory more, and see the children (webpages connected to the index) and see the changes of the children. The outline would be linked to the pages, and then the page changes would be shown. A drastic change to the ideaI presented this idea and found a large problem with the idea. First, the webpage was not a webpage in the way I thought. For most webpages, the webpage's information resides in the page. The text can only be chagned when the page is changed. The media may be updated but if the media link is changed, the webpage is chagned. Thus, most of the changes to the webpages are already recorded when the page is saved. In VRV-ET, however, this is not the case. The text is kept in an XML data file. The media is kept in who knows where, and the media album keeps track of where the media is. A separate XML file keeps track of what is in the webpage. The information is scattered. A new SolutionThus the idea of using XML to make a log file of all the changes made to the webpage. The log would be produced by VRV-ET and my program would parse the file and produce reports from the file. The architecture consisted of a webpage calling a servlet which read in a XML file and outputted the report to the browser directly. More Description of the ReportsWith this idea, the work began on the XML file. But another problem arose. Should the reports worry about whether the database had changed, or the webpge itself? The database contains all the information available to a person making a webpage, but the webpage is actually what the person is making. Shoudl the reports report changes to the database, or a presentation? A PrototypeThe decision made was that both types of reports would be useful. So a prototype of a database report would be made. The XML log was made containg any events that would happen to the media album. The report generated six different reports: date filtered, file filtered, date browser, file browser, what is new, and what is modified. Descriptions follow:
Another ArchitectureThe prototype was accepted, but a new architecture for the program would allow quicker reports to be made. The old architecture required the HTML code to be hard-coded into the servlet (java code). Therefore, the new architecture proposed was as follows. The browser would send a request to the servlet. The servlet would parse the XML and send the information in a Java Bean to a JSP page which would output depending on the report selected. This allowed for a better report generator as reports could be added fairly easily. The HTML was in the JSP page and could be changd easily but didn't affect the main code in the servlet. A new XMLThe finally the reports made it to the outline reports. These provided the most trouble. The former XML would not work for the outline. It didn't contain enough information. A page in the outline could be added, deleted, modified in many ways, have its title changed, or it could be moved to a different place in the outline. Also, a page was contained within a section. A secion had no real information but a title and some pages that were in the section. But it too could be moved, or have its title changed, or deleted, etc. Therefore a new XML was made to include old information on the database and new information on the outlines. The log now contained outline data of two types (changes to the outline itself, and chagnes to the pages) and database information. Changes to the pages were defined as text, annotation, or media changes to the pages. They did not affect the outline but were useful information to include with the outline report. The oultine allowed four changes to sections and pages: move, title change, add, and delete. Back EndIn order to keep track of routing information, a complex back end had to be made. The routing information could not be just a URL to the page. Since the page could be moved at any point, and since the movement of another page could affect the other pages in the outline, the routing information had to be flexible. Therefore, each change recorded the section and page spot when that change was made. The outline would consists of lists mainly. The main list is a list of sections. The sections are objects within the LinkedList. The section contains four lists themselves : current pages, deleted pages, changes, and old names. The page objects contain three lists: page changes, outline changes, and old names. Both section and page object contain a String for name. This way routing information can be determined by the page's spot in the outline. All the changes are recorded with date and type of change. Wallah!And the program is finished. It can report changes to the outline as well as to the database. It only has basic reports now, but more complex reports may be added later without many hardships. A tutorial exists for those curious about the interface and actually seeing sample reports. |
Home | Project Summary | Weekly Journal | VRV-ET | DMP | Visit Journal | My Homepage | Jan's Homepage