Задать вопрос
Пишу проекты на Django, а значит пишу код Python.

Имею опыт больше 5 лет работы на ЧПУ-станках с материалом Дерево, МДФ (3D и 2D). Делал свои постпроцессоры и прикладные программы. Работал в основном в ArtCam, Vectric Aspire. Работал на станках под управлением RZNC, Mach3 и Syntec. (но не увидел ни материального, ни профессионального развития и ушёл)

Когда-то пытался писать на PHP.
Могу читать код JS, но пишу по мануалам, да и ограничиваюсь чистым или максимум jQuery. А потому что не люблю я JS.

Есть в прошлом программы на VB, VBA, PureBasic, AutoHotKey, AutoIt и даже пару программ небольших на С#, но Python лучше. Иногда балуюсь на GOlang.

Как то тяжело мне даётся фронтенд, зато в бекенде я чувствую себя уверенно.

Топ любимых языков программирования выглядит так:
1. Python (+Django)
2. Lua
3. C#
4. GOLang
...
9. PHP
...
99. JS (jQuery, vue, Angular, React и прочая муть)
....
999. Node.js (в отдельном пункте)
Контакты
Местоположение
Россия

Наибольший вклад в теги

Все теги (18)

Лучшие ответы пользователя

Все ответы (29)
  • Как в Django определять админа, персонал, какую-то роль (которую определили в админке), как назначать свежезареганному пользователю роль?

    JawsIk
    @JawsIk Автор вопроса
    Python Django, Lua, ЧПУ-станки(ArtCam, Aspire)
    Итак, как было в теме, я задавал два вопроса. Отвечу на них по порядку, чтобы людям сразу наглядно было понятно что сделать, чтобы получить результат. Очень меня печалит документация по Django. Вроде бы всё есть, но в итоге нет примеров. А как сказал мой один хороший учитель (не по Django а вообще по программированию): "Документация без примеров кода, это просто справочник. И если ты не специалист, то грош цена такому справочнику". Поэтому я просто приведу два примера кода, после которого сразу всё станет ясно.

    Вопрос 1: Опознавание ролей (групп) программно.
    В примере будет показан программный код метода account_view из файла views.py, который будет опознавать разные группы пользователей. Для примера в админке была создана группа manager. Ей не были даны специальные разрешения (permissions) и она служит лишь для декоративного разделения, но в программном коде даже такое декоративное разделение позволяет прекрасно опознавать и распределять пользователей. Так же прошу не обращать на функционал корзинки, здесь он оставлен только для того, чтобы показать на какой стадии нужно вставлять условия. Так же нужно понимать, что в каждом условии кроме имени шаблона могут быть (при необходимости) добавлены свои параметры, которые потом можно передать в шаблон.
    def account_view(request):
    
        cart = Cart()
        cart_id = cart.get_cart_id(request)
        items_in_cart = CartItems.objects.filter(cart_id=cart_id)
    
        # если не опознан, то дуй на страницу регистрирации
        if not request.user.is_authenticated:
            return HttpResponseRedirect(reverse('registration'))
    
        # если это суперпользователь
        if request.user.is_superuser:
            template = 'account_admin.html'
        # или если это пользователь с галочкой персонал, а так же принадлежащий группе manager
        elif request.user.is_staff and request.user.groups.filter(name='manager').exists():
            template = 'account_personal_role.html'
        # или если это просто пользователь с галочкой персонал
        elif request.user.is_staff:
            template = 'account_personal.html'
        # или если это пользователь принадлежащий группе manager
        elif request.user.groups.filter(name='manager').exists():
            template = 'account_role.html'
        # иначе все остальные (обычные пользователи)
        else:
            template = 'account.html'
    
        # сортировка выдачи заказов в обратном порядке (от последнего к первому)    
        list_orders = Order.objects.filter(user=request.user).order_by('-id')
        orders = OrderItems.add_order_info(request, list_orders)
    
        context = {
            'title': 'Кабинет пользователя',
            'orders': orders,
            'cart': items_in_cart,
            'total_cost': cart_id.total_cost,
        }
        return render(request, template, context=context)

    Как видно из кода здесь имеет место быть некоторая последовательность. В частности, если второе условие (первый elif) опустить ниже, то возможна неверная работа, т.к. тогда пользователь принадлежащий группе manager и с галочкой персонала, может легко заскочить в чужой шаблон (по одному условию), поэтому при создании сложных условий, этот момент нужно учитывать.

    Вопрос 2: Программное добавление пользователей в группу (или в несколько сразу)
    Иногда бывает, что (например) при регистрации, нужно сразу добавить пользователя в определённую группу. Для примера была создана группа clients. Это чисто декоративное разделение. Группа не имеет никаких разрешений в админке, но выполняет свою задачу. Ниже представлен код метода registration_view из файла views.py , т.е. регистрации пользователя и этот новый пользователь после регистрации будет уже принадлежать группе clients. Кстати, чтобы код работал нужно выполнить необходимый импорт, это тоже в коде показано.
    ...
    from django.contrib.auth.models import Group
    ...
    
    def registration_view(request):
    
        # (предотвращаем заход по прямой ссылке)
        # если авторизован, то
        if request.user.is_authenticated:
            return HttpResponseRedirect(reverse('account'))
    
        form = RegistrationForm(request.POST or None)
        if form.is_valid():
            new_user = form.save(commit=False)
            new_user.username = form.cleaned_data['username']
            new_user.set_password(form.cleaned_data['password'])  # вот из-за этой бяки вся засада была у меня с паролями ЗАПОМНИ!!!!!!
            new_user.email = form.cleaned_data['email']
            new_user.first_name = form.cleaned_data['first_name']
            new_user.last_name = form.cleaned_data['last_name']
            new_user.save()
    
            # после собственно регистрации (сохранения нового) пользователя его можно добавить к группам
            new_user.groups.add(Group.objects.get(name='clients'))
    	# new_user.groups.add(Group.objects.get(name='manager'))  # и в ещё одну группу работает тоже
    
            login_user = authenticate(request, username=form.cleaned_data['username'], password=form.cleaned_data['password'])
            if login_user:
                login(request, login_user)
                return HttpResponseRedirect(reverse('account'))
    
        context = {
            'title': 'Регистрация',
            'form': form,
        }
        return render(request, 'registration.html', context)

    Как видно в коде после создания пользователя, он добавляется к (уже созданной предварительно) группе и теперь зайдя в админку, мы это можем легко проверить. Кроме того, в коде закомментирована строчка с добавлением в ещё одну группу manager. Если её раскомментировать, то пользователь будет добавлен сразу в две группы. Т.о. можно добавлять пользователей сразу в несколько групп (если в этом есть необходимость). Естественно нужно понимать, что подобное добавление в группу можно делать не только при регистрации, но видя этот код, сделать необходимое решение уже не должно составлять большого труда.

    Надеюсь код пригодиться людям.
    Ответ написан
    Комментировать
  • Как сделать нужный порядок при отображении моделей в админке Django?

    JawsIk
    @JawsIk Автор вопроса
    Python Django, Lua, ЧПУ-станки(ArtCam, Aspire)
    В общем нашёл я функцию сортировки. Сортирует она в функции get_app_list класса AdminSite. Затем по указанию Pavel Denisov стал искать способы решения. Находил разные варианты, поэтому объединив получил следующий вариант. Все манипуляции происходят в файле admin.py.
    Тут сразу хочется сделать некое отступление, что при переназначении регистрации, из админки пропадают Пользователи и группы и поэтому их нужно туда зарегистрировать самостоятельно. Но обо всём по порядку.

    1. Делаем необходимый импорт:
    from django.contrib.admin import AdminSite
    from django.contrib.auth.models import Group, User
    from django.contrib.auth.admin import GroupAdmin, UserAdmin

    2. Определяем свой класс, наследуясь от AdminSite и в нём переписываем функцию. (в моём случае я просто закомментировал цикл сортировки):
    class MyAdminSite(AdminSite):
    
        def get_app_list(self, request):
            """
            Return a sorted list of all the installed apps that have been
            registered in this site.
            """
            app_dict = self._build_app_dict(request)
    
            # Sort the apps alphabetically.
            app_list = sorted(app_dict.values(), key=lambda x: x['name'].lower())
    
            # Sort the models alphabetically within each app.
            #for app in app_list:
            #    app['models'].sort(key=lambda x: x['name'])
    
            return app_list


    3. Подменяем admin.site своим собственным:
    admin.site = MyAdminSite()

    4. Регистрируем своим модели:
    # Register your models here.
    admin.site.register(TypeProfile)
    admin.site.register(TypeFacade) 
    admin.site.register(Price)
    admin.site.register(PaintColor)
    admin.site.register(PatinaColor)
    admin.site.register(Materials)
    admin.site.register(Category)
    admin.site.register(Products)

    5. Регистрируем стандартные модели:
    #Регистрируем стандартные
    admin.site.register(Group, GroupAdmin)
    admin.site.register(User, UserAdmin)


    И всё работает как надо.
    Всем спасибо.
    Ответ написан
    2 комментария
  • Как изучать Python?

    JawsIk
    @JawsIk
    Python Django, Lua, ЧПУ-станки(ArtCam, Aspire)
    На меня наверное все накинутся, но хуже чем документация Django я не встречал ещё ни разу.
    Да, я не знаю английского. Но я русский человек и сижу на русских порталах и форумах.
    Да, имея четверых детей, нет у меня возможности выучить английский, но даже имея перевод на русском, официальная документация Django отвратительная!!!
    Да, может быть я старый уже дядька и у меня, как я сам про себя говорю, однопроцессорная система в голове, но я считаю, что должно быть описание и тут же показана реализация с кодом и РЕЗУЛЬТОМ ВЫПОЛНЕНИЯ этого кода.
    В официальной же документации Django вы найдёте кучу всего в разных местах, всяких ссылок и описаний. Свойства в одном месте. Фильтры в другом. Аргументы в третьем, а в едином коде вам этого никогда не покажут. И вот когда вы уже подготовленный человек и знаете хотя бы половину из всего, то вам будет легко пользоваться этим, как справочником и то не факт.
    Очень часто вам нужна одна задача и она простая для понимания, а в официальной документации будет непонятно-неприменимый-к-реальности-пример, который вас запутает и отправит в Google. И тут нужно уметь искать по английски.
    Слава Богу, есть https://djbook.ru/ , да там версия 1.9, но по началу вы находите ответы именно там.
    И вот тут чем больше вы копаете, и разбираете чужого кода, тем больше вы понимаете что куда и как лепить. И тогда Django становиться реальным пластилином для быстрых поделок.
    Чтобы выйти на этот уровень новичку обязательно смотреть видео-уроки. Потому как если вы начнёте сейчас изучать английский, то до компьютерного английского вы доберётесь года через 2-3, а это значит вам нужно было задавать вопрос, как изучить всё это дело в 2021 году.
    А если сейчас, то обязательно к просмотру:
    djlesson : https://www.youtube.com/channel/UCbGrifMy8FAYpZ6wj...
    Олег Молчанов: https://www.youtube.com/user/zaemiel/featured?disa...
    Django School: https://www.youtube.com/channel/UC_hPYclmFCIENpMUH...
    Ну а дальше всё остальное, смотрите по Python целыми плейлистами.

    Я сейчас например смотрю очень много англоговорящих курсов. Балаболы срашные! Слава Богу, что я понимаю только отдельные слова. Но я смотрю код, который они кодят. И вот там нахожу порой удивительные решения.

    Но как я уже сказал, нужно несколько месяцев плотно посидеть, посоздавать какие-то проекты по тем же видео-урокам. Чтобы код не вызывал страха и вопроса "А чего это? и где это?".

    А максимум возгласы: "А почему так" или "Ух-ты, не дурно".

    Кроме того вы всегда можете почитать комментарии и сделать для себя выводы, почерпнуть дополнительные нюансы. (и английские комментарии можете переводить). Или даже задать вопрос самостоятельно автору того или иного ролика. Даже на английском (ведь Google Traslate есть). Только совет. Если задаёте вопрос, то разбивайте предложение на короткие.

    В общем плотный кодинг это самое верное средство для изучения. По 3-10 часов в день. И через 3 месяца у вас уже опыт около 500 часов кода на django.
    Ответ написан
    9 комментариев
  • Как правильно обработать urls в django?

    JawsIk
    @JawsIk
    Python Django, Lua, ЧПУ-станки(ArtCam, Aspire)
    Да всё ты правильно делал. В джанге второй всё даже проще. Со временем разберёшься, только попробуй (хоть оно и на английском) пусть даже с переводчиком (как и я) почитать официальную документацию по path. Ну а в твоём случае делается следующее:

    1. в файл urls.py (главный, тот который лежит в папке с названием твоего проекта) нужно импортировать модуль include. Обычно там уже модуль path импортирован, поэтому просто нужно добавить include, чтобы строчка выглядела так:
    from django.urls import path, include

    2. Соответственно ниже код у тебя должен быть подобного вида:
    urlpatterns = [
        path('admin/', admin.site.urls),
        path('', include(learning_logs.urls), namespace='learning_logs'),
    ]

    namespace (да и name) даже и не знаю нужен ли вообще в данном случае, ибо это же у тебя главный urls.py и в своих шаблонах ты можешь просто использовать '/' (прямую косую черту)
    <a class="main" href="/">Главная</a>
    да и в шаблонах этот же критерий можно использовать даже в качестве условий:
    {% if not request.get_full_path == '/' %}
    (в данном случае, условие означает, если текущая страница не главная (корневая), (но get_full_path нужно написать самому.))

    3. А вот уже во-внутреннем urls.py (тот который лежит в папке твоего приложения learning_logs), я бы использовал уже параметр name=:
    from django.urls import path
    from . import views
    
    urlpatterns = [
       # и т.д. пишешшь више чем нижняя строка
        path('result/', views.result, name='result'),
        path('', views.index, name='index'),
    ]


    Это твой как бы для тебя. Хотя я бы для себя это всё написал в главном urls.py, если приложение не большое. И оно одно. Кроме того я не выполняю (from . import views), а делаю это явным образом (контролируя и дописывая нужное в процессе написания). Обычно у меня главный urls.py файл выглядит как-то так:
    from django.contrib import admin
    from django.urls import path, include
    # тут могут быть и другие импорты например для статических файлов
    
    urlpatterns = [
        path('admin/', admin.site.urls),
        path('tst/', include('tst.urls')),
        path('', include('shop.urls')),
    ]

    а во внутренний файл уже выглядит следующим образом:
    from django.urls import path
    from django.views.generic import TemplateView
    from shop.views import (
        base_view,
        category_view,
        product_view,
        cart_view,
        add_to_cart_view,
        remove_from_cart_view,
        add_to_cart_js_view,
        remove_from_cart_js_view,
        change_item_qty_view,
        checkout_view,
        order_create_view,
        make_order_view,
    )
    
    urlpatterns = [
        path('category/<slug:slug>', category_view, name='category_detail'), # если нужно отправить в метод slug
        path('product/<slug:slug>', product_view, name='product_detail'), # тоже самое
        path('cart/', cart_view, name='cart_detail'),  # просто переходим
        path('add_to_cart/<int:pk>', add_to_cart_view, name='add_to_cart'), # если нужно отправить id ключа например
        path('add_to_cart_js/', add_to_cart_js_view, name='add_to_cart_js'),
        path('remove_from_cart/<slug:slug>', remove_from_cart_view, name='remove_from_cart'),  # снова slug
        path('remove_from_cart_js/', remove_from_cart_js_view, name='remove_from_cart_js'),
        path('change_item_qty/', change_item_qty_view, name='change_item_qty'),
        path('checkout/', checkout_view, name='checkout'),
        path('order/', order_create_view, name='create_order'),
        path('make_order/', make_order_view, name='make_order'),
        path('thank_you/', TemplateView.as_view(template_name='thank_you.html'), name='thank_you'), # вот тут даже класса во views.py не создаётся, а сразу напрямую отправляемся в шаблон (работает потому что импортирована функция вверху).
        path('', base_view, name='base'),
    ]


    ну я так часть взял, часть убрал, чтобы было наглядно понятно. Вообще всё с опытом. Дерзай.

    p.s. и последнее:
    Но PowerShell кидает ошибку
    name 'learning_logs' is not defined

    И глушит сервер.


    у тебя всё называется одинаково и поэтому ты путаешься сам. Подумай над названиями. А по факту всё это произошло, из-за вот этого (см. жирным):
    path(r'', learning_logs.urls, namespace='learning_logs'),
    Потому что в данном случае Django пытается найти в views.py класс learning_logs и естественно его там не находит, вот и говорит тебе, что ёлки-маталки имя learning_logs не определено. (и правильно кстати говорит).
    Ответ написан
    Комментировать
  • Как изучать Базы Данных? С чего начать? Какой СУБД выбрать? Что читать? Где искать информацию?

    JawsIk
    @JawsIk
    Python Django, Lua, ЧПУ-станки(ArtCam, Aspire)
    Начнём с простого:
    БД - это база данных, а СУБД это Система управления БД. Отсюда мы делаем вывод, что базой можно управлять по разному. Ну это так. По сути болтовня.

    А по факту:
    1. Sqlite - подойдёт для изучения и для мелких проектов. Всё содержится в одном файле. Не позволяет сразу работать нескольким пользователям.
    2. MySQL - возможно глючная для каких-то очень больших проектов, но 90% всяких блогов, форумов, каталогов, магазинов и т.п. работает на ней и НЕ ГЛЮЧИТ. Т.е. ко всему нужно приложить руку и знания.
    3. PostgreSQL - возможно сложная, но эта штука чаще встречалась мне на питоновских проектах. Django (фреймоврк для построения сайтов написанный на Python и на котором сделан Instagram) очень любит эту базу. Но в Django есть ORM (это когда тебе вообще по боку какая база, ты просто даёшь команды, положить в базу, или извлечь из базы, а оно само выполняет нужные команды в зависимости от того к какой базе подключен.).
    4. Oracle DB - говорят стабильная. Сам не использовал. Но, говорят это мощь для больших корпораций.
    5. ....

    В итоге изучай MySQL и не парься. Этой технологии сто лет в обед. А зная её основы (всё про БД тебе просто на начальном этапе вообще не пригодиться), ты прекрасно будешь чувствовать себя и с простыми решениями (Sqlite) и с более продвинутыми PostgreSQL.

    Я MySQL запросами интересовался лет 10 назад. Сейчас пользуюсь и PostgreSQL и Sqlite и иногда MySQL и как-то не вижу прямо кардинальных каких-то различий. Ну тонкости, но не более. А вообще я всё чаще и чаще использую проекты с ORM.

    По поводу установки. Если винда, то у меня PostgreSQL ставиться гораздо быстрее, чем MySQL сервер. Можно ещё поставить всякие там пакеты для разработки поставить. Вот посмотри статья старая, но может чего там обновили и тебе оно как раз и нужно. XAMPP очень говорят популярен. А в моё время был Denwer.
    Ответ написан
    Комментировать

Лучшие вопросы пользователя

Все вопросы (44)