View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

milestone 4 (Web Interface)


What we're discussing:

  • A discussion of the Web UI
  • Generating the resulting web page
  • Our use of the PWS





    A Look at the User Interface
    This is the basic layout for our Newspaper web interface. We decided to go with the selection boxes versus check boxes because they seem much more intuitive in selecting lists of items.

    Sections are lined up by priority, starting at the top and working its way down from left to right. In this way, the user is encouraged to start by selected their primary news category, and then go on from their (to source, then source topics). After the user has made a selection anywhere on the page, he must signify that he has made a change by clicking on the appropriate submit form box underneath the menu items. This is not the most intuitive method for selecting, but due to javascript limitations in this project, there was not another choice. However, to keep the interface understandable by even novice web users, there are descriptions on the graphics associated with each section of the UI, explaining what the section is, and what they're supposed to do to.

    Clicking on the form submit buttons will send a request (discussed in further detail below) to our back end, and cause Squeak to send out a new page with the modifications reflected on it.

    Probably the nicest feature of the Web Interface is the "Selected Source Topics" selection box, which shows the user everything that is currently selected for their newspaper, and the ability to remove any source topics they currently have selected. Not as intuitive is the fact that if the user doesn't selected anything, the newspaper will still generate a story pulling from a set list of source topics. We couldn't really find a good way around this.

    Lastly, at the very bottom of the page, the user can click the "Generate Newspaper" button when they have finalized all their selections and are ready to receive their customized newspaper.

    The result of this brings the user to a new web page, which contains all the stories, headlines and graphics for their specified articles.

    pros:
  • Clean, well layed-out design
  • Unintrusive directions embedded into the UI.
    cons:
  • inability to select multiple selections (using [Ctrl]+selection)
  • must click on specific submit button every time a change occurs




    Web page generation



    When the user opts to generate the newspaper, all of the choices that were made are collected and put into a list that includes each source, and each source will know its selected topics. This list is handed over to the publisher. The publisher has an editor on hand, and will now tell the editor that these are the selections. It will ask the editor to collect some stories and put them into HTML format. The editor knows its correspondents, and will tell each of them to gather stories that relate to the topics that the user has selected. These stories consist of a headline, a location, an image, and a list of paragraphs. Once all the stories from all the sources have been assembled, the editor will go through these stories and format them as HTML. This means that the editor will have to take each story, put HTML tags into it, and store this information as a string. The editor makes a string representing all of the stories in HTML format, and returns this string to the publisher. The publisher will put this string onto a form that will properly display the newspaper.






  • Our Use of the Pluggable Web Server

    Modularity and Re-Use
    Fortunatly for Team Fox Force Five, the previous milestones had been built on a foundation of modularity. Most noteably, use of the MVC paradigm had separated the view from the model allowing a the new web-based view to be added with minimal modification to the core newspaper classes.

    Embedded Code vs. Servelet
    From the get-go it was pretty obvious that the page would need to contain a large amount of dynamic information, including the primary news categories, the sources and the topics. Of course one option would have been to hard code in the information, and thus only have to deal with a statically defined html page. But that would preclude us from having a robust web interface. So dynamic it was.

    As far as we could tell we had two alternatives for a dynamically-contented webpage: 1) embedded code 2) a servlet. Embedded code seemed like a good solution at first; All we had to do was build the HTML, throw some code in there, and voila, we'd be done. But a bunch of issues started creaping up as we further investigated.

    The big road block for embedded code was the issue of how to access the content-providing methods of our Newspaper object. Most examples of embedded code we could find revolved around calling class methods with data that was stored in the request objects. So how were we going to call methods in an instance variable that we had no reference to? Our best solution was to store the newspaper object in some type of global hashtable, and get reference to the newspaper via key-lookup. This approach was deemed too contrived especially when considering how elegant a solution servlets provided.

    The servlet
    What is a servlet? Did we extend something named AbstractServlet? Did we plug blocks of code into a PluggableServlet object where all kinds of esoteric details were hidden from us? Nope. All we did was write a method called "process: aRequest" in our NPWebInterface model, and tadah! our NPWebInterface was our servlet.

    There is a little more to it than that, but not much. You see, once the "process" method was written we registered the NPWebInterface with the PWS (PluggableWebServer). Registering the object involved linking our object with the key "newspaper". So, whenever anybody requests "http://(server_name)/newspaper" processing the request is handed off to our object, the NPWebInterface.

    The method "process: aRequest", takes in a request (duh!). The request is your link to the outside world. Anything that you want to display, you write to the request. So what do we write to the request? Well, there's a whole lot of html that never changes e.g. the images, the basic layout, the buttons – all that stuff is hard coded and gets sent back to the requestee whenever a request is made. But there's also a lot of dynamic information, like the primary news categories, the sources, and the topics – the code for those options is generated on the fly by retrieving information from the model. For instance:
    getTopicOptions
    	| textOut topics |
    	"Generates the code needed to display the possible topics for the selected source as a list of options"
    
    	topics := self listTopics.
    	textOut := ''.
    
    	topics size >= 1 ifTrue: [
    		"select the first element"
    		textOut := textOut, '<option selected>', (topics at: 1), Character cr asString.
    	].
    	2 to: topics size do: [:i |
    		textOut := textOut, '<option>', (topics at: i), Character cr asString.
    	].
    	^textOut.
    

    This chunk of code is the method that creates content for the list of topics for a given source. You can see where the array of topics is retrieved, and how the proper HTML code is assembled for each topic.

    Serving The Images
    This part was pretty easy. If you look at the HTML source you see that all of the images are linked to "npsupport/(image_name).jpg". The trick here is that our servlet does not handle requests for the images, they simply go to the default server action which is to load up the file named "(server_directory)/npsupport/(image_name).jpg". And we've got all the images sitting in that directory.

    Generating The Paper
    So how does the user generate a newspaper? Well, they click on the "Generate paper" button. That button isn't really a button, its just a hyperlinked image whose reference is to "newspaper/generate.html". Since the base address is "newspaper" our servlet gets the request. Our servlet watches for the "generate.html", and if in deed the request is for newspaper/generate.html, then another piece of code takes over. The code that takes over is similar in operation to the menu generation code. That is, some static strings are used to support the dynamic content. In this case, the dynamic content is retrieved from the selected web pages. And just like before, the generated html is shipped out through the request object.


    Links to this Page