Travel Federation

For Milestone due dates see schedule below.

See Addendum for updates.

Continuation: A Joint Federation of Travel Sites

This is a Paired Programming Project. It is the final in a three part semester project working toward a class federation of travel websites. New Teams will be assigned through Canvas by EOD Friday 4/6. You'll build upon what you developed for Project 1 and 2. As mentioned in prior Projects, both of the team partners first need to review, discuss and agree upon what parts of their Project could be carried forward to this phase. In Project 3, you will be enhancing the functionality of your travel site. The objective of this project is to have the class as whole create a Federated Travel Site. Each site will share the information about it's available attractions with the Federation. Most of this new functionality will be developed in JavaScript utilizing JSON and jQuery. Though, if you have not transitioned your site to use a proper DB, you will have to do that as part of this assignment. No keeping site state/data in a file!

Master Federation List and Common API alements

The CT310 account will provide a master list of all sites in the Federation in JSON (Array) format. The master list URL is accessible at https://www.cs.colostate.edu/~ct310/yr2018sp/master.json The JSON response is formatted as shown in the following example:

[{"team":"0","nameShort":"Rivers","nameLong":"Beautiful Flowing Rivers","eid":"eid"}]

This example has a single fake site, once teams supply this information, the page will return an array of sites. There may be multiple entries with the same team number.

As will be discussed further below, there are four pages that you must supply with your site.

• ~eid/ct310/index.php/federation/status
• ~eid/ct310/index.php/federation/allstatus
• ~eid/ct310/index.php/federation/listing
• ~eid/ct310/index.php/federation/attraction/[id]
• ~eid/ct310/index.php/federation/attrimage/[id]

These controllers and actions must reside at the URL provided in order to standardize the AJAX calls across the federation. The functionality of these four pages is discussed below, both from the standpoint of what the AJAX service must provide and also how you are expected to utilize that functionality when extending your Travel Website.

AJAX Status Page

The page ~eid/ct310/index.php/federation/status provides a mechanism for indicating if your site is open for business. This will be useful to all of you as you write code that must decide when to attempt to display attractions from another site in the list of federated sites.

Your ~eid/ct310/index.php/federation/status page must return a JSON object. More precisely, if you want to signal your site is ready for business, it should return: {"status":"open"}
and if you are not ready to have other sites querying your site then instead return: {"status":"closed"} . Please implment this functionality,returning the closed option ASAP, since the entire class will start relying on each others pages.

Displaying Federation Status

Your site also should provide a page ~eid/ct310/index.php/federation/allstatus that provides immediate visual feedback regarding the status of every site in the Federation Master List. You must list each site's status, not just one status per team. Exactly how you format this display is up to you, provided you work into your display the following:

• The short name of each site.
• The long name of each site.
• A prominent color encoded status indicator for each site. There are three possible colors

There are actually three possible states and with each a color:

1. Green: Site responded as open when asked through their status page.
2. Red: Site responded as closed when asked through their status page.
3. Yellow: Site has not responded to an AJAX call to their status page.

Notice that this page is not something a Customer would generally want to see (though they can, this page is NOT protected by login), but it will be handy as a visual indicator of what other sites are up and running: something you will want to know as you start pulling attraction content from these other sites.

AJAX Listing Page

Your site must provide a page, ~eid/ct310/index.php/federation/listing , through which any other site in the federation may obtain a listing of available attractions. The results should be returned using JSON. Here is an example:

[{"id":"1","name":"Yosemite","state":"CA"},{"id":"2","name":"Mt. Rushmore","state":"SD"}]

The id field must be unique to your site and it will be used in other AJAX calls to specify an attraction. The name field is whatevery you like. The state field is the two letter state abbreviation (in CAPS).

Displaying All Available Attractions

Currently you have a page that displays all attractions from your site. For Project 3 you must now display all attractions from all sites that are open as defined above by status. Attractions from your and other sites are no longer limited by user level. You have a lot of latitude when it comes to how exactly you want to display this information visually to customer. That said, here are some guidelines and suggestions. You may want to not include thumbnail images in this master listing becuase it will become long. However you display each attraction, perhpas as a unique row in a table, there must be a hyperlink to a page hosted on your site that displays information aobut that specific attraction. More will be said about that page later.

You also face some choices in terms of timing and sorting. For example, you could insert directly into the table each time you get a response from another site. Alternatively, you could collect responses in an intermediate JavaScript structer (array of attraction objects perhaps) and then only redo the table every couple of seconds or when you've detected that all open sites have provided you their attraction listing information. You should also think about how you want to group attractions. Finally, pagination is a nice touch, but it is NOT required for displaying attractions in this assignment: a single long listing on one page is fine.

The AJAX Attractions Page

Your ~eid/ct310/index.php/federation/attraction/[id] page will return additional information on a specific attraction appropriate for the generation of a display page highlighting the attraction. Note this page will be used with an attraction specified on the URL. So, for example:

~eid/ct310/index.php/federation/attraction/2

This AJAX call returns a JSON object very similar to a single entry from the ~eid/ct310/index.php/federation/listing page with two notable exceptions. It will include two additional fields in order to supply a long description, desc. So, for example:

{"id":"2","name":"Mt. Rushmore","desc":"Look, those rocks looks like the faces of presidents!","state":"SD"}

As you write the code to generate these AJAX responses pay attention to escape characters in the formatting of strings, particularly the long description. Finally, for your own sake and the other sites depending upon you, make sure that information in the common fields returned by ~eid/ct310/index.php/federation/attraction matches that returned by ~eid/ct310/index.php/federation/listing for the same attraction.

The AJAX Attraction Image Page

Your ~eid/ct310/index.php/federation/attrimage/[id] page will stream the contents of an image of a single attraction that may then in turn be displayed. Note that like the ~eid/ct310/index.php/federation/attraction page, the id of the attraction is passed along in the URL. Indeed, the attraction specification should be communicated in exactly the same manner.

Some Suggestions

Your approach in this assignment should be to build the AJAX API functionality first. That includes obviously testing it and making sure it is functioning as desired.

Do NOT treat your site as special when displaying the summary listing of federation attractions nor when displaying specific attractions. This advice is key for two reasons. First, it means you 'eat your own cooking' - to borrow a phrase. Second, and more important, it reduces the total amount of code you need to write. For example, think about the page you use to display a single attraction. In Project 2, in all likelihood it took one GET (URL passed) argument specifying the unique id of the attraction. To build Project 3, in essence you add one more argument, the short name of the site where the attraction is hosted. Then, simply use the standard AJAX API to populate the page decription. If your AJAX calls are functioning properly, this will work as well for your site as any other.

As you build up support for the Federation, do not break functionality. In other words, everything your Projec 2 site(s) could do this new site can do. That includes the ability to reset passwords, shop and accumulate brochures in a shopping cart, etc. Now, one simplfication, you need NOT communicate information back to other sites when a customer adds attraction brochurs from their site into your shopping cart. This lack of communication back is unrealisitc, but it would take us into a level of complexity beyond the scope of this assignment. Your shopping carts should simply record the short name of the sites hosting the brochurs being requested.

Schedule

Because Project 3 has teams utilizing functionality being implemented by other teams a staggered set of deadlines/milestones is being established. These are summarized next.

Wednesday April 11th by Midnight

Each groups member submits through email to ct310@cs.colostate.edu their entry line for the master listing. Specifically their team , nameShort , nameLong and eid . Keep in mind the URLs are fixed based on your eid (see above)

Friday April 13th by Midnight

Please have your ~eid/ct310/index.php/federation/status page in place and at least returning a properly formatted 'closed' message.

Friday April 27th by Midnight

Dry run testing of Project 3 Team AJAX API. The GTA will test and record which teams have all four AJAX files in place and responding to queries correctly. Your site MUST report OPEN before this date.

Friday May 4th Project 3 is Due by 11:55pm

Code development freezes. The Projects are due and will be graded. Grading will be through live sites, although project teams will be asked to submit tar files of their site code as well. Please host it on your CS account at the usual URL.

Project Teams

As with the previous projects, project teams are assigned at random.