LINUX.ORG.RU

Форум на Python/Flask

 , ,


2

2

https://github.com/Lenin1917/FlaskForum - моя курсовая по информатике (WIP). Прошу обратить внимание, что я учусь не на программиста! Буду рад увидеть здесь критику принципиальных недостатков в архитектуре, а ещё сильнее буду рад, если вы скажите как исправить проблемы.


я учусь не на программиста

а как не программисты оправдывают форумы ? или преподу все равно ? Меня вот в магестратуре заставляли такие штуки притягивать за уши к специальности

Dred ★★★★★ ()

Ну что, поздравляю, теперь ты типа программист :) Я тебе помогу немного вечером, докину docker образ и может немного подкорректирую код.

deterok ★★★★★ ()

Пароли plain-text'ом что-ли в базе хранишь? Не надо так.

При каждом запросе заново создается соединение к БД, это плохая практика. По хорошему, надо делать пул соединений и брать соединения из него. SQLite не самый лучший выбор, если планируется множество подключений, он всё-таки больше рассчитан на работу с одним подключением.

hippi90 ★★★★ ()
Ответ на: комментарий от ggrn

flask-sqlalchemy

Нахер-нахер, если уж хочется ORM, то лучше посмотреть на pewee или pony, второй лично мне больше зашел.

flask-migrate

Миграции вообще хорошая штука, рекомендую. Я пользуюсь yoyo, он не завязан на другие фреймворки.

hippi90 ★★★★ ()

Прошу обратить внимание, что я учусь не на программиста!

Вот так всегда. Сапоги тачает пирожник, пироги печет сапожник... Россея...

dem ()
Ответ на: комментарий от Dred

У нас вся параллель, хоть у нас и физико-математические специальности, изучает программирование. Пишем контрольные от расчёта движения планет на C++ до бухгалтерского учета макросами в Excel.

Cirno ()
Ответ на: комментарий от Dred

Вообще, у меня специльность не лабораторная/заводская, а больше офисная. Препод попался хороший, а не дед какой-то и разрешил использовать любой ЯП на выбор. Потом просто дали темы в количетсве около 9 штук и сказал пилите на чем хотите, но помогать я вам буду только если будете писать на js/php/python. Выбрал именно форум, так как я ими чаще всего пользкюсь по жизни

Cirno ()

Ты можешь смело удалять все комментарии из кода, так как они комментируют очевидные вещи и только мешают.

Используй комментарии только в том случае, когда есть что-то неочевидное.

Если последовательность операторов под if заканчивается return, то else не нужно - в нем нет смысла.

Избавься от лишних отступов, переопределив условия.

Твой код

@app.route('/') 
def root():

    if 'user' in session: # Если пользователь в сессии
        db = sqlite3.connect(DB) # Подцепляемся к базе данных
        cur = db.cursor() # Имитируем консоль?

        
        # Исполянем команду как в базе данных

        thread = cur.execute('SELECT * FROM thread group by id order by date desc').fetchall()

        perm = cur.execute('SELECT perm from users where login=?', [session['user']]).fetchone()
        if perm[0] == "Администратор":
            perm = True
        else:
            perm = False
        # Вызываем шаблон индекс, и посылаем в него имя пользователя и все поля таблицы месседж 
        return render_template('index.html', perm=perm, user=session['user'], thread=thread) 

    else:
        # Иначе возращаем пользователя на страницу ввода логина/пароля
        return redirect(url_for('login'), code=303) 

Можно заменить этим

@app.route('/') 
def root():
    if 'user' not in session:
        return redirect(url_for('login'), code=303)
    
    db = sqlite3.connect(DB)
    cur = db.cursor()
    thread = cur.execute('SELECT * FROM thread group by id order by date desc').fetchall()

    perm = cur.execute('SELECT perm from users where login=?', [session['user']]).fetchone()

    perm = perm[0] == "Администратор"

    return render_template('index.html', perm=perm, user=session['user'], thread=thread) 

Дальше попробуй сам.

khrustalev ()
Ответ на: комментарий от khrustalev

0. Подход вообще говно, я бы полностью переделал на нормальную ролевую модель, потому что текущий подход не расширяем. По факту сейчас есть только админ и обычный юзер, если нам завтра захочется добавить например модератора, или юзера с доп. правами, то этот код только выкинуть.

1. Оставаясь в рамках данного подхода, «роль» должна хранится в виде кода, который не меняется никогда, например 'ADMIN';

2. Выше уже правильно заметили, результат может быть пустым списком или None, это надо учитывать.

is_admin = perm is not None and 'ADMIN' in perm
hippi90 ★★★★ ()
Последнее исправление: hippi90 (всего исправлений: 1)
Ответ на: комментарий от khrustalev

perm = perm[0] == «Администратор»

я бы вообще отказался от идеи переопределят тип переменной. Сначала perm список, потом булево

perm[0]

надо проверять длину.

Dred ★★★★★ ()

Стоит взаимодействие с БД вынести в отдельный модуль/файл и обернуть в ф-ции, тогда будет проще контролировать. И выпилить из репозитория файлы БД (*.db)

if 'user' in session: # Если пользователь в сессии
return redirect(url_for('admin'), code=303)

Я бы это превратил в декоратор

Dred ★★★★★ ()
Последнее исправление: Dred (всего исправлений: 2)
Ответ на: комментарий от Cirno

я не программист
хоть у нас и физико-математические специальности, изучает программирование.

Что значит «хоть и» тут? Человек физмат специальности не умеющий в программирование это инвалид. Почти как писать/читать не уметь.

Ты вообще своим делом занят? Точно?

anonymous ()
Ответ на: комментарий от dimuska139

Когда она не нужна - на этот вопрос я ответить не могу. Когда без нее можно обойтись - на мой взгляд часто. Возможность быстро сменить базу данных на другую - весьма неплохо, но насколько часто это люди делают? Миграции - да, штука очень полезная, тут сказать нечего (но и без орм можно сделать что либо аналогичное). Возможность все писать и работать с данными на одном языке программирования, не затрагивая SQL - поначалу полезно, потом может стать вредно. Скорость работы и оптимальность запросов - поначалу может устраивать, но со временем может стать проблемой, с решением которой вы немало посидите. А если вас еще сложная выборка данных с нескольких таблиц (допустим штук 10 , с 5-7 колонок в каждой), и вам нужно данные отфильтровать/сгруппировать, да и чтобы работало быстро ... Скажем так, с обычным sql это будет сделать в разы проще. Я не претендую на звание гуру орм, но блин после того как я минут 30 просидел над тем, чтобы алхимия делала выборку данных более менее похожую на ту, что я делаю запросом, причем делала одним запросом, вытаскивая именно нужные мне данные - как то не ок стало мне. А это был один из простейших примеров. Да и скажем так - нередко видишь статьи «Мы использовали орм, у нас все работало хреново, мы налепили страшных престаршных архитектурно-програмных решений, и у нас вроде все заработало неплохо.». И самое главное, ты понимаешь, что при использовании обычного sql такие проблемы даже возможности возникнуть не имели бы.

Kazun3500 ()
Ответ на: комментарий от Kazun3500

Т.е. вы согласны что ОРМ бывает вредна? Просто малость удивлен (перечитал ваше сообщение раза 3)

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

redixin ★★★★ ()