Forem: Jonathan Farinloye

Models, Views, Templates - Lesson 5

Jonathan Farinloye — Tue, 25 Jun 2019 09:09:27 +0000

Introduction
Templates to Views to Models
Displaying From Models

Introduction

In the last article, we discussed how we can create a blog model in our blog app. This model contained a title, a cover image, a date field, a content field, and a slug field. Out of all these fields, we would be working on and interacting with the title, cover image and content fields. We would also be setting the date field to be automatically set to the date of the last update to our blog post, and the slug to be automatically set based on the title. I think that's a nice place to start. 🤔

Move over to your blog/models.py file and edit the field called raw_date. Also add the save function to the class.

# blog/models py
from django.template.defaultfilters import slugify # a django module to take care of creating slugs
class Blog(models.Model):
...
    raw_date = models.DateTimeField(auto_now=True)
...
    def save(self, *args, **kwargs):
        self.slug = slugify(self.title)
        return super(Blog, self).save(*args, **kwargs)
...

The parameter auto_now, when set to True, automatically sets the date to the latest date every time the model is edited and saved.
Note also, the function we added must be named save for this to work, because it, for lack of the right word, extends the original inbuilt save function.

Do not forget to makemigrations and migrate your changes. Feel free to also test it to make sure it works. If you check the admin site, you would not find the date field anymore. This is because it is being automatically set.

Date was eaten by a hungry squirrel 🐿️

Templates to Views to Models

Don't get confused by the long heading. It's not that serious really 😉. Or is it 🤔? Just kidding. On a more serious note though, our main goal is to allow blog posts to be created from the frontend and to do this, we basically need just a form that has the fields of the model we created, with an exception of the automatically populated fields (I was going to say filled fields). So we need to create an HTML file that would hold the form (We really aren't bothering about the styling now. Feel free, though, to style however you want).

Move over to your blog app and create a templates directory if you don't already have one. Next, create a file, I'd name mine add-blog. So, blog/templates/add-blog.html. Let's move over to our views.py and create the function for our add a blog page.

...
# blog/views.py
from django.shortcuts import render, redirect
...
def add_blog_post(request):
    return render(request, 'add-blog.html')

For now, we'd just return the html document

We need to create a urls.py file inside the blog app and link the file to the main urls.py inside the awesome directory.

# blog/urls.py
from django.urls import path
from . import views

urlpatterns = [
    path('add-post/', views.add_blog_post, name='add-a-post')
 ]

In awesome/urls.py

# awesome/urls.py
...
from django.urls import path, include
...
    path('counts/', views.counter, name='count-vowels'), # Don't forget this comma
    path('blog/', include('blog.urls'))
...

The new line includes the blog/urls.py file in the recognized urls.

Now, go back to your html file and create the form.

<!-- blog/templates/add-blog.html -->
...
<form action="{% url 'add-a-post' %}" method="POST" enctype="multipart/form-data">
    {% csrf_token %}
    <label for="title-field">Title</label>
    <input id="title-field" name="title" type="text">
    <br><br>
    <label for="cover">Cover Image</label>
    <input id="cover" name="cover-image" type="file">
    <br><br>
    <label for="blog-content">Content</label>
    <textarea id="blog-content" rows="20" cols="30" name="content"></textarea>
    <br><br>
    <input type="submit" value="Post">
</form>
...

Don't forget to include your csrf_token, else it won't work

Please style if you can. This thing is ugly.

Now, go to blog/views.py and let's make changes to the function.

# blog/views,py
...
from .models import Blog
...
def add_blog_post(request):
    if request.method == 'POST':
        blog = Blog()
        blog.title = request.POST['title']
        blog.cover = request.FILES['cover-image']
        blog.content = request.POST['content']
        blog.save()
        return redirect('home')
    return render(request, 'add-blog.html')

Note: This fetches the information from the name given to each of the fields, meaning if you don't give it a name, accessing the information might be difficult.

When we run blog.save(), a blog post is created with the given information. Save your code, and test it. Login to the admin site and confirm that it saves.

Displaying from Models

Currently when a blog post is created, we redirect the user to the home page. Not so ideal. We would want to redirect the user, however, to a page that lists all out posts. To do this, we need a page, a function and a new url entry.

blog/views.py

# blog/views.py
...
def all_posts(requests):
    posts = Blog.objects.all()
    return render(requests, {'all-posts': posts})
...

blog/templates/all-posts.html

<!-- blog/templates/all-posts.html -->
...
<body>
{% for post in all %}
    <h3>{{ post.title }}</h3>
    {{ post.date }}
    <br>
    {{ post.content }}
    <hr>
{% endfor %}
</body>
...

blog/urls.py

# blog/urls.py
...
urlpatterns = [
    path('add-post/', views.add_blog_post, name='add-a-post'),
    path('all-posts', views.all_posts, name='all-posts')
 ]
...

This are all the changes made and their respective files. And just like this, we are able to access and display our blog posts on the frontend.

I'd want you to, in your own free time, extend the blog model. Try adding categories using the ManytoMany field. We'd be extending the model and possibly dealing with user accounts soon.

One thing to note is, there are other ways to handle forms in Django. This is one, and not the only way. Feel free to check around for other methods and possibly try them too. 🦉. Stay safe. Be nice. Enjoy your day.

Models - Lesson 4

Jonathan Farinloye — Fri, 21 Jun 2019 08:38:50 +0000

Models
Creating Models
Registering Models

Models

We can describe models as representations of real-world data or objects. For example a blog post. If we are to build a model around a blog post, we could have a title, the date of publishing, maybe a cover image, definitely the body of the post. Let us work with this and see how we can model these bits of information.

As you might have thought, since we are talking about the blog, we would be working inside the blog app now. And since we are dealing with creating models, we would be working with the models.py file.

However, before creating the model, let us edit our settings.py file to prepare our Django project to accept media files, in this case, the cover image. Move over to settings.py file, and at the bottom add:

123. MEDIA_ROOT = os.path.join(BASE_DIR, 'media/')
124.
125. MEDIA_URL = '/media/'

MEDIA_ROOT is set to a folder named 'media' inside the base directory of the project. While the MEDIA_URL is what URL would be used to access media files.

Creating Models

Models are similar to objects. Well, they are actually objects and creating them looks like this:

1.  from django.db import models
...
...
4.  class Blog(models.Model):

You can read more about Django models here.
You can also give it another name asides Blog, but since we are dealing with the blog app, this name is reasonable.

In our model we need:

A field for post Title
A field for Date
A field for Cover image
A field for post Content

The Django site gives us quite a lot of fields that we can use in our objects. Searching through the site, we find some we might need.

CharField for the title
DateTimeField for the dateeverytime
ImageField for the cover image
TextField for the post

Let us create our model and see how it looks:

4. class Blog(models.Model):
5.     title = models.CharField(max_length=50)
6.     raw_date = models.DateTimeField()
7.     cover = models.ImageField(upload_to='images/')
8.     content = models.TextField()

The title is set to models.CharField, and the max_length attribute is set to 50 characters. The max_length attribute is a required argument for the CharField.
The DateTimeField and the DateField fields require no positional argument. However, it could take some optional argument, such as auto_now which sets it to the current date and time every time the model is updated. You can find others here.
Also to format the date in a more presentable format we could use strftime. To do that we would be adding a function to our object.

10.     def date(self):
11.         return self.upload_date.strftime('%b %d, %Y')

As explained on the site, this formating method %b %d, %Y,would give a result like Jun 12, 2019 or Nov 13, 2019.

The next field is the TextField which is used for the content. We use a TextField and not a CharField because TextField is designed for long text content. If yoy remember, we said CharField requires a max_length attribute. This attribute isn't required by a TextField.

Your models.py, at this point, should look like:

1.  from django.db import models
2.  
3.
4.  # Create your models here.
5.  class Blog(models.Model):
6.      title = models.CharField(max_length=50)
7.      raw_date = models.DateTimeField()
8.      cover = models.ImageField(upload_to='images/')
9.      content = models.TextField()
10.      
11.      def date(self):
12.          return self.raw_date.strftime('%b %d %Y')

Registering Models

This is what our admin site looks like now
To register a model we have created is to make it 'show up' in the admin site so we can add content and edit content. To register a model we open the admin.py file inside our blog app and add a few lines.

1. from django.contrib import admin
2. from .models import Blog
3. # Register your models here.
4. admin.site.register(Blog)

This registers the model named Blog, on the admin site.

Refreshing the admin site shows the Blog Model

However, if you try clicking on the Blog section, you get an Operational error.

The exception value is 'no such table blog_blog'. This might tell you that it's a database problem. Remembering something we learned in an earlier section about databases, we need to migrate the changes we have made to the models.py file. Almost all changes to models.py would require migrations before moving on. To do this, open your terminal, makemigrations and then migrate.

/awesome-project$ python manage.py makemigrations

and then:

/awesome-project$ python manage.py migrate

Note: A migrations folder is automatically created inside the blog directory. Never delete this folder as it could cause serious issues for your app and database. Speaking from experience 😵. It's fixable though, just in case you're curious. 😉

Loading the admin site and checking the Blog opens a page that shows we have 0 Blog posts. Click on the add button to add a post.

Shows all the fields we created. 🍉 for you

Saving the new post, we see it named a "Blog object (1)". We don't want this. To adjust this we another function:

14.     def __str__(self):
15.         return self.title

This change doesn't require migrations. If you attempt to migrate, it says 'No changes detected'.

If you check the blog app in the admin site now, you would see that 'Blog object (1)' has changed to the title of the blog post.

What the Blog app looks like

We can leave this page as it is, but to make it easier we could do a bit of customization. Open your admin.py file and edit it to look similar to this:

1.  from django.contrib import admin
2.  from .models import Blog
3.  # Register your models here.
4.
5.
6.  class BlogAdmin(admin.ModelAdmin):
7.      list_display = ('title', 'date', 'cover')
8.      search_fields = ['title', 'content']
9.    
10.
11.  admin.site.register(Blog, BlogAdmin)

Refreshing the blog app, we see a new look.
Now includes date, link to image, as well as a search bar

One last thing we would do is add a slug field. To do this, we first add a new field to our model:

5.  class Blog(models.Model):
6.      title = models.CharField(max_length=50)
7.      raw_date = models.DateTimeField()
8.      cover = models.ImageField(upload_to='images/')
9.      content = models.TextField()
10      slug = models.SlugField()

You could set a max_length attribute for the SlugField or not. If you don't set it, Django used 50 by default. The next thing we would do is set the slug as a prepopulated field. This would automatically set the slug based on one or more other fields. We want our slug to depend on the title so in admin.py we add a new line to the class:

1.  from django.contrib import admin
2.  from .models import Blog
3.  # Register your models here.
4.
5.
6.  class BlogAdmin(admin.ModelAdmin):
7.      list_display = ('title', 'date', 'cover', 'slug')
8.      search_fields = ['title', 'content']
9.      prepopulated_fields = {'slug': ('title',)}
10.
11.
12. admin.site.register(Blog, BlogAdmin)

Line 8 set the slug as a 'prepopulated' field that depends on the title. We also added slug to the list display to see what our slug is. If you attempt to makemigrations now (due to adding a new field), Django would give you 2 options, either provide a one-off default for already existing rows or quit and set a default in models.py. This is why it is better to completely build our model before adding objects to the database.
To move forward from this issue, we can quit and set a default in the models.py.

10.     slug = models.SlugField(default='random-text')

Make the migrations again, migrate, then go to the already existing blog post, tweak the name a bit(you could add a space and remove it 😉)Just to trick the system to automatically set the name. Once done, save and check that everything works. When you're done, you can remove the default attribute in the SlugField, makemigrations and migrate again (It won't make much sense if multiple blog posts have the same slug🤷🏾‍♂️🤷🏾‍♀️).

You can read more about customizing the Django ModelAdmin here. In the next article, we would be seeing how we can add blog posts from the site, without going into the admin site.
Project can be found here
There would be no articles over the weekend. Play around with what you've learned and use it to create something nice. Enjoy your weekend
Until then, 🍊🍎🍍

Cheers ✨✨

Views - Lesson 3

Jonathan Farinloye — Wed, 19 Jun 2019 21:22:44 +0000

In this lesson, we would be discussing further uses of the views.py file other than just returning an HTML page. To do this we would be building a small app while we make a few changes to the way our current homepage is displayed.

Changes to Make

Currently, our Homepage is served from the blog app, but we should honestly leave the blog for only blog related things. Meaning we have to move our homepage out, probably to the root directory. The first thing we would do is create a folder called templates in the awesome-project directory. Second, move the home.html file to this newly created folder.

Next, go to settings.py. Around line 55, we see TEMPLATES. Inside the list of DIRS add 'templates', which is the name of the templates folder we created.
So, my line 58 looks like:

    58.        'DIRS': ['templates'],

Next, we create a views.py file inside the awesome directory. and copy the content from the views.py inside the blog directory. You can go ahead and delete the function we created in the previous views.py. And make appropriate changes to the views.py inside the awesome directory.

    1. from django.shortcuts import render
    2.
    3. # Create your views here.
    4. def home(request):
    5.     return render(request, 'home.html')

This should be inside awesome/views.py

One more change we should make, assuming I'm not missing anything out, is to the awesome/urls.py file. Instead of having:

    18. from blog import views

We now have:

    18. from . import views

This means - from this directory, import views.

Save all files, run your server and make sure your home page still displays. If it does, let's move on.

It's not yet time for a carrot 😏.

Views.py

So to dive into this, we'd be adding a form to our home page that counts the number of vowels in some text. It's a good practice to highlight what would be needed. Thinking of this problem and what we have learnt so far, we would be needing:

A form that we use to collect user input;
A function that counts the vowels;
A page that we return the number of vowels to.

So let us start with no. 1. Adding a form. For the sake of simplicity, we would be adding it to the homepage.

    <form method="POST" action="">
        <textarea name="input-stuff" rows="10" cols="30"></textarea>
        <button type="submit">Check vowel count</button>
    </form>

So, here's what my form looks like. Notice I have a method and action on the form tag and a name on my textarea tag. The method is POST because it's a POST request. The action is the url that should be triggered when the button is clicked. We would get back to it. Let's go create our function.
No. 2
We'd be naming our function counter. and it would look like this:

       # awesome/views.py
    8. def counter(request):
    9.     if request.method == 'POST':
    10.         vow = 0
    11.         for i in request.POST['input-stuff']:
    12.             if i in 'aeiou':
    13.                 vow += 1

Most of this code might look familiar, except line 9 and line 11. Line 9 checks if the request method is a POST. A POST request is basically used when sending certain information to the server. Usually from a form. Line 11, on the other hand, is used to access the information inputted in the textarea. Remember that we named the textarea input-stuff. Well, this helps to access it. One thing we must not forget is that our function must always return something. If it doesn't we would most likely get error 500. So the question is: what do we return? Simple. A page to display the result.
No. 3
Let's create an HTML file called count in the templates directory. We would be back to what should be inside it in a few. Okay... That's a lot of things on hold.

Action in the form tag.
A return statement in the counter function.
The content of the count.html file
The url that would lead to the counter function.

Let us handle the view.py first. We need a return statement. Our return statement would return the page and a bit of extra information: the number of counted vowels. How do we do this? Well:

    8.  def counter(request):
    9.      if request.method == 'POST':
    10.         vow = 0
    11.         for i in request.POST['input-stuff']:
    12.             if i in 'aeiou':
    13.                 vow += 1
    14.         return render(request, 'count.html', {'count': vow})

Okay. Wait a minute. We recognize that last part {'count': vow} as a python dictionary. So we could use this to pass extra information back to the page that we are also returning; in this case, the count.html page.
One thing we should also address if someone tries to visit the count.html page without going through the home page. Let's just set it to send them to the homepage. For this, we would need to import redirect.

    1.  from django.shortcuts import render, redirect
    ...
    ...
    8.  def counter(request):
    9.      if request.method == 'POST':
    10.         vow = 0
    11.         for i in request.POST['input-stuff']:
    12.             if i in 'aeiou':
    13.                 vow += 1
    14.         return render(request, 'count.html', {'count': vow})
    15.     return redirect('home')

Line 15 gives us what we are looking for. Meaning, if the request isn't a POST request, it would not encounter the first return statement and would move to the next. The return statement on line 15 says: redirect the user to a url with the name of home. We use the url name, not the html file. Note.

Now, let us move to creating the url. Move over to your awesome/urls.py file, let's add another path.

    20. urlpatterns = [
    21.     path('some-random-text/', admin.site.urls),
    22.     path('', views.home, name='home'),
    23.     path('count/', views.counter),
    24. ]

New path is on line 23. If the comma at the end of line 23 is missing, we would face issues.

This shouldn't be strange. Remember to add a comma to end of every closing bracket. You might also notice that I didn't add a name to the count url and we would get to that shortly.
Now let's go to the home.html file and make one minor addition. We would add the action, which would be the url, which is /count/. And then we head over to count.html and add some strange stuff to the body:

    <h3> Vowels Counted - {{ count }}</h3>

This definitely isn't regular html. However, Django allows us to access the contents of the dictionary we returned using this syntax.i.e.

{{ dictionary_key_name }}

Now run your server and check if your code runs.
Mine doesn't 😫😩. However, because DEBUG = True in settings.py, we see the error has to do with CRSF verification failed. Well Django requires that for every form, there is a

{% csrf_token %}

CSRF stands for Cross Site Reference Forgery. You should read a little about it.

To prevent againt CSRF, a token is generated on every form submission. So let's go add it:

    <form method="POST" action="">
        {% csrf_token %}
        <textarea name="input-stuff" rows="10" cols="30"></textarea>
        <button type="submit">Check vowel count</button>
    </form>

Now save, and try again. Ding! Ding!! Ding!!🛎🛎🛎😁😄
Mine works! If yours does, 🍓🍓 strawberries for you.

Awesome work, . You're the best

One final thing is to test what happens when we change the url from count to counts in the urls.py file.

    20. urlpatterns = [
    21.     path('some-random-text/', admin.site.urls),
    22.     path('', views.home, name='home'),
    23.     path('counts/', views.counter),
    24. ]

404 error just by changing count to counts
Trying again, we get a 404 error, because the url changed. To combat this e could use the name of the url. So add a name to the count url.

    20. urlpatterns = [
    21.     path('some-random-text/', admin.site.urls),
    22.     path('', views.home, name='home'),
    23.     path('count/', views.counter, name='count-vowels'),
    24. ]

Now go to home.html and make your opening form tag similar to:

9. <form method="POST" action="{% url 'count-vowels' %}">

Only the action changed to what is known as a template tag. This basically says: search all the urls we have and see if there's any with the name count-vowels. If there is, that is the url we want. And so that works.

As we have seen, the views.py file controls a number of things. This isn't all we can use it for. We would also be talking about models and how we can upload images, maybe a profile picture.
This would be the end of today's article. I know we've been eating fruits, but here 🍩🍿🍫🍪, give yourself a tasty treat if you choose to. Cheers.

I almost forgot the carrot, here 🥕🥕.
Project can be found here
Cover image by yabayee from Pixabay

Moving Forward - Lesson 2

Jonathan Farinloye — Wed, 19 Jun 2019 07:04:23 +0000

Get Familiar
Database
Apps
Homepage

Get Familiar

I believe you either have a Python IDE or a code editor. I use Pycharm. Many people like VS Code. If you don't, go and download one before moving on.

Hoping you have a Code Editor now, open your project in your editor. You might want to get familiar with the files and folders in your project.

Some really random files and stuff
You might recognize the 'manage.py' file, as it was the one we used when we wanted to run the server. You should have a file named 'db.sqlite3'. This is the database file. It was automatically generated when we run the server. Other database services could be used - like Postgres, MySQL. However, we'd be working with the default. Later on, we could discuss setting up a Postgres Database.

There is the '__init__.py' which just identifies the 'awesome' directory as a group of python files, or what we can call a module. The 'settings.py' file contains the settings for our Django project. We'd be diving into it as we move on.

A section of settings.py showing Database settings
Then, we have 'urls.py' which contains the URLs that our site would make use of. If you view it now, you see some comment and then one 'urlpattern', which is:

urlpatterns = [
    path('admin/', admin.site.urls),
]

If you run your server now, make sure your virtual environment is active. Remember, to run the server:

/awesome$ python manage.py runserver

And then visit 127.0.0.1:8000/admin, you should see a sign in page that looks like:

Eat an apple for getting this far 🍏
Lastly, we have the 'wsgi.py' file.

The Web Server Gateway Interface (WSGI) is a simple calling convention for web servers to forward requests to web applications or frameworks written in the Python programming language. From Wikipedia

In case you're curious, you would find extra information online. However, we won't be toying with this file much. I doubt we'd ever touch it.

Before moving forward, we'd be renaming the folder up-top to 'awesome-project' so as to differentiate it from the one that contains the 'urls.py' and other files.

Renaming the wrong one would break everything😭

Database

The database is, well the database. Stores information, data and a whole bunch of things. The first task we would be performing with the database is creating a 'superuser'. A superuser has 'ultimate level access' to the entire project. Make sure you're careful with your superuser account. To create one, run:

/awesome-project$ python manage.py createsuperuser

If you do this at this point, you would get a bunch of errors. Well, that's because the database hasn't been prepared to receive the information. Django has a nice way of managing the databases with its migrations. If a change that should be reflected in the database is performed, Django requests you to 'makemigrations' and then 'migrate'. Unapplied migrations always show up. Similar to:

You have 17 unapplied migration(s). Your project may not work 
properly 
until you apply the migrations for app(s): admin, auth, contenttypes, 
sessions.
Run 'python manage.py migrate' to apply them.

To makemigrations, run:

/awesome-project$ python manage.py makemigrations

If changes are detected, it prepares it for migration.

To apply the migrations, run:

/awesome-project$ python manage.py migrate

You get something like:

Operations to perform:
  Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying sessions.0001_initial... OK

This means you have successfully migrated your changes.
Now, try creating your superuser again

/awesome-project$ python manage.py createsuperuser
Username: we-awesome    
Email address: hello@awesome.us
Password: DjangoPass
Password (again): DjangoPass
Superuser created successfully.

Note: I strongly advise you set a strong password. I'm only using this because it's for a tutorial. In real life projects. A strong password and a real email address are essential.

Now run your server again, visit the admin page via 127.0.0.1:8000/admin and login with your details.

Another apple for you, or maybe an orange🍊

One thing you should know is, you can change the link to the admin page. so if you want to change it from 127.0.0.1:8000/admin to 127.0.0.1:8000/some-random-text, just go the urls.py file and change it.

Previous and current line 20

Visiting 127.0.0.1:8000/some-random-text opens the admin page; Visiting 127.0.0.1:8000/admin gives a 404 error

Apps

So what's the difference between a project and an app 🤔? Imagine a company with different teams. A marketing team, to well, market. A design team, you're on the development team. Your best friend is on the administration team and so on. Apps could be likened to the individual teams, while the project is like the company. We could create a 'blog' app to manage blogging issues. We could have a 'profile' app to manage user profiles and so on.

Let us create a 'blog' app.
To create an app. Open your terminal in the awesome-project directory. Make sure your virtual environment is active, then run:

/awesome-project$ django-admin startapp blog

As usual, you can give it another name.

I'm quite sure it worked✨✨! If not, 😟 review what you did and kindly tell me what went wrong.

Creating the app also creates a bunch of files that we haven't seen before.

That's a lot of strange stuff😕

As we move forward and encounter them, we'd discuss what they are.

We also need not forget to register the app in the settings.py file. (Actually, I forgot to register it as at the time of writing😬) To do this, open the apps.py file inside your 'blogs' directory and copy the name of the class. In my case, it is BlogConfig. Now go to settings.py. Scroll till you see INSTALLED_APPS. A number of apps are there by default, however, we want to add a new one which is BlogConfig. Add a Comma after the last line before the ']', move to the next line, and add:
40. 'blog.apps.BlogConfig'

blog - the name of the folder/app; apps - the name of the file; BlogConfig - the name of the class.

Please don't forget as I did.😬😬

Homepage

The last thing we would consider in this lesson is how to change the default homepage. By this, I mean the page that shows up on visiting 127.0.0.1:8000. To do this, we need to create a template, an HTML file.
Let us use our blog app. Create a new folder inside the blog folder and name it 'templates'. You could create your HTML file directly into this folder or further add subdirectories to organize the files. Either way is fine. (Edit: As an example, I created a main-site subdirectory in the templates directory. And that would reflect in my views.py.)

You can see both the folder arrangement and the placement of the HTML file.

Now the question is: How do I get this file to display? This is where we visit the view.py file alongside urls.py.

This is a quite skeletal representation
This isn't everything that happens, but this is all we need for now. So let's follow the image. The user's request takes a plane 🛬 and lands in the 'urls.py' file. On getting there, it checks if the url exists. One thing you should know is our 'urls.py' file deals with only the suffix. i.e It doesn't include the 127.0.0.1:8000 in itself. So keeping that in mind, if we want to replace the default home page, we add one line to 'urls.py'.

20. urlpatterns = [
21.     path('some-random-text/', admin.site.urls),
22.     path('',)
23. ]

The newly added line says when they input the prefix(127.0.0.1:8000) without any suffix, come to me. The second box in our image says we should run the specified function in views.py. Which means we have to create a function that returns something. And the question is what do we want to return? The HTML file. So let's go create our function. In views.py, create a function, name it. It takes in at least one argument, which we would name request. And then returns the render of the HTML document on the URL that was requested. I know it's sounding confusing. Get a pen and paper, draw the different sections and try linking them up. My function looks like:

4. def home(request):
5.     return render(request, 'main-site/home.html')

The views automatically check the templates folder as the base directory of all HTML documents. Now to add the view to our url path, we first have to import it into the urls.py file. At the top of the file, add:

1. from blog import views

This imports views from the blog app

And in the url path we added earlier, add some extra information

20. urlpatterns = [
21.     path('some-random-text/', admin.site.urls),
22.     path('', views.home)
23. ]

This invariably says that when you open the link; prefix with an empty suffix; run the function named home, which you would find in the views file.

It is also a good practice to give names to your url's, as you would be referencing them a lot in your HTML documents. To add a name:

20. urlpatterns = [
21.     path('some-random-text/', admin.site.urls),
22.     path('', views.home, name='home')
23. ]

Save everything, and restart your server.

Ignore the empty look
💃🕺🍾💃🕺🍾 I think we should celebrate. Go get yourself a bottle of whatever you like best, you've worked hard.
You could go over it by creating another app and another url, and so on. Be curious. You have everything to gain!
I'd also take a break🍟. We continue another time.
Project can be found here

Beginning Django - Lesson 1

Jonathan Farinloye — Tue, 18 Jun 2019 01:27:52 +0000

Introduction

This series is specifically for beginners who want to learn the Django. The Web framework based on Python. As you should know, Python is a requirement, and we'd be making use of Python v3.0+. It'd also be nice if you know some HTML and CSS. I'm not saying know it all level. Just basic knowledge.

I'm also learning, so you might have some questions and I might not be able to answer immediately. However, feel free to ask questions, I'd try my best to answer.

So in this lesson, we'd be learning about:

Installation
- Python
- PIP
- Virtual Environment
- Django
Starting a new Project
Running a new Project

Before starting, you should know a few things:

The Django Project has great documentation. You should make sure to check it out.
This tutorial would be done completely on a Linux machine and should work perfectly for Linux distributions and MacOS. You might need to do a little bit of extra work if you're using Windows.
All commands to be run in the terminal would start with a '$'. The '$' is not part of the command
Feel free to skip to sections you need if you're already familiar with the previous sections.

Installation

Python

Python needs to be installed and as mentioned earlier, Python version 3.0 or greater.
To check if python3 is installed, open your terminal and type

$ python3

Running that should open a prompt similar to this:

Python 3.7.3 (default, Apr  3 2019, 05:39:12) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for information.
>>>

If it does, you're good to go. If not, you need to first install python3. You can go to the official site to download it and install it. If you're on Linux. You could try:

$ sudo apt install python3

This would install the latest version of Python3.

PIP

Pip is basically a package manager for python. To install it, visit the documentation here or try:

$ sudo apt install python3-pip

Virtual Environment

I would suggest using a virtual environment because it allows you to basically localize your project and all the packages you use while working. To install virtualenv, open your terminal and run:

$ sudo pip3 install virtualenv

$ sudo apt install python3-venv

Now that we have installed virtualenv, lets create one.

$ virtualenv -p python3 myvenv

$ python3 -m venv myvenv

You can replace 'myvenv' with the name of your choice

To activate the virtual environment:

$ source myvenv/bin/activate

To deactivate it:

$ deactivate

at this point, I'm getting tired. Maybe you are too. Go take a short walk🌞. I'd be here when you're back.

Django

No? No walk? Okay. Well, to install django, first ensure that your virtualenv is active. Then run:

$ pip install Django

This would download and install the Django package into your virtual environment.
And that installs all we need to start.

Starting a New Project

Our project would be named awesome because you're awesome😉 . Feel free to give it another name, but don't forget, anywhere you see awesome, you replace it with your project name. To create, run:

$ django-admin startproject awesome

And! BoOm💥 We have a new project named awesome.

Running a Project

To run a project, first move into the directory of the project.

$ cd awesome

Then run:

/awesome$ python manage.py runserver

You get something like this:

Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).

You have 17 unapplied migration(s). Your project may not work properly 
until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.

June 17, 2019 - 17:41:50
Django version 2.2.1, using settings 'awesome.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

If yes, you're doing great. Now, open your browser and visit http://127.0.0.1:8000/.
Looks like this?

Your project is up and running!

Great! I hope I didn't confuse you. Leave a comment if there's anything I should know or can help with.
Project can be found here
Cover image by pngtree.com

Forem: Jonathan Farinloye

Models, Views, Templates - Lesson 5

Introduction

Templates to Views to Models

Displaying from Models

Models - Lesson 4

Table of Contents

Models

Creating Models

Registering Models

Cheers ✨✨

Views - Lesson 3

Changes to Make

Views.py

Moving Forward - Lesson 2

Get Familiar

Database

Apps

Homepage

Beginning Django - Lesson 1

Introduction

Installation

Python

PIP

Virtual Environment

Django

Starting a New Project

Running a Project

Cheers ✨✨