Соглашение об именах для представлений Django? - PullRequest
5 голосов
/ 18 мая 2009

Я создаю веб-сайт (на языке Django), и меня смущает правильное соглашение об именах, которое будет использоваться для моих функций. Тривиальный пример: допустим, у меня есть страница, которая позволяет пользователю решать, хотят ли они видеть изображение A или изображение B. Как только пользователь отправляет решение, сайт отображает изображение, запрошенное пользователем.

Вот две функции, которые были бы у меня в модуле представлений:

def function1(request):
    """Returns the page that presents the user with the choice between A and B"""

def function2(request):
    """Takes in the submitted form and returns a page with the image the user requested."""

Какое соглашение для именования функций, которые делают это? Я вижу как минимум два возможных пути:

Вариант 1 : function1: "decide", function2: "view_image"

Вариант 2 : function1: "view_choices", function2: "decide"

Основная проблема заключается в том, что каждая из этих функций выполняет 2 действия: (1) обрабатывает и сохраняет данные, отправленные пользователем, и (2) возвращает следующую страницу, которая может относиться или не относиться к вводу пользователя. Так я должен назвать свои функции после (1) или (2)?

Ответы [ 4 ]

8 голосов
/ 18 мая 2009

Обычно соглашение - это некий тип CRUD (создание, получение, обновление, удаление). Я лично использую индекс, детализирую, создаю, обновляю, удаляю для своих действий. Однако я не думаю, что это относится к вашим пользовательским функциям.

На самом деле звучит так, будто ваши функции должны быть объединены в одну и ту же функцию выбора. Затем вы либо отображаете форму или результат в зависимости от того, был ли результат POST или нет.

Примечание. Этот пример я сильно копировал из документации django по обработке форм .

def choose(request):
    """
    Presents the user with an image selection form and displays the result.
    """
    if request.method == 'POST': # If the form has been submitted...
        form = ChoiceForm(request.POST) # A form bound to the POST data
        if form.is_valid(): # All validation rules pass
            # Process the data in form.cleaned_data
            # ...
            return HttpResponseRedirect('/thanks/') # Redirect after POST
    else:
        form = ChoiceForm() # An unbound form

    return render_to_response('choose.html', {
        'form': form,
    })
1 голос
/ 18 мая 2009

Я бы использовал нечто похожее на встроенные представления (object_list, object_detail и т. Д.), Где это применимо. (Всегда хорошая идея)

Остальные затем будут следовать этому понятию (item_action), насколько это возможно.

1 голос
/ 18 мая 2009

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

В любом случае, лучше называть функции в зависимости от того, что они делают, так что function1 может быть «displayImageChoices», а function2 может быть «displayImage».

IE, функция1 принимает некоторые данные и отображает некоторые варианты, функция2 принимает некоторые данные и отображает изображение.

0 голосов
/ 24 декабря 2014

Я знаю, что это немного устарело, но с тех пор, как переключились на представления на основе классов.

PEP8 ( python.org / dev / peps / pep-0008 ) соглашения о присвоении имен для классов будут использовать заглавные буквы для каждого слова без пробелов. Если вы все еще используете представления стилей функций, то это будут имена функций в нижнем регистре с пробелами, заменяемыми символами подчеркивания для удобства чтения.

Например, для представлений на основе классов:

class MyClassBasedView():
    ...

На основе функций

def my_function_based_view():
    ...
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...