This section discusses the implementation of each of the pages in the user interface. The author will outline how each of the pages designed in Appendix D were implemented. However, within the remit of the project it is not possible to go into detail of how every part of the user interface was implemented.
Therefore, the more advanced features implemented on each page will be discussed here with code extracts and screenshots provided in Appendix E.
The implementation of the user interface is carried out by creating “Views” and using Django’s Templating system for each page. Holovaty & Kaplan-Moss (2006) state that a View returns a HttpResponse object which contains the content of the requested page. Holovaty & Kaplan-Moss (2006), then declare that a view “retrieves data, loads a template and renders the template with the retrieved data”. Django’s templating system is required once a view has been created. Views and Templates will be discussed further in this section as they are required in the implementation of each page on the user interface.
6.3.1 Implementation of the Main Page
Appendix C, Figure C outlines all the folders that have been created. The code written for the Main Page resided in the Home folder. This folder has the following structure;
Home/
__init__.py models.py views.py
The views.py module has a method which points to an html template. This template stores the code of what is to be displayed on the main page of the user interface. In views.py the following code was inserted;
(Ln1) from myproject.home.models import Home
(Ln2) from django.http import HttpResponse (Ln3) from django.template import Context, loader
(Ln5) def index(request):
(Ln6) latest_home_list = Home.objects.all().order_by('Home') (Ln7) t = loader.get_template('home/index.html')
(Ln8) c = Context({'latest_home_list': latest_home_list,}) (Ln9) return HttpResponse(t.render(c))
The next step was to create a directory in the myproject folder called ‘mytemplates’. In here, a further 7 folders were created for each part of the user interface (1 for main page, 1 for classlist, 1 for messages etc). The templates that were created were organized into these 7 folders.
The first 3 lines of the code above import Django modules which are required for this views.py to work. Ln7 loads the template index.html located in myproject/mytemplates/home/index.html. In this file, html code was written by the author as to what the main page should display.
In summery of views and templates, a view is a python module which is required for each part of the user interface. The view has a line of code which loads a html template where the code is written as to what the
page should display. For example, each of pages of the user interface requires links that take a user to the other pages of the interface. To implement this, the code in Appendix E Figure A was inserted into all of the templates that were created. This is required so that every page on the interface remains consistent. To complete the Main page, the author coded into the html template, an introduction to the prototype system which is displayed in the page. The main page is now complete and will display if the following link (http://81.102.100.206/home/) is clicked (and if the Apache server is running on the authors PC) [See Appendix E Figure B for a screenshot of the finished Main page.]
6.3.2 Implementation of the Classlist, Lectures and Messages pages
This section will outline how these three pages were implemented. The reason why these three are together in this section is because the implementation of them was very similar. The process of coding the method (shown above) into views.py of the home folder was repeated for the views.py modules in the classlist, lectures and messages folders. (Remember that each folder has a views.py module). Appendix E Figure C shows this code. The next step of implementing these onto the user interface was to create a template for each page. The main page didn’t require any data to be displayed, but for these three pages the author requires a list of all the students that have been added in the AAI to be displayed on the classlist page. On the lectures page the author requires a list of all the lecture information and lecture notes that have been added in the lectures AAI to be displayed and similarly, on the messages page the author requires the messages that a teacher adds in the messages AAI to be displayed. To do this, the author wrote some code in each template so that the data does display on their respective pages on the user interface. The code extract below shows what was inserted into the lectures template;
(Ln1) {% for LectureNote in latest_lect_list %}
(Ln2) <ul><li><table width="1091" border="1">
(Ln3) <tr bgcolor="#FFFFCC">
(Ln4) <td width="226"> {{LectureNote.lecture_number}} </td>
(Ln5) <td width="226"> {{LectureNote.lecture_title}} </td>
(Ln6) <td width="226"> {{LectureNote.lecture_date}} </td>
(Ln7) <td width="385"><a href="{{LectureNote.lecture_notes}}">DOWNLOAD NOTES</a></td>
(Ln8) </tr></table> (Ln9) {% endfor %}
Ln1 of the code extract, looks to see if there is any data in the lectures table. If there is none, then the lectures page on the user interface displays no data. But, if a lecture information and lecture note has been added by a teacher in the lecture AAI, Ln4 to Ln7 (inclusive) will display the details that were entered into the fields (i.e. the lecture number, lecture title, lecture date and the uploaded lecture notes) by the teacher. Ln7 specifies a hyperlink that allows a student to download a file (such a PowerPoint presentation) that has been uploaded by a teacher in the lecture AAI. This code extract was inserted into the templates of the classlist and messages pages also. The fields in Ln1 and Ln4 to Ln7 were modified so that the correct data
displays on the correct page. (For example, in the classlist template, the fields such as firstname, surname etc should be included). [See Appendix E Figure D)
A strong point of Django is the templating system which allows whatever data is entered into the AAI to be displayed onto the corresponding page of the user interface. For example, in the classlist AAI a teacher adds students to the classlist. These students’ details would then be displayed onto the classlist page of the user interface. An advantage is that what is displayed on the page can be controlled by the teacher in the AAI. So if the student does not take that class anymore, he/she is deleted in the AAI and therefore would not be displayed on the classlist page of the user interface.
The classlist, lectures and messages template files were coded so that the layout (eg. links to other pages are at the top) and colour scheme were the same as what was implemented in the Main page template. The classlist, lectures and messages pages of the user interface are now completed. [See Appendix E Figure E, F and G for a screenshot of these pages.]
6.3.3 Implementation of the Questions, Blog and Poll pages
The implementation of these pages on the user interface differs slightly to those mentioned in the previous section. The classlist, lectures and messages pages each have only 1 template that displays the data that is added in by a teacher in the AAI. The questions, blog and poll pages go a little further then these as they require more then 1 template to be coded. The code extract in section 6.3.1 illustrates a method that needs to be inserted into the 7 views.py module [Appendix C Figure C]. As the questions, blog and poll pages require more then 1 template, there respective views.py modules require a number methods to be implemented (similar to the code extract in section 6.3.1). In the views.py module for questions, the following methods were inserted into the module;
def index(request): latest_quest_list = CourseQuestion.objects.all().order_by('pub_date') t = loader.get_template('questions/index.html') c = Context({ 'latest_quest_list': latest_quest_list,}) return HttpResponse(t.render(c))
def detail(request, CourseQuestion_id):
p = get_object_or_404(CourseQuestion, pk=CourseQuestion_id)
return render_to_response('questions/detail.html', {'CourseQuestion': p})
The index method loads the index.html template (i.e. the first page of the questions section) [Appendix E, Figure H]. This page displays a list of all the set of topic questions that have been added by a teacher (For example, questions have been added about python, java and databases). The detail method in the code extract above loads a second template that displays the second page of the questions section. The second
page displays a list of questions for a specific topic. Appendix E, Figure H shows the topic questions python and database listed on the first page. When the python topic is selected, a second page; the detail.html is loaded which displays a list of questions and useful links about python [Appendix E, Figure I]. The detail.html template was coded in a similar approach to the index.html template. The code is shown in Appendix E, Figure D. The question pages implementation is complete and the final thing to mention is that the colour scheme and text styles used on all of the other pages of the user interface have implemented in the questions pages, so that there is consistency in the look and feel of the user interface.
The Blog pages were implemented (the views.py and the templates) in a similar way to the questions pages. The Blog required 4 pages to be implemented. The first page displays the titles of the postings added by a teacher [Appendix E, Figure J]. If a title link is clicked, a second page displays which lists the comments that have been made by students regarding this posting [Appendix E Figure K]. At the bottom of the second page, a short form (Figure 1.5) is provided by Django that allows a student to enter in their comments.
Figure 1.5 – Comments form
Once the comments have been entered, the preview comment button is clicked, which displays the third page [Appendix E, Figure L]. This page allows a student to check their comment and make changes if necessary before it is posted to the public. After the comment is posted, a fourth page is displayed which thanks the person who entered the comment and links them back to the second page which has all the comments displayed. The student should now be able to see the comment he/she just posted [Appendix E, Figure K]. The blog pages implementation is complete and the final thing to mention is that the colour scheme and text styles used on all of the other pages of the user interface have implemented in the blog pages, so that there is consistency in the look and feel of the user interface.
The poll pages were the final pages of the user interface to be implemented and they were developed in a similar approach to the questions and blog pages. The poll section requires 3 pages to be implemented.
The first page displays the different polls that have been added by the teacher. They were displayed in the same approach as the questions first page in Appendix E Figure H. A poll is added by a teacher so that he/she can get feedback from the students. (For example, a poll question may be, “What did you think of the coursework?” The choices for the students may be “too easy”, “difficult” and “too hard”). Once a poll was selected on the user interface, the choices for that poll were displayed [Appendix E, Figure M]. This allows a student to vote in the poll by selecting a choice and clicking on the vote button. The final page would display the results of the poll (i.e. how many votes each of the choices received). [Appendix E, Figure N]. The poll pages implementation is complete and the final thing to mention is that the colour scheme and text styles used on all of the other pages of the user interface have implemented in the poll pages, so that there is consistency in the look and feel of the user interface.
All of the pages of the user interface have now been implemented using the blueprints made in the design stage. The next stage is to carry out the testing of the user interface.