Difference between revisions of "Team:Michigan Software/Design"

 
(13 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
<html>
 
<html>
  
−
<h2>Design</h2>
+
<h1>Design</h1>
−
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;HTML, CSS, and Javascript were used to create the user interface for Protocat. The intent was to design the site in a way that makes it easy for users to create, find, and use any protocol on our database. We used Bootstrap for its HTML grid layout to format our pages.</p>
+
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;HTML, CSS, and Javascript were used to create the user interface for Protocat 2.0. The intent was to design the site in a way that makes it easy for users to create, find, and use any protocol on our database. We used Bootstrap for its HTML grid layout to format our pages.</p>
 +
 +
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;We used the Django web framework designed for Python 3.4 to manage the inner workings of Protocat 2.0. Django is convenient because it is capable of useful features including managing administration, databases, authentication, and templating of data on HTML pages through a Model-View-Controller system. The Model component is the Python code interacting that stores classes and objects needed for the database. The View component is the user interface that updates when changes are made to the model. The Controller handles browser requests and responses, as well as database connections. The combined MVC is an architecturally sound web application.</p>
  
−
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;On the back end of Protocat, we used the Django web framework designed for Python 3.4. Django is a convenient framework to use because it is able manage administration, databases, authentication, and templating data on HTML pages, as well as other useful features. It is also fairly simple to learn because of it's Model-View-Controller (MVC) system. To create the database we created a "class Protocol," the model of a protocol for our database. Attributes in our Protocol class are properties associated with a protocol, such as name, reagents, and steps. We then migrate these models through Django which creates our database for us. Whenever we want to make changes to our models, all we have to do is migrate the changes through Django which will change our database accordingly. Django comes with its own user system, so there is no need for us to make a user model.</p>
+
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Protocat 2.0 uses two databases, one for protocols and one for users. We created a “class Protocol,” a model of a protocol, to be used in the protocol database. This class includes properties such as name, reagents, protocol ID, and steps. Django takes care of the necessary steps to aggregate the various protocols into a database. Whenever changes need to be made to our models, all we need to do is migrate the changes through Django and it will change our database accordingly. Django comes with its own user system, which was used instead of creating our own user model. New user information such as username, password, email, and real name are added to the user database. Likewise, when a protocol is uploaded, all those attributes are saved in the protocol database.</p>
  
−
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;We have two databases, one for protocols and one for users. When someone signs up for Protocat, their username, email, password, first, and last name are added to the user database. Likewise, when someone uploads a protocol, all attributes of the protocol are saved into the protocol database.</p>
+
<center><img src="https://static.igem.org/mediawiki/2015/3/35/Team_Michigan_Software_Databases.png" width=500px /></center>
 +
<br />
  
−
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;When uploading a protocol, the author is automatically chosen to be the username name of the uploader, taken from the user database. Each uploaded protocol is also given an auto-incremented id number. This id is used when making queries to the database to view a protocol, and helps differentiate protocols with the same name. </p>
 
−
 
−
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Uploading protocols and signing up for Protocat is the Controller in the MVC system because this is how we allow users to interact with the database. People accessing protocols from the database is where the View comes in to play. </p>
 
  
 
</div>
 
</div>
  
 
</html>
 
</html>

Latest revision as of 14:02, 18 September 2015


Michigan Software 2015

Design

     HTML, CSS, and Javascript were used to create the user interface for Protocat 2.0. The intent was to design the site in a way that makes it easy for users to create, find, and use any protocol on our database. We used Bootstrap for its HTML grid layout to format our pages.

     We used the Django web framework designed for Python 3.4 to manage the inner workings of Protocat 2.0. Django is convenient because it is capable of useful features including managing administration, databases, authentication, and templating of data on HTML pages through a Model-View-Controller system. The Model component is the Python code interacting that stores classes and objects needed for the database. The View component is the user interface that updates when changes are made to the model. The Controller handles browser requests and responses, as well as database connections. The combined MVC is an architecturally sound web application.

     Protocat 2.0 uses two databases, one for protocols and one for users. We created a “class Protocol,” a model of a protocol, to be used in the protocol database. This class includes properties such as name, reagents, protocol ID, and steps. Django takes care of the necessary steps to aggregate the various protocols into a database. Whenever changes need to be made to our models, all we need to do is migrate the changes through Django and it will change our database accordingly. Django comes with its own user system, which was used instead of creating our own user model. New user information such as username, password, email, and real name are added to the user database. Likewise, when a protocol is uploaded, all those attributes are saved in the protocol database.