ча, здійснений доступ до інших сторінок користувачів, можливість завантажувати документи себе на сторінку і викачувати зі сторінок інших користувачів, особиста стрічка новин та сторінка новин усіх користувачів, з можливістю пошуку новини за словами в тексті і заголовку, фільтрація по тегам і по датах.
Весь функціонал сайту розбитий на 3 додатка profile, blog, message. Перше здійснює відображення і редагування особистої інформації, стрічку своїх новин, створення нової новини, додавання документів для скачування іншим користувачам, пошук, додавання і видалення інших користувачів. Друге відображення новин для всіх користувачів, з можливістю коментування. І останнє третє, відповідає за обмін повідомленнями між користувачами.
Кожна програма складається з двох частин:
Загальнодоступна частина, яка дає людям можливість управляти своїм профілем.
Адміністративна частина, яка дозволить адміністратору редагувати базу даних сайту.
Ці дві частини реалізовані, слідуючи шаблоном Модель-Представлення-Контролер (Model-View-Controller, MVC). Приймемо, що MVC визначає спосіб розробки програмного забезпечення, при якому код для визначення і доступу до даних (модель, файл models.py) відділений від логіки додатка (управління, файл views.py), яка в свою чергу відділена від інтерфейсу користувача (подання , файл html) так, що модифікація одного з компонентів надає мінімальний вплив на інші.
Основою проекту будуть manage.py, __init__.py, settings.py, urls.py, wsgi.py.
manage.py скрипт, який дозволяє вам взаємодіяти з проектом Django.
__ init__.py порожній файл, який вказує Python, що поточний каталог є пакетом Python.
settings.py налаштування/конфігурація проекту.
urls.py конфігурація URL-ів для вашого проекту Django. Це «вміст» всіх Django-сайтів.
wsgi.py точки входу для WSGI-сумісний веб-серверів.
Вміст цих файлів представлено у додатку А.
У даній роботі крім модуля django-registration, будемо використовувати модуль south, для здійснення міграції бази даних, grapelli, для додання адміністративної частини красивого виду, filebrowser, для множинної завантаження файлів.
3. База даних і адміністративна частина
В якості СУБД обрана PostgreSQL, у зв'язку з наявністю деяких особливостей в PostgreSQL, які часто використовуються - зовнішні ключі, тригери та подання. Вони дозволяють приховувати складність бази даних від програми, таким чином уникаючи створення складних команд SQL. Підключення до бази даних здійснюється в папці settings (у попередній роботі всі налаштування знаходилися в одному файлі settings.py).
={
default raquo ;: {
ENGINE raquo ;: django.db.backends.postgresql_psycopg2 ,
NAME raquo ;: diplom ,
USER raquo ;: postgres ,
PASSWORD : postgres ,
HOST raquo ;: 127.0.0.1 ,
PORT raquo ;: 5432 ,
}
}
Ця настройка ведеться з урахуванням того, що в PostgreSQL ми вже створили порожню базу даних з назвою diplom.
Розглянемо модельну частина додатку, відповідальну за головну сторінку користувача.
Клас Profile описує структуру таблиці profile, яка посилається на таблицю User, (сгенерированную при підключенні додатки django.contrib.auth), за допомогою поля user (об'єкт класу ForeignKey, атрибут-покажчик якого буде модель User).
user=models. ForeignKey (User, related_name= profile raquo ;, verbose_name=( User ), blank=True, null=True)
Так само в цій моделі описані два поля friends і friesnd_requests, які є об'єктами класу ManyToManyField (відношення багато-до-багатьох) і посилаються на свою ж модель («self»), для визначення, які об'єкти Profile знаходяться в друзях і хто хочеться стати одним.
friends=models. ManyToManyField («self», blank=True, null=True, symmetrical=False, related_name= friends_targets ) _ requests=models. ManyToManyField («self», blank=True, null=True, symmetrical=False, related_name= friend_requests_targets )
Поле party необхідно для адміністратора, що б підтверджувати, що користувач є співробітником фірми, звичайний користувач бачити його не буде. Якщо модуль django-registration, забезпечує перевірку на реєстрацію існуючої людини, то поле party буде важелем адміністратора, для додавання в соціальну мережу тільки співр...
