Software Design

Tools

• Python
  • Flask
  • SQLAlchemy
  • requests
• GNUMake

Design

Our website is organized into two domains: Front-End development, and Back-end development.

Front-End

• Pertains to the organization and serving of web pages, populating data in web pages, and facilitating in aesthetic design and animation

Back-End

• Pertains to the organization of models and database, and the serving of data from the database to front-end.

Routing

The routes are services which the websites offers to the client when they make a specific request to our server. Our routing structure then can be thought of as two different parts: the routes which provide functionality to the actual website and pages, and the routes which performs and serves our Golazo API.

Back-End Design

We decided to use Flask's routing system for our API, but also use AngularJS routing system for the front-end. Flask is a very simple, yet powerful tool for creating web frameworks, so it was our first choice as a library for implementing our API.

Flask monitors several endpoints and serves them accordingly: #####Back-End Endpoints

• /
  • This is the home route for our Flask routing system. It serves the index.html template file which serves as the entry point to our website.
• /runtests
  • This is the route used for retrieving the testing status of our website to the front-end. It serves a text output of the test results.

The rest of the Back-End Endpoints are used to implement the API.

The API can be explained [here]("link to API").

Front-End

We decided to use AngularJS for our front-end as it is packed full of features which facilitated in providing pagination and other animation into our web pages. However, AngularJS provides a routing system which is easy.

In app.js, AngularJS route provider system is used to monitor the serving of web pages and the loading of dynamic data. The following endpoints have their respective controller to perform these tasks:

#####Front-End Endpoints

• /
  • This is our home route for front-end and is controlled by the 'main' controller. As of now, the main controller makes a call to our API to get the game playing today if there is one. It then populates index.html with show cards which refer to the game and its participants.
• /about
  • This is the about route for front-end and is controlled by the 'about' controller. The about controller controls the online testing viewer. It makes a call to Flask's routing system to gather the testing data that ran on the server and displays it nicely on the website.
• /games
  • This is the games route for front-end and is controlled by the 'games' controller. This controller constructs the games view. It populates table with games retrieved from the API and paginates them in increments of 10.
• /players
  • This is the players route for front-end and is controlled by the 'players' controller. This constructs the Players view which populates a table with the total list of players and paginates them in increments of 10, ordered alphabetically.
• /teams
  • This is the teams route for front-end and is controlled by the 'teams' controller. This constructs the Teams view which populates a table with the total list of teams and paginates them in increments of 10.
• /team/:id
  • This is the team route for front-end and is controlled by the 'team' controller. This constructs the Team view for a specific team and populates the information in the page from data retrieved from the API.
• /seasons
  • This is the seasons route for front-end and is controlled by the 'seasons' controller. This constructs the Seasons view which populates a table of total compiled seasons and paginates them in increments of 10. standings/:id
  • This is the standing route for front-end and is controlled by the 'standing' controller. This constructs the Season view for a specific seasons and populates the information in the page from data retrieved from the API.
  • As of right now, only one season is fully populated with information and is used to show of the website's functionality.

Code

There are several sections of our code which are non-trivial and need explanation.

####Test Button To implement the test button, we needed a way to get our test results to be served to the front-end of the website. We decided to use a flask endpoint to serve the output of the tests. The call serves a file which is the output of our tests of the server. Our server updates this file by running the tests every hour.

####Pagination To implement pagination in our website, we needed to design our code in such a way as to allow for chunks of data to be served to our front-end. To do this we needed to define how a page gets its data and how such data is populated. We use AngularJS to organize our website data into tables with columns which represent keys. The front end controller for each website records the user's location in the data table and fills the table accordingly in respect to the user's current offset as he or she navigates our website. To facilitate this process, we designed our API calls which gives list data to serve it grouped in lists of 10. Notice then that our API list calls have an optional parameter called offset, which returns a list of 10 models in the database starting at the offset. We use this to get the correct group of data for each page. This type of pagination is used for all of our models.

####Search To implement search in our website, we use a Flask endpoint which is given a search phrase. In the server, we then query the database with the search phrase, using the entire phrase and its constituent words to find similarities with all the models and return the results. In doing so, it retrieves the 'and' and 'or' results of the phrase, as it merges all the query results into one and serves it to the front-end.

To search, begin writing in the search box in the top right corner of the page.