Есть ли способ создать постоянную переменную в моей Django функции просмотра? - PullRequest
0 голосов
/ 07 марта 2020

В настоящее время я получаю переменную 'my_var' через GET, когда вызывается моя функция просмотра, как показано на рисунке. Мне нужно запросить эту переменную в моем методе POST.

def article_delete_view(request, pk):
    my_var = request.GET.get('my_var') #GET THE VARIABLE from referring data-url
    obj = Listing.objects.get(type=type) # I could query here if I wanted (illustration only)
    article = get_object_or_404(Article, pk=pk)
    data = dict()
    if request.method == 'POST':
        article.delete()
        data['form_is_valid'] = True
        articles = Article.objects.all()
        obj = Listing.objects.get(name=my_var) #THIS DOES NOT WORK, since 'type' is not passed on submit.
        context = {'articles':articles, 'obj':obj}
        data['article_table'] = render_to_string('article_table.html', context)
    else:
        context = {'article':article}
        data['html_form'] = render_to_string('article_delete.html', context, request=request)
    return JsonResponse(data)

Есть ли наилучший способ сохранить эту переменную, когда POST вызывается при отправке? Я знаю, что объявлять глобальный - плохая идея. Мысль о записи его в память (прилагается к статье), но это похоже на взлом. Добавление его к аргументу pk и последующее его разделение кажутся еще хуже. Тьфу. Я мог бы заставить мой <input> метод передать my_var, но для этого мне пришлось бы реорганизовать множество других вещей, чтобы это произошло. Являются ли django переменные сеанса ответом здесь? Любая перспектива полезна. Заранее спасибо.

ОБНОВЛЕНИЕ И РЕШЕНИЕ:

Итак, для контекста проблема заключается в том, что я хочу запросить конкретный экземпляр модели c в представлении, которое нет информации об экземпляре модели (pk или id), переданной ему в качестве аргумента. Я могу GET эту переменную через data-url, которая запускает представление, но только один раз. Его нельзя было использовать в POST или при любом последующем вызове article_delete_view.

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

def article_delete_view(request, pk):
    my_var = request.GET.get('my_var')
    if my_var is not None: #This prevents my_var from being lost subsequent function calls
        request.session['session_var'] = my_var = request.GET.get('my_var') # create session variable
    else:
        pass
    article = get_object_or_404(Article, pk=pk)
    data = dict()
    if request.method == 'POST':
        article.delete()
        data['form_is_valid'] = True
        articles = Article.objects.all()
        session_var = request.session.get('session_var', None) # grab the session variable here
        obj = Listing.objects.get(name=session_var) # NOW THIS WORKS!
        context = {'articles':articles, 'obj':obj}
        data['article_table'] = render_to_string('article_table.html', context)
    else:
        context = {'article':article}
        data['html_form'] = render_to_string('article_delete.html', context, request=request)
    return JsonResponse(data)

if, следующий за получением my_var, предотвращает запись переменной сеанса в ноль при каждом последующем обращении к представлению, поскольку GET получает переменную только в первый раз. Если кому-то интересно, откуда на самом деле это session_var, вот источник (obj.slug):

<button type="button" data-url="{% url 'article_delete' article.id %}?my_var={{obj.slug}}">Name</button>

Я использую GET, чтобы получить его из шаблона, где он находится в области видимости, поэтому я можете запросить его в article_delete_view. Передача его в качестве параметра URL не сработала, поскольку этот шаблон ничего не соответствует в моем приложении. Пока это работает отлично. Если у кого-то есть какие-либо другие идеи и / или они могут сказать мне, почему это плохая идея, пожалуйста, напишите.

...