Python Web Application Development using Django

SolarPV Project

Introduction
We now gone through the full cycle in our Python web application development using Django. We’ll now put all the components together, test, and deploy.
Here are the different scenarios.

 

SolarPV Project
Your homepage is similar to the diagram provided in PD2.

Public Interface
a. When a user clicks on “Testing & Certification” on the left hand site, a new page should open that allows the user to search a certificate by certificate number or a keyword.

If you enter the keyword “solaria” in the search box, a list of certificates with this keyword is displayed with links to open specific certificates.

If you enter a specific certificate number in the search box, such as “CA 72180017”, information about that particular certificate will be displayed.

 

b.User Registration
Any user should be able to Register with the portal.

Web Portal
A registered user can be either a staff or a client.
When a registered user logs in, 
a. If it is a client, he/she should simply be directed to the home page as we’ll not implement the client portal at this time.
If it is a staff, he/she should be directed to a Dashboard. From the dashboard, the staff should b.be able to perform CRUD (create, retrieve, update, delete) operations on the following entities:
Client
Location
Product
Test Standard
Certificate

SynerD Project
Your homepage is similar to the diagram provided in PD2.

 

Public Interface
a. When a user clicks on “Members”, a new page should open that allows the user to search a subscriber by ID or a keyword. Note that a subscriber can be an individual or an organization.

Refer to the link below for an example page listing all member organizations However, your application should also be able to list information about an individual subscriber, not just organizations. 

b. User Registration
Any user should be able to sign up with the portal.

 

Web Portal
A registered user can be either a staff/officer or a non-officer subscriber.
When a registered user signs in, 
a. if it is a non-officer subscriber, he/she should simply be directed to the home page as we’ll not implement the client portal at this time.
If it is a staff/officer, he/she should be directed to a Dashboard. From the dashboard, the staff/officer should be able to perform CRUD (create, retrieve, update, delete) operations on the following entities:

Office
Officer
Organization
Organization Member
Subscriber

futche Project
Your homepage is similar to the diagram provided in PD2.

 

Public Interface
a. When a user clicks on “Scholarships”, a new page should open that allows the user to search available scholarships by ID or a keyword. If no keyword is provided, the list of all available scholarships should be displayed. The result should be in a tabular format that provides scholarship ID, denomination, referred studies, amount, description, and criteria.

 

A registered user can be either a Donor, a Parent, or a student (aka potential scholarship applicant). Note that a student must first register his/her parents before registering him/herself.

When a registered user signs in, he/she should simply be directed to the home page as we’ll not implement the client portal at this time. 
Using the Django Admin page, a staff person  should be able to perform CRUD (create, retrieve, update, delete) operations on the following entities:

School
Scholarship
School Tuition & Fees
Student Scholarships

Features

 

The Public Interface
The Public Interface must be serviced through a RESTful API.

 

Dashboard
The Dashboard can be designed using the Django Admin site.

 

We want to customize our interface to:
Add additional fields/information displayed for each record: You can use list_display to add additional fields to the view.

Add filters to select which records are listed, based on date or some other selection value: You filter which items are displayed by listing fields in the list_filter attribute

 

Choose which fields to display (or exclude), along with their order, grouping, whether they are editable, the widget used, orientation etc.: The fields attribute lists just those fields that oare to be displayed on the form, in order. Fields are displayed vertically by default, but will display horizontally if you further group them in a tuple.

 

Sectioning the detailed view: You can add "sections" to group related model information within the detail form, using the fieldsets attribute.