Вы можете просто воспользоваться распаковкой словаря.
Например, определите свой словарь processed_image_field_specs
:
def get_gallery_path(filename):
ext = filename.split('.')[-1]
filename = "%s.%s" % (uuid.uuid4(), ext)
return 'static/uploads/images/gallery/' + filename
processed_image_field_specs = {
'default': '',
'verbose_name': 'Image',
'upload_to': get_gallery_path,
'processors': [ResizeToFill(100, 50)],
'format': 'JPEG',
'options': {'quality': 60}
}
Теперь распакуйте словарь, чтобы предоставить именованные аргументы для ProcessedImageField
:
class Photo(models.Model) :
...
image = ProcessedImageField(**processed_image_field_specs)
...
«У меня как минимум 20 моделей» - это, вероятно, больше, чем одно «приложение» Django и больше похоже на «проект» Django с несколькими небольшими «приложениями»
Мне нравится для разделения вещей по темам или предметным областям, имеющим несколько (от 1 до 5) моделей. Это становится «приложением» Django - и представляет собой полезную единицу возможности повторного использования.
Общий «проект» представляет собой набор приложений, представляющих собой интегрированную вещь, построенную из отдельных частей.
Это также помогает для управления проектами. поскольку каждое «приложение» может стать спринтом с выпуском в конце.
Все модели связаны, поэтому я не могу просто сделайте их отдельными приложениями можно?
Вы можете разделить их на отдельные приложения. Чтобы использовать модель в одном приложении из другого приложения, вы просто импортируете ее так же, как вы импортируете приложения django.contrib.
Вы можете разбить модели на несколько файлов. Это касается и просмотров.
Это довольно распространенная потребность ... Я не могу себе представить, чтобы пробираться через файл models.py длиной в 10 000 строк: -)
Вы можете разделить модели .py
файл (и views.py тоже) в pacakge. В этом случае дерево вашего проекта будет выглядеть так:
/my_proj
/myapp
/models
__init__.py
person.py
Файл __ init __. Py
превращает папку в пакет. Единственная проблема - обязательно определить внутренний Meta
класс для ваших моделей, который указывает app_label для модели, иначе Django не сможет построить вашу схему:
class Person(models.Model):
name = models.CharField(max_length=128)
class Meta:
app_label = 'myapp'
Как только это будет сделано, импортируйте модель в ваш файл __ init __. py
, чтобы Django и sync db нашли его:
from person import Person
Таким образом, вы все еще можете сделать из myapp.models import Person
Вы можете разделить их на отдельные файлы и просто разместить импорт в верхней части основного поля models.py.
Хотите ли вы на самом деле - это другой вопрос.
Файл php.vim
должен находиться в папке ftplugin
в $ VIMRUNTIME
.
В версии 7,2 vim строка комментариев является строкой 74 в этом файле.
Этот файл был удален или перемещен?
-121--4349663-Веб-обходчики испытывают трудности с ajax и javascript, которые динамически загружают содержимое. Этот сайт имеет некоторые идеи, которые показывают, как помочь Google индексировать ваш сайт http://www.softwaredeveloper.com/features/google-ajax-play-nice-061907/
-121--2600159-Наличие 20 моделей в одном приложении может быть признаком того, что вы должны разбить его в меньших.
Цель приложения Django состоит в том, чтобы иметь небольшой одноцелевой фрагмент кода, который хорошо сочетается.
Таким образом, если у вас был сайт электронной коммерции, у вас может быть приложение для shopping_cart, приложение для выставления счетов и так далее.
Имейте в виду, что на самом деле нет проблем в приложениях, зависящих друг от друга (хотя всегда лучше, если их можно разъединить), но у вас не должно быть приложения, делающего две очень разные вещи.
Статья Django советы: раскладывание приложения может вам помочь. Как всегда, возьмите все прочитанное с зерном соли (включая этот ответ).