Iteration 2 Plan - GToidZ/ku-polls GitHub Wiki

Goal

Add functionalities to KU Polls, exclude sensitive configuration from the repository, further improve the look and experience of the application and automate tests using Continuous Integration (maybe in future iteration).

Features

  1. A poll needs an end date or closing date, such that polls cannot be voted anymore after the date.
  2. Users can directly go to the results of a poll from the homepage.
  3. The application has a better look and user experience.
  4. Administrators can edit polls' choices and modify ending dates.
  5. Administrators can configure server's variables using an external file.

Milestone

  1. Application development - develop a web application with Django.
    1. Each poll has an end date which polls are closed after that date. (End date implementation, Model modification)
    2. Administrators can edit polls' choices and modify ending dates. (Admin page modification)
    3. Administrators can configure server's variables. (Config decoupling implementation)
  2. UI/UX design - design UI/UX for a web application and implement into the project.
  3. Code review - review, fix and document project's source code respecting style guides and standards.
  4. Iteration 2 - completing iteration two with deployable application.

Acceptance Criteria

  1. Polls closing (not being able to vote) after the end date.
  2. Links lead to correct pages.
  3. All tests passing.
  4. User experience is smoother than before.
  5. User interface is more beautiful.
  6. Everything works (deployable) on the iteration2 branch and must be merged into master.

Retrospective

What went right?

The second iteration was successfully implemented with all the requirements that are functionalities.

The migration of models with new attributes went fine and database reading/writing works perfectly.

The interface improved from the first iteration. (I think it looks much better)

Navigation on site is better, all views are connected in every page, redirects are available in suitable places.

Everything works on deploy.

What went wrong?

This second iteration required some test suites to be modified, which is not ideal.

Most of the time wasn't spent on backend but, actually making an HTML template that works. Currently, the HTML for Details view is a mess and required another HTML file which has a lot of CSS manipulation. If I can use other templating engine like Jinja2, that would save much lines of HTML (using {% macro ... %}).

What has been learned?

Django filters are a great way to manipulate variables that gets passed from HTTP request and Django's objects, you can also create them yourselves! (Check polls/templatetags)

Django has {% include ... %} tag that allows us to include a partial HTML snippet to another HTML file. (That's how I created bars in voting results.)

Django's templating is great, but has a flaw, is not being able to have another tag inside another tag syntax. Though, we can make a workaround with tags like: {% with ... %}, {% include ... %} etc. (We can also create our own tag if they don't have what we want.)

Unittest's mock patching is now my favorite testing tool.

How to improve in next iteration?

  • Issues are too broad, they should be more specific on each tasks.
  • Propose Jinja2 as templating engine rather than Django's. (unlikely)