Создание аналога Twitter

Модели – построение начальной схемы базы данных

Возвращаясь к нашему проекту, на начальном этапе нам нужно две модели для нашего проекта модель user и модель tweet. Модель user будет использоваться для хранения основных подробностей о пользователях, которые будут иметь аккаунты в нашей системе.

Затем мы обращаемся к модели tweet, которая будет хранить все данные относящиеся к твиту, такие как текст твита, пользователь, создавший твит и другие важные подробности , такие как временной штамп опубликованного твита и т.д.

Для просмотра твитов пользователя, лучше создать отдельное приложение, особое для всех пользователей проекта. Наши пользовательские модели будут созданы на основе расширенного класса пользовательской модели Django AbstractBaseUser.

Изменение текущего класса user в вашем дереве источников Django, а также копирование и изменение модуля auth никогда не рекомендуется.

Это будет первое приложение с использованием фреймворка для веб-разработки, вместо написания всей системы аутентификации самостоятельно, что является довольно общим для всех сценариев веб-разработки. Django поставляется со стандартными библиотеки так, что нам не нужно снова изобретать колесо. В поставке так же есть аутентификация и авторизация вместе и это называется система аутентификации

Пользовательские объекты Django

Дополнительная настраиваемая модель пользователя поставляется с Django 1.5, что является более простым методом для хранения пользовательских данных в приложении.

Мы создадим приложение user и затем импортируем модель пользователя Django по умолчанию:

python manage.py startapp user_profile

Мы будем расширять модель пользователя Django согласно нашим потребностям в текущем проекте, создав пользовательский класс User(), который наследует от класса AbstractBaseUser. Таким образом наш файл models.py будет выглядеть так:

from django.db import models 
from django.contrib.auth.models import AbstractBaseUser

class User(AbstractBaseUser):

Теперь, когда мы создали наш класс user для данного проекта, мы можем добавить все основные атрибуты к данному классу user, которые нам бы хотелось видеть в данной модели,

Наш файл models.py будет выглядеть так:

from django.db import models 
from django.contrib.auth.models import AbstractBaseUser

class User(AbstractBaseUser):


    username = models.CharField( 'username', max_length=10, unique=True, db_index=True)
email = models.EmailField('email address', unique=True)
joined = models.DateTimeField(auto_now_add=True)
is_active = models.BooleanField(default=True)
is_admin = models.BooleanField(default=False)

В приведенном коде поле пользовательской модели email имеет свойство unique, установленное в True. Это означает, что пользователь может зарегистрироваться, предоставив свой адрес электронной почты, подтверждение может быть сделано на странице регистрации. Вы также можете заметить опцию db_index в атрибуте username со значением в True, которая будет индексировать таблицу пользователя в атрибуте username.

Параметр joined типа DateTimeField автоматически увеличивается, когда создается новый профиль пользователя.; поле is_active по умолчанию устанавливается в True при создании нового аккаунта, а поле is_admin в то же самое время устанавливается в False.

Еще одно поле, которое нам необходимо сделать, чтобы у нас получилось почти то же самое, что и в модели пользователя Django по умолчанию, поле username.

Добавьте поле USERNAME_FIELD в файл models.py:

USERNAME_FIELD = 'username'
def __unicode__(self):
    return self.username

USERNAME_FIELD выступает также в качестве уникального идентификатора для пользовательской модели в Django. Мы сопоставляем параметр username с полем username Django. Это поле должно быть уникальным по своему определению (unique=True), когда наше поле username уже существует.

Метод __unicode__() так же добавляется как определение, которое отображается в формате, удобном для представления человеку объекта нашей модели пользователя.

Итак, окончательный вариант нашего файла models.py будет выглядеть так:

from django.db import models 
from django.contrib.auth.models import AbstractBaseUser

class User(AbstractBaseUser):
    username = models.CharField( 'username', max_length=10, unique=True, db_index=True)
email = models.EmailField('email address', unique=True)
joined = models.DateTimeField(auto_now_add=True)
is_active = models.BooleanField(default=True)
is_admin = models.BooleanField(default=False)
USERNAME_FIELD = 'username'
def __unicode__(self):
    return self.username

Теперь, после определения нашей модели пользователя, мы можем перейти к дальнейшей разработке модели твита. это будет такое же приложение, которое мы создавали для проверки основного представления на основе классов.

Мы добавим следующее в файл models.py приложения tweets:

from django.db import models 
from user_profile.models import User
class Tweet(models.Model):
user = models.ForeignKey(User)
 text = models.CharField(max_length=160)
 created_date = models.DateTimeField(auto_now_add=True)
 country = models.CharField(max_length=30)
 is_active = models.BooleanField(default=True)

Модель твита разработана максимально просто для пользователя. Параметр user – это внешний ключ для объекта User, который мы уже создавали. Атрибут text – это содержимое твита, содержит в основном простой текст. Атибут created_date автоматически добавляется в базу данных, когда инициализируется объект tweet. Country хранит имя страны, из которой опубликован твит, в большинстве случаев он совпадает со страной проживания пользователя. Флаг is_active используется для представления текущего состояния твита, когда тот активен и может отображаться, и удаляться пользователем.

Нам нужно создать таблицы в базе данных для обоих созданных моделей, user_profile и tweets. Нам нужно обновить переменную INSTALLED_APPS в файле settings.py для указания Django включить эти приложения в состав нашего проекта.

Наша обновленная переменная INSTALLED_APPS будет выглядеть так:

INSTALLED_APPS = (
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'user_profile',
    'tweets'
)

Вы можете обратить внимание, что последние две строки добавляют две созданные нами модели.

Сейчас мы создадим таблицу базы данных для нашего проекта, для чего запустим следующую команду из-под корневого каталога проекта в командной строке:

python manage.py syncdb

Вывод может быть следующим:

C:\Python34\lib\site-packages\django\core\management\commands\syncdb.py:24: Removed In Django 1.9 Warning: The syncdb command will be removed in Django 1.9
  warnings.warn("The syncdb command will be removed in Django 1.9", RemovedInDja
ngo19Warning)

Operations to perform:
  Synchronize unmigrated apps: staticfiles, messages
  Apply all migrations: sessions, contenttypes, auth, admin
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
  Installing custom SQL...
Running migrations:
  No migrations to apply.
  Your models have changes that are not yet reflected in a migration, and so won
't be applied.
  Run 'manage.py makemigrations' to make new migrations, and then rerun 'manage
.py migrate' to apply them.

Вы только что установили систему авторизации Django, что подразумевает отсутствие созданных суперпользователей. Вы увидите следующее приглашение:

You have installed Django's auth system, and don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Username (leave blank to use 'ff'): sergioalvares
Email address: tilllindemann85@outlook.com
Password:
Password (again):
Superuser created successfully.

В результате, к нашей базе данных добавится таблица. Она появится в базе данных, в файле нашего проекта, названном db.sqlite3.

Как и в случае с Django 1.6, панель администратора поставляется по умолчанию. Все что нам нужно для того, чтобы модели были доступны в администраторской панели Django, это добавить параметр admin.site.register с именем модели в качестве аргумента для обоих приложений.

Таким образом, после добавления admin.site.register(parameter) в файлы admin.py обоих приложений, tweets и user_profile, будут выглядеть следующим образом:

• Файл admin.py в приложении tweets будет выглядеть так:

  from django.contrib import admin 
  from models import Tweet
  admin.site.register(Tweet)
  
• Файл admin.py в приложении user_profile будет выглядеть так:

  from django.contrib import admin 
  from models import User 
  admin.site.register(User)
  

Запустим сервер командой:

python manage.py runserver

Перейдя по адресу http: //127.0.0.1:8000/admin, мы получим запрос информации о входе. Как вы помните, мы создавали пользователя по умолчанию во время запуска команды python manage.py syncdb; используйте те же логин и пароль.

После успешного входа, администраторская панель будет выглядеть как на приведенном скриншоте:

увеличить изображение

Давайте поиграем с панелью управления администратора и создадим объекты user и tweet, которые мы используем далее для представления нашей домашней страницы. Для добавления нового пользователя к нашему проекту просто нажмите на кнопку Add перед полем модели пользователя, как показано на следующем скриншоте:

увеличить изображение

Затем заполните детали и сохраните их. Вы увидите сообщение user successfully created, как показано на следующем скриншоте:

увеличить изображение

Похожим образом создается твит. Давайте вернемся к http: //127.0.0.1:8000/admin. Затем нажмем кнопку Add напротив окошка Tweet.

увеличить изображение

Создайте новый твит, заполнив параметры и выбрав пользователя из выпадающего списка. Этот список пользователя уже заполнен, так как мы сопоставили пользователя с объектом user. Пока мы добавляем новых пользователей, выпадающий список будет пополняться новыми пользователями.

увеличить изображение

Наконец, после составления твита, нажмем на кнопку Save. Вы увидите то же, что и на следующем скриншоте:

увеличить изображение

Если вы присмотритесь внимательно, страница списка администратора говорит о том, что каждый твит есть объект tweet, представление которого не особенно дружелюбно к пользователю. Это можно легко исправить в данном случае. Действительно, это же правило применимо для всех базовых представлений моделей в представлении администратора Django или там, где они отображаются.

Добавим следующий фрагмент в файл admin.py нашего проекта:

def __unicode__(self):
    return self.text