From 6390b4350a0a69fa35f569db172d0de5ee6df1b2 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 13:02:50 -0500 Subject: re-markdownify the heading --- docs/DesignDocument.md | 32 ++++++-------------------------- 1 file changed, 6 insertions(+), 26 deletions(-) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index d9761b1..2fb57c0 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -1,30 +1,10 @@ -Design Document -Version 1.0 – 2014.02.09 -Created 2014.02.09 - -Leaguer -Nathaniel Foy -Guntas Grewal -Tomer Kimia -Andrew Murell -Luke Shumaker -Davis Webb - -1. Contents -1Purpose 3 -2Non-Functional Requirements 3 -3Design Outlines 3 -3.1Design Decisions and Components 3 -3.2Component Interaction 3 -4Design Issues 3 -4.1Scoring Algorithm 3 -4.2Offline Data Management 3 -4.3Fetching Data from Games 3 -5Design Details 4 -5.1Class Descriptions and Interactions 4 -5.2UML Diagram of Classes 4 +--- +title: Design Document +author: [ Nathaniel Foy, Guntas Grewal, Tomer Kimia, Andrew Murrell, Luke Shumaker, Davis Webb ] +--- +Version 1.0 – 2014.02.10 +Created 2014.02.09 - 1 Purpose This document describes all components of the Leaguer Tournament management system. Leaguer is a software to be installed and run on a server. TODO. ANDREW COMPLETE THIS. -- cgit v1.2.3-54-g00ecf From 66912895c53b7c22809935c2158c8ee9f184e793 Mon Sep 17 00:00:00 2001 From: AndrewMurrell Date: Mon, 10 Feb 2014 13:04:56 -0500 Subject: Worked with Davis on Section 3. --- docs/DesignDocument.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 9efbca8..4e24c99 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -45,17 +45,17 @@ sleek web application which manages tournaments. 2 Non-Functional Requirements TODO Guntas. Email dunsmore and marco about this, then fill it out. -3 Design Outlines +3 Design Outlines 3.1 Design Decisions and Components -Our system will on the Model 2 design pattern/architecture. +Project Leaguer is written on the Ruby on Rails platform and will use the Model 2 (MVC) design pattern/architecture. This architecture is comprised of three interacting components: Controllers, Views, and Models. -Controllers – The controllers will control any logic necessary to obtain the correct content for display. It then places the content in the request and decides which view it will be passed to. +Controllers – Requests received by the server are processed by a routing subroutine and directed to a controller responsible for handling them. Controllers accept these requests and manage any logic necessary to obtain the correct content for display, retrieving and updating information from the Model as needed. It then creates a new request, places the content from the model in the request (if applicable), decides which view it will be passed to, and passes on the request. -Models – We will be using a Ruby on Rails model. The Ruby on Rails framework maps to a table in the database and a Ruby file. So a User will usually be difined as user.rb in the app/models directory and this will be linked to the table users in the database. +Models – In Ruby on Rails, models are usually implemented as an interface to a table in the database and a Ruby file which queries this table and interacts with the other components. For example, a "user" model would be connected to the "user" table and a file "user.rb" in the app/models directory would provide an interface to interact with the "user" controller. -Views – Views will be the HTML pages for Leaguer, and will display the users desired content inside of the web browser. +Views – Views will primarily be dynamically generated HTML pages and will display the users desired content inside of the web browser. These may be implemented with inline Ruby scripts and tags within traditional HTML. Component Interaction -- cgit v1.2.3-54-g00ecf From b67793f0c920596d8bcd44a647336b0dda5dee6f Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 13:11:15 -0500 Subject: DesignDocument: markdownify the headings --- docs/DesignDocument.md | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 8b14aae..5fae039 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -5,7 +5,7 @@ author: [ Nathaniel Foy, Guntas Grewal, Tomer Kimia, Andrew Murrell, Luke Shumak Version 1.0 – 2014.02.10 Created 2014.02.09 -1 Purpose +# Purpose The purpose of this document is to outlay the desgin, intent, and structure of the Project Leaguer tournament organizing software. @@ -23,12 +23,13 @@ The software itself operates as a stand-alone background server application accessible and configurable though its web interface which reveals to users a sleek web application which manages tournaments. -2 Non-Functional Requirements +#Non-Functional Requirements + TODO Guntas. Email dunsmore and marco about this, then fill it out. -3 Design Outlines +# Design Outlines -3.1 Design Decisions and Components +## Design Decisions and Components Project Leaguer is written on the Ruby on Rails platform and will use the Model 2 (MVC) design pattern/architecture. This architecture is comprised of three interacting components: Controllers, Views, and Models. @@ -54,21 +55,26 @@ Each of these controllers will fetch the data specified by its separate section. The Model will be the data section that will map all of the information to their proper locations in the data base. -Design Issues +# Design Issues -Scoring Algorithm +## Scoring Algorithm + In an effort to keep our system broad, one of our requirements is that Leaguer is adaptable to many competitions, not just League of Legends. How do we assure that the different scoring systems of different sports are represented in Leaguer? + Option 1: One of our interfaces could be “Scoring System” which will be implemented by many classes with common scoring systems. For example there would be a implementing class in which the highest score wins, and one in which the lowest score wins. This is likely to be the winning option, as there are not too many obscure scoring systems that we could not think of. Option 2: We could design an API in which the host writes a method to update the scoring. This is pretty complex, and while it would allow more customization, it is hard to imagine completing this task without first completing option 1. -4.2 Offline Data Management +## Offline Data Management + TODO – Nathniel write this -4.3 Fetching Data from Games + +## Fetching Data from Games + TODO – Nathaniel write this. -5 Design Details -5.1 Class Descriptions and Interactions +# Design Details +## Class Descriptions and Interactions VIEWS Webpage: An abstract HTML file, all entries below are webpages (we represent them as subclasses of the abstract “Webpage” class. All webpages will send HTTP requests to the server. Most of the visual effects and update the display with Javascript methods. Each page will have a login dialogue which will POST to the login controller or the logged in user’s page. @@ -104,5 +110,6 @@ Server: Rails’ Server class handles all HTTP events. Our Server class is the c User: A class that represents someone using the Views (HTML, javascript) the user is in competitions and -5.2 UML Diagram of Classes +## UML Diagram of Classes + TODO – I’m working on this – see images.pptx -- cgit v1.2.3-54-g00ecf From c6d94fb81865017c9a2dd753b14cb18bbf400fc9 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 13:22:55 -0500 Subject: DesignDocument: fiddle with whitespace, make the roman numeral lowercase --- docs/DesignDocument.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 5fae039..0ca77a4 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -2,6 +2,7 @@ title: Design Document author: [ Nathaniel Foy, Guntas Grewal, Tomer Kimia, Andrew Murrell, Luke Shumaker, Davis Webb ] --- + Version 1.0 – 2014.02.10 Created 2014.02.09 @@ -41,15 +42,15 @@ Views – Views will primarily be dynamically generated HTML pages and will disp Component Interaction - Controllers will be used to run all of the background work of Leaguer. They will fetch the necessary data and will tell the view what to do. We will be implementing seven controllers into Leaguer. Those will be: +Controllers will be used to run all of the background work of Leaguer. They will fetch the necessary data and will tell the view what to do. We will be implementing seven controllers into Leaguer. Those will be: - I. PM & Alerts – This controller will be used for sending and receiving private messages to and from the host. Players will be able to message the host in order to inform him/her of anything during the tournament. This will also allow the host to post any notifications he or she desires that will be displayed for all to see. - II. Homepage – Used to handle the homepage. This will be the first web page seen by any user of the application. - III. Login – This controller will be used when a user attempts to sign in to their profile on Leaguer. - IV. Search – This controller will be used to search the web-base for on going tournaments, players and past tournaments. - V. Tournament – Used for setting up a tournament. This will be restricted to the host of the tournament. - VI. User – The controller that will take each user to their own profile. - VII. Match/Peer Review – used for gather game statistics and the separate player reviews. + i. PM & Alerts – This controller will be used for sending and receiving private messages to and from the host. Players will be able to message the host in order to inform him/her of anything during the tournament. This will also allow the host to post any notifications he or she desires that will be displayed for all to see. + ii.Homepage – Used to handle the homepage. This will be the first web page seen by any user of the application. + iii. Login – This controller will be used when a user attempts to sign in to their profile on Leaguer. + iv. Search – This controller will be used to search the web-base for on going tournaments, players and past tournaments. + v. Tournament – Used for setting up a tournament. This will be restricted to the host of the tournament. + vi. User – The controller that will take each user to their own profile. + vii. Match/Peer Review – used for gather game statistics and the separate player reviews. Each of these controllers will fetch the data specified by its separate section. The view will then be used to display all of this information, so Login will take the user to a login page, search will take the user to a search page and so on. -- cgit v1.2.3-54-g00ecf From de11084b4ed4574403dfbb16d059b04266af9323 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 13:33:59 -0500 Subject: DesignDocument: give the views rails-like names --- docs/DesignDocument.md | 74 ++++++++++++++++++++++++++++++++++++++------------ docs/Makefile | 2 +- 2 files changed, 57 insertions(+), 19 deletions(-) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 0ca77a4..5cfa946 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -45,7 +45,7 @@ Component Interaction Controllers will be used to run all of the background work of Leaguer. They will fetch the necessary data and will tell the view what to do. We will be implementing seven controllers into Leaguer. Those will be: i. PM & Alerts – This controller will be used for sending and receiving private messages to and from the host. Players will be able to message the host in order to inform him/her of anything during the tournament. This will also allow the host to post any notifications he or she desires that will be displayed for all to see. - ii.Homepage – Used to handle the homepage. This will be the first web page seen by any user of the application. + ii. Homepage – Used to handle the homepage. This will be the first web page seen by any user of the application. iii. Login – This controller will be used when a user attempts to sign in to their profile on Leaguer. iv. Search – This controller will be used to search the web-base for on going tournaments, players and past tournaments. v. Tournament – Used for setting up a tournament. This will be restricted to the host of the tournament. @@ -78,23 +78,61 @@ TODO – Nathaniel write this. ## Class Descriptions and Interactions VIEWS -Webpage: An abstract HTML file, all entries below are webpages (we represent them as subclasses of the abstract “Webpage” class. All webpages will send HTTP requests to the server. Most of the visual effects and update the display with Javascript methods. Each page will have a login dialogue which will POST to the login controller or the logged in user’s page. - -Homepage: This page has 3 basic options. Visually simple – two large buttons on a white screen, and a search bar above them. The search bar will cause a POST requeest to the search controller. Log in (which will cause a POST to the login controller) and “Go to Tournament” in which you enter a tournament title. This interacts with the Homepage Controller. - -Login: Page with form entries for username, password. If user clicks “new user” more forms entries will appear. One for repeating the password, and one for email. This POST to the Login controller. - -newTorunament: A form that interacts with users who are either hosts or becoming hosts. This interacts with tournament controller. - -Tournament: A tree-like display of matches, where each match consists of a pair of teams. All users can click on a match to go to that match’s page. Host can see a gear on top left corner that represents tournament settings, it will GET the edit Tournament view. There will be an end button that will redirect to back to the homepage after posting to the tournament controller. The tournament will POST to the tournament controller. - -editTorunament: This view is a list of settings. Some are form entries, and some are checkboxes. More settings will be added later in develpment. This view interacts with the tournament controller. - -Match: A display of both teams. Each team's players are clickable which causes a GET for the player's profile HTML. A link above both teams will GET the tournament the match belongs to. This will POST its actions to the Match controller. - -Search: A page with a searchbar and a list of searchable tournaments that match the search query. The searchbar causes a POST to the search controller. Each entry is clickable and causes a GET to the enrry's tournament. - -UserProfile: A page with the user's information. One can view the player's reviews. If the user is viewing his/her own profile, they can edit it causing a POST to the userProfile controller. +layouts/application.html.erb + : An abstract HTML file, all entries below are webpages (we + represent them as subclasses of the abstract “Webpage” class. All + webpages will send HTTP requests to the server. Most of the visual + effects and update the display with Javascript methods. Each page + will have a login dialogue which will POST to the login controller + or the logged in user’s page. + +main/homepage.html.erb + : This page has 3 basic options. Visually simple – two large buttons + on a white screen, and a search bar above them. The search bar + will cause a POST requeest to the search controller. Log in (which + will cause a POST to the login controller) and “Go to Tournament” + in which you enter a tournament title. This interacts with the + Homepage Controller. + +login/form.html.erb + : Page with form entries for username, password. If user clicks “new + user” more forms entries will appear. One for repeating the + password, and one for email. This POST to the Login controller. + +tournament/new.html.erb + : A form that interacts with users who are either hosts or becoming + hosts. This interacts with tournament controller. + +tournament/index.html.erb + : A tree-like display of matches, where each match consists of a + pair of teams. All users can click on a match to go to that + match’s page. Host can see a gear on top left corner that + represents tournament settings, it will GET the edit Tournament + view. There will be an end button that will redirect to back to + the homepage after posting to the tournament controller. The + tournament will POST to the tournament controller. + +tournament/edit.html.erb + : This view is a list of settings. Some are form entries, and some + are checkboxes. More settings will be added later in + develpment. This view interacts with the tournament controller. + +match/show.html.erb + : A display of both teams. Each team's players are clickable which + causes a GET for the player's profile HTML. A link above both + teams will GET the tournament the match belongs to. This will POST + its actions to the Match controller. + +search/search.html.erb + : A page with a searchbar and a list of searchable tournaments that + match the search query. The searchbar causes a POST to the search + controller. Each entry is clickable and causes a GET to the + enrry's tournament. + +user/show.html.erb + : A page with the user's information. One can view the player's + reviews. If the user is viewing his/her own profile, they can edit + it causing a POST to the userProfile controller. CONTROLLERS diff --git a/docs/Makefile b/docs/Makefile index b12a990..5082db3 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -12,7 +12,7 @@ html: $(addsuffix .html,$(docs)) ProductBacklog.pdf: SystemModel.png SystemModel.png: stickman.png -DesignDocument.pdf.args = --table-of-contents --number-sections +DesignDocument.pdf.args = --table-of-contents --number-sections -f markdown+definition_lists clean: rm -f -- *.pdf *.html -- cgit v1.2.3-54-g00ecf From 6b5feec6bd29446ffe6043cbecd4f23479fcff7f Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 13:36:28 -0500 Subject: DesignDocument: use pandoc definition lists --- docs/DesignDocument.md | 61 ++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 44 insertions(+), 17 deletions(-) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 5cfa946..3a9bd64 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -62,9 +62,19 @@ The Model will be the data section that will map all of the information to their In an effort to keep our system broad, one of our requirements is that Leaguer is adaptable to many competitions, not just League of Legends. How do we assure that the different scoring systems of different sports are represented in Leaguer? -Option 1: One of our interfaces could be “Scoring System” which will be implemented by many classes with common scoring systems. For example there would be a implementing class in which the highest score wins, and one in which the lowest score wins. This is likely to be the winning option, as there are not too many obscure scoring systems that we could not think of. - -Option 2: We could design an API in which the host writes a method to update the scoring. This is pretty complex, and while it would allow more customization, it is hard to imagine completing this task without first completing option 1. +Option 1 + : One of our interfaces could be “Scoring System” which will be + implemented by many classes with common scoring systems. For + example there would be a implementing class in which the highest + score wins, and one in which the lowest score wins. This is likely + to be the winning option, as there are not too many obscure + scoring systems that we could not think of. + +Option 2 + : We could design an API in which the host writes a method to update + the scoring. This is pretty complex, and while it would allow more + customization, it is hard to imagine completing this task without + first completing option 1. ## Offline Data Management @@ -77,7 +87,8 @@ TODO – Nathaniel write this. # Design Details ## Class Descriptions and Interactions -VIEWS +### VIEWS + layouts/application.html.erb : An abstract HTML file, all entries below are webpages (we represent them as subclasses of the abstract “Webpage” class. All @@ -134,19 +145,35 @@ user/show.html.erb reviews. If the user is viewing his/her own profile, they can edit it causing a POST to the userProfile controller. - -CONTROLLERS -HomepageController: This is the main controller. It has methods showHomepage() which renders the homepage view. It has editSettings() method, that gets the current settings of the entire server, provided that the host is viewing the homepage. - -LoginController: This has doLogin() and doLogout(). Both have access to the HTTP requrest. It will interact with the Users model to validate passwords and usernames. - -TournamentController: This controller will have methods: newTorunament(), getTournament(), editTournament(), and endTournament(). All of these methods will interact with the Tournament model, and all of its fields including users matches and TournamentSettings. And all will interact with their tournament view, for example, newTournament() will render newTorunament. - - - - -Server: Rails’ Server class handles all HTTP events. Our Server class is the class that is the main program. It instantiates other classes, manages requests from Views, and runs static methods. -User: A class that represents someone using the Views (HTML, javascript) the user is in competitions and +### CONTROLLERS + +HomepageController + : This is the main controller. It has methods showHomepage() which + renders the homepage view. It has editSettings() method, that gets + the current settings of the entire server, provided that the host + is viewing the homepage. + +LoginController + : This has doLogin() and doLogout(). Both have access to the HTTP + requrest. It will interact with the Users model to validate + passwords and usernames. + +TournamentController + : This controller will have methods: newTorunament(), + getTournament(), editTournament(), and endTournament(). All of + these methods will interact with the Tournament model, and all of + its fields including users matches and TournamentSettings. And all + will interact with their tournament view, for example, + newTournament() will render newTorunament. + +Server + : Rails’ Server class handles all HTTP events. Our Server class is + the class that is the main program. It instantiates other classes, + manages requests from Views, and runs static methods. + +User + : A class that represents someone using the Views (HTML, javascript) + the user is in competitions and ## UML Diagram of Classes -- cgit v1.2.3-54-g00ecf From 499bbc781ac2327015cf654225ffe43caff5cbc7 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 13:40:23 -0500 Subject: DesignDocument: word-wrap the Controlers/Model/View section --- docs/DesignDocument.md | 32 +++++++++++++++++++++++++------- 1 file changed, 25 insertions(+), 7 deletions(-) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 3a9bd64..e754a71 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -34,13 +34,31 @@ TODO Guntas. Email dunsmore and marco about this, then fill it out. Project Leaguer is written on the Ruby on Rails platform and will use the Model 2 (MVC) design pattern/architecture. This architecture is comprised of three interacting components: Controllers, Views, and Models. -Controllers – Requests received by the server are processed by a routing subroutine and directed to a controller responsible for handling them. Controllers accept these requests and manage any logic necessary to obtain the correct content for display, retrieving and updating information from the Model as needed. It then creates a new request, places the content from the model in the request (if applicable), decides which view it will be passed to, and passes on the request. - -Models – In Ruby on Rails, models are usually implemented as an interface to a table in the database and a Ruby file which queries this table and interacts with the other components. For example, a "user" model would be connected to the "user" table and a file "user.rb" in the app/models directory would provide an interface to interact with the "user" controller. - -Views – Views will primarily be dynamically generated HTML pages and will display the users desired content inside of the web browser. These may be implemented with inline Ruby scripts and tags within traditional HTML. - -Component Interaction +Controllers + : Requests received by the server are processed by a routing + subroutine and directed to a controller responsible for handling + them. Controllers accept these requests and manage any logic + necessary to obtain the correct content for display, retrieving + and updating information from the Model as needed. It then + creates a new request, places the content from the model in the + request (if applicable), decides which view it will be passed to, + and passes on the request. + +Models + : In Ruby on Rails, models are usually implemented as an interface + to a table in the database and a Ruby file which queries this + table and interacts with the other components. For example, a + "user" model would be connected to the "user" table and a file + "user.rb" in the app/models directory would provide an interface + to interact with the "user" controller. + +Views + : Views will primarily be dynamically generated HTML pages and will + display the users desired content inside of the web browser. These + may be implemented with inline Ruby scripts and tags within + traditional HTML. + +## Component Interaction Controllers will be used to run all of the background work of Leaguer. They will fetch the necessary data and will tell the view what to do. We will be implementing seven controllers into Leaguer. Those will be: -- cgit v1.2.3-54-g00ecf From 66e8bf81734e0b2920505ed073097fa8e6c35f06 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 13:53:25 -0500 Subject: DesignDocument: embed the graphviz UML --- docs/DesignDocument.md | 6 +++++- docs/Makefile | 2 ++ 2 files changed, 7 insertions(+), 1 deletion(-) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index e754a71..fdb2a8c 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -196,4 +196,8 @@ User ## UML Diagram of Classes -TODO – I’m working on this – see images.pptx +TODO – I’m working on this – see images.pptx ~ Tomer + +So am I: ~ Luke + +![](DesignDocument.png)\ diff --git a/docs/Makefile b/docs/Makefile index ff2a1cb..4f236d4 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -12,6 +12,8 @@ html: $(addsuffix .html,$(docs)) ProductBacklog.pdf: SystemModel.png SystemModel.png: stickman.png + +DesignDocument.pdf: DesignDocument.png DesignDocument.pdf.args = --table-of-contents --number-sections -f markdown+definition_lists clean: -- cgit v1.2.3-54-g00ecf From 09b631258a45b3b3d80ebc8084f81d8e1014b6c6 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 14:08:24 -0500 Subject: DesignDocument: start adding models --- docs/DesignDocument.md | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index fdb2a8c..cd3c682 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -105,6 +105,15 @@ TODO – Nathaniel write this. # Design Details ## Class Descriptions and Interactions +### MODELS + +ActiveRecord::Base (abstract) + : The abstract model that all other models inherit from. + +User + : This model represents all types of users; hosts, players, and + spectators. These roles are identified by a “role” attribute. + ### VIEWS layouts/application.html.erb -- cgit v1.2.3-54-g00ecf From 74a88fba1be5c17360de55772ecaab3afaef1e02 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 14:10:30 -0500 Subject: DesignDocument: touch up view names --- docs/DesignDocument.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index cd3c682..4a1cb86 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -116,7 +116,7 @@ User ### VIEWS -layouts/application.html.erb +layouts/application.html (abstract) : An abstract HTML file, all entries below are webpages (we represent them as subclasses of the abstract “Webpage” class. All webpages will send HTTP requests to the server. Most of the visual @@ -124,7 +124,7 @@ layouts/application.html.erb will have a login dialogue which will POST to the login controller or the logged in user’s page. -main/homepage.html.erb +main/homepage.html : This page has 3 basic options. Visually simple – two large buttons on a white screen, and a search bar above them. The search bar will cause a POST requeest to the search controller. Log in (which @@ -132,16 +132,16 @@ main/homepage.html.erb in which you enter a tournament title. This interacts with the Homepage Controller. -login/form.html.erb +login/form.html : Page with form entries for username, password. If user clicks “new user” more forms entries will appear. One for repeating the password, and one for email. This POST to the Login controller. -tournament/new.html.erb +tournaments/new.html : A form that interacts with users who are either hosts or becoming hosts. This interacts with tournament controller. -tournament/index.html.erb +tournaments/index.html : A tree-like display of matches, where each match consists of a pair of teams. All users can click on a match to go to that match’s page. Host can see a gear on top left corner that @@ -150,24 +150,24 @@ tournament/index.html.erb the homepage after posting to the tournament controller. The tournament will POST to the tournament controller. -tournament/edit.html.erb +tournaments/edit.html : This view is a list of settings. Some are form entries, and some are checkboxes. More settings will be added later in develpment. This view interacts with the tournament controller. -match/show.html.erb +matches/show.html : A display of both teams. Each team's players are clickable which causes a GET for the player's profile HTML. A link above both teams will GET the tournament the match belongs to. This will POST its actions to the Match controller. -search/search.html.erb +search/form.html : A page with a searchbar and a list of searchable tournaments that match the search query. The searchbar causes a POST to the search controller. Each entry is clickable and causes a GET to the enrry's tournament. -user/show.html.erb +users/show.html : A page with the user's information. One can view the player's reviews. If the user is viewing his/her own profile, they can edit it causing a POST to the userProfile controller. -- cgit v1.2.3-54-g00ecf From b2cf6249063987e74e0742935a90b6ed6de9ac8e Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 14:10:57 -0500 Subject: DesignDocument: fix typo --- docs/DesignDocument.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 4a1cb86..22dc264 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -127,7 +127,7 @@ layouts/application.html (abstract) main/homepage.html : This page has 3 basic options. Visually simple – two large buttons on a white screen, and a search bar above them. The search bar - will cause a POST requeest to the search controller. Log in (which + will cause a POST request to the search controller. Log in (which will cause a POST to the login controller) and “Go to Tournament” in which you enter a tournament title. This interacts with the Homepage Controller. -- cgit v1.2.3-54-g00ecf From f3544deefc69b00e99c45f066fe7a3221f200a8c Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 14:11:30 -0500 Subject: elaborate on some of the views and controllers --- docs/DesignDocument.md | 32 +++++++++++++++++++++++++++----- 1 file changed, 27 insertions(+), 5 deletions(-) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index 22dc264..d294c30 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -132,6 +132,10 @@ main/homepage.html in which you enter a tournament title. This interacts with the Homepage Controller. +main/edit.html + : This page is a form for editing the server-wide configuration, + such as the language or the graphical theme. + login/form.html : Page with form entries for username, password. If user clicks “new user” more forms entries will appear. One for repeating the @@ -166,6 +170,8 @@ search/form.html match the search query. The searchbar causes a POST to the search controller. Each entry is clickable and causes a GET to the enrry's tournament. +search/results.html + : A page that shows search results. users/show.html : A page with the user's information. One can view the player's @@ -174,11 +180,27 @@ users/show.html ### CONTROLLERS -HomepageController - : This is the main controller. It has methods showHomepage() which - renders the homepage view. It has editSettings() method, that gets - the current settings of the entire server, provided that the host - is viewing the homepage. +ApplicationController (abstract) + : The base controller class that all other controllers inherit from. + +MainController + : This is the main controller. It has the following methods: + + - `show_homepage()` Responds to GET requests by rendering the + `main/homepage` view. + - `edit_settings()` Responds to GET requests by (if the user is + authenticated and is a host) rendereing the `main/edit` view + that presents the user with a form to edit the server settings. + If the user is not authenticated, it renders the + `common/permission_denied` view. This involves interacting with + the `User` model to determine whether the user is authorized to + see this. + - `update_settings()` Responds to POST requests by updating the + server configuration with the POSTed settings. It then either + renders the `common/permission_denied` view, or the `main/edit` + view with the updated settings. This involves interacting with + the `User` model to determine whether the user is authorized to + do this. LoginController : This has doLogin() and doLogout(). Both have access to the HTTP -- cgit v1.2.3-54-g00ecf From 107d7cff315548692a4e81e2961664fd5f08238a Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Mon, 10 Feb 2014 14:17:35 -0500 Subject: DesignDocument: fix whitespace --- docs/DesignDocument.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'docs/DesignDocument.md') diff --git a/docs/DesignDocument.md b/docs/DesignDocument.md index d294c30..e73cb25 100644 --- a/docs/DesignDocument.md +++ b/docs/DesignDocument.md @@ -188,14 +188,14 @@ MainController - `show_homepage()` Responds to GET requests by rendering the `main/homepage` view. - - `edit_settings()` Responds to GET requests by (if the user is + - `edit_settings()` Responds to GET requests by (if the user is authenticated and is a host) rendereing the `main/edit` view that presents the user with a form to edit the server settings. If the user is not authenticated, it renders the `common/permission_denied` view. This involves interacting with the `User` model to determine whether the user is authorized to see this. - - `update_settings()` Responds to POST requests by updating the + - `update_settings()` Responds to POST requests by updating the server configuration with the POSTed settings. It then either renders the `common/permission_denied` view, or the `main/edit` view with the updated settings. This involves interacting with @@ -223,7 +223,7 @@ Server User : A class that represents someone using the Views (HTML, javascript) the user is in competitions and - + ## UML Diagram of Classes -- cgit v1.2.3-54-g00ecf