Welcome, Guest User :: Click here to login

Logo 67272

67-272 :: Phase 5: Finishing the Baking Factory


This phase we will finish our project to develop an online system for the Baking Factory. This phase will constitute 14 percent of your final course grade and is broken down into the following components:

1. Implementation of Site Design: An appropriate visual design for the site using CSS and appropriate images should be created. Even though you have been given a basic CSS as a starter, do NOT feel in any way that you have to use these settings and designs; much of this is just for the sake of people who need help from phase 3 to get up to speed. (Indeed, to get top marks on visual design, you will need to improve upon the default CSS.)

When users log into the application, they should go to a home page that provides all the key information a user would immediately want access to (or have access to it with just one click). Shippers and bakers obviously want access to their appropriate lists as mentioned in phase 1, but the design of information for customers and administrators is up to the discretion of you, the designer. An appropriate way for each type of user to navigate throughout the site must be clearly evident and allow easy transitions to other parts of the application.

A lot of the grade this phase will be on the quality of the interactions you design for each of the users and how well you implement the design concepts discussed in class. Below is a list of high-level use cases to guide you, but if you feel a need to deviate from this list, you may do so as long as it is documented in the README file and you have discussed it in advance with Prof. H.

As last time, semi-static pages for about, contact, privacy and the like must be in place. No 'lorem ipsum' style text is accepted on any page; text should be appropriate for the page. The student's name must appear on the bottom of every page in the footer (name should be listed as webmaster or designer).

2. Authorization: Customers should have access to information that either belongs to them (such as their order history or account settings) or is necessary for them to conduct business (be able to see and order items), but they should not have access to other customers' information or business information that is used only by employees (such as the baking and shipping lists). Likewise, bakers and shippers have limited access to their respective lists and their user accounts but cannot add or edit items, prices, customers and the like. Administrators as usual have complete authority to do whatever is needed on the site.

Authorization should be implemented at both the controller and the view level. Do not show options to a user that the user does not have the authorization to act on. (By now we should know why this is the case.)

3. Testing: All unit tests (given in the starter code) must be fully working. Since you were given a solution, expect a penalty if this solution is not implemented and any unit tests fail. As for cucumber tests, there are no tests provided this phase in order to maximize your freedom to design. As a result, the weight this phase is considerably less for tests and much more on designing appropriate interactions.

4. Coding Style: All code must be appropriately organized. What that means at this stage is the following: Indentation should be used consistently to make code readable. Comments showing organization should be present and explaining difficult code should be used when/if necessary. All business logic should be in models, not views or controllers.

5. Creation of API: Using the models provided in the starter code, create an API for the Customer and Order entities. In this case, we are only looking for GET requests and authentication is not required. Below is a sample of the JSON we expect your API to generate.

Starting the project

Starter code is available for you on Github. This starter code has some additional code modules not previously given, so we strongly recommend you start with this as your base and port over styles, views, etc from phase 3 that could be helpful. To get this code, it would be best to clone the existing repository with the following command:

  git clone https://github.com/profh/baking_factory_phase_5_starter.git

After this, switch into the project directory and remove the reference to origin with the following:

  git remote rm origin

This will stop you from accidentally trying to push changes to Prof. H's repo (which won't be accepted). Now it is recommended that instead you set up a connection to your remote repository on darkknight soon and begin saving your code there early in your development. There is no limit on a number of times you can commit code to the remote repository and remember that committing to your local repository does not automatically mean the remote repository has been updated.

After cloning the project, run bundle install to get any gems needed. After that, populate the database with rake db:populate to get a set of realistic records in your database. (We've added rake db:drop, rake db:migrate, rake db:test:prepare to the populate script so anytime you run it, it will completely reset both your dev and test databases.)

Building the API

At the end of this phase, you will also have to build a basic API for the Baking Factory application. This application will be a separate repository on darkknight, but you can (and absolutely should) copy your models into this new application. We are only asking for GET requests (index and show actions) for the following models:

  • Customer
  • Order

A sample of the output expected (using a reduced set of data generated from the populate script) can be found below. These endpoints must be able to generate JSON of this structure. You are also required to use Swagger Docs to document your API; as mentioned in class, an API without sufficient documentation is nearly useless. We also expect you to allow for cross-origin resource sharing (CORS).

You will be given a separate repository for the API -- do not use your main repository for phase 5 on darkknight.

You do NOT have to handle authentication in your API, allow for filtering or ordering (apart from what your endpoint provides by default), throttle requests to the API or creating versioning for the API. Again, there are also no RESTful endpoints for POST, PATCH or DELETE -- we are only handling basic GET requests for the models listed earlier with this API. Nothing from lab 12 is required or desired for this part of the phase.


Baking Factory wants to be able to post pictures of their different items. An administrator should be able to upload photos for items and have them displayed on the item's show page. If an item doesn't have a picture, it should be handled appropriately (and not look like a gaping hole in the page).

When an administrator sees the item's show page, he/she should also see a price history of the item as well as have an opportunity to change the price right there. Customers only see the current price, but they should also see a list of similar items (i.e., items that are of the same category) that they may also be interested in purchasing.


The starter code you have been given has a module called Cart that is located in lib/helpers/cart.rb. As noted earlier in the course, we are saving cart information to a session hash and not to a database. This module has the following methods you might find helpful:

  • create_cart
  • clear_cart
  • destroy_cart
  • add_item_to_cart(item_id)
  • remove_item_from_cart(item_id)
  • calculate_cart_items_cost
  • get_list_of_items_in_cart
  • save_each_item_in_cart(order)

If you want a class (e.g., the OrdersController class) to have access to this cart functionality, simply add near the top of the class the following:

  include AppHelpers::Cart

These functions work fine, but you are free to modify them if you wish. In any case, users must be able to add (or remove) items to a cart and when the cart has everything the customer wants, he/she can checkout the cart and pay for the items.

You may use the code provided and you can modify it as you wish, but you may NOT use a cart gem or any other pre-built cart plug-in or solution for this phase as it defeats some of the educational objectives we have for this part of the assignment.

Finally, also note that there is another module called Shipping (in lib/helpers/shipping.rb) that has a useful method called calculate_cart_shipping. This method calculates the shipping costs for items that are currently in the cart. This module needs to be included in the appropriate places similar to how you included the Cart module.

Nested forms

When creating a new customer account, the client must be able to also create a User account -- from the client's perspective this should be seamless and not two separate steps. Having a nested form for user within customer is required for this phase; other nested forms might make sense from a design perspective, but are not strictly required.

Filtered parameters

When creating a new customer account, the client must not be able to set the role parameter and the controller should filter out any attempts to do so. (In fact, no one but the administrator should be able to set role.) In a similar fashion, because we don't want anyone to manipulate dates for orders or item prices, so these should be set internally and the controller should filter out any attempts to change them.

Other notes

A few other notes students should be aware of:

  • If a table has no content, then give an appropriate message rather than displaying an empty table.
  • No 'geek dates' – format dates in a user-friendly fashion and do so for an American (rather than European) audience.
  • If the computer should know the date (because it is today or tomorrow, for instance) then users typically don't have to enter the date. If a date is needed, use a datepicker for dates rather than three date dropdown lists that Rails defaults to.
  • All tables, lists, and select options must be appropriately ordered.
  • Appropriate and clear feedback for the user needs to be given to reduce misunderstanding.
  • Navigation options appropriate for each type of user should be provided.

Finishing the project

Your project will be turned in via git no later than 4:59pm on May 3, 2019. We will transfer a copy of your files from your remote git repository on darkknight-cmuis.net to the grading system on May 6th at 4:00pm. We know that everyone will turn in their applications on time, so we will not bother to check timestamps in this last phase. We will keep access open to the remote repositories and answer questions regarding the project after the due date since those things may prove helpful to students studying for the final exam. Once we start transferring files on May 6th, we will have to cut off student access to the server, so any applications missing or largely defective at that time will get a zero grade.

Again, if you have questions regarding the turn-in of this project or problems downloading any of the materials provided, please ask Prof. H or a Head TA well in advance of the turn-in date. Do not wait until 48 hours or less before it is due to get help as we may not be able to respond in a timely fashion that close to the deadline.

Additional Information. Below are links to additional files references above.

High Level Use Cases

JSON sample from API


Due Date: May 03, 2019

Weight: 14.0