Правила настройки settings.py из книги для 1.8 применимы к 1.10? Вот что у меня получилось используя рекомендации: https://dpaste.de/ZHh4

Там думаю ничего и не изменилось то в плане settings

Решил, кстати, не делать отдельные файлы для настроек в продакшн / локал, а вынести ключ в env

Это 1 в 1 как я советовал, только незачем корневое приложение config-ом звать

А как? Брал из книжки.

Кому как нравится, тут говорили так будет безопаснее. Я лично по старинке production.py создаю

Вот моя структура, ты заметишь что твоя полностью дублирует папку src |data - всякие данные нужные мне, там база гео и т.д. не важно |venv |media |static |src |— application |— — app1 |— — app2 |— — settings.py |— — urls.py |— locale |— static |— templates |— manage.py |.gitignore - и т.д.

Вот

venv в папке с проектом?

вопрос вкуса

Проект в src

У меня тоже venv всегда в папке с проектом

Опять таки, благодаря книжке - познал virtualenvwrapper. Приятная штука.

Ну так да при импорте этой папки в pycharm он автоматом venv как python подтягивает

У меня тоже venv всегда в папке с проектом

зачем?

А куда его еще девать в /tmp ?)

зачем?

Удобно удалять, удобно использовать

а если у меня винда?

Ну так да при импорте этой папки в pycharm он автоматом venv как python подтягивает

+, та же ситуация с VS Code, в два клика цепляется venv.

а если потом деплой?

а если у меня винда?

Снеси её

у меня все енвы в корне лежат в .virtualenvs

а если у меня винда?

У меня тоже. А в чем проблема?)

а если потом деплой?

енвы если в проекте и лежат, они в гитигноре конечно же

Стуктура что я привел довольно стандартная

у меня все енвы в корне лежат в .virtualenvs

вот решение, если чо

смысл хранить в репе венв - не вижу

вот решение, если чо

я выше написал, это сугубо вопрос вкуса ничего критичного не меняется

смысл хранить в репе венв - не вижу

А кто хранит его в репе?

создать виртуалку минутное дела, пип рек главное держать и все

Хорошо когда у тебя весь проект в папке, а не разбросан по всему серверу, вместе с виртуалками, потом запаришься вычищать

смысл хранить в репе венв - не вижу

Просто удобно, когда в папке с проектом сразу все есть. В гит не попадет все-равно же

Просто удобно, когда в папке с проектом сразу все есть. В гит не попадет все-равно же

+

Хорошо когда у тебя весь проект в папке, а не разбросан по всему серверу, вместе с виртуалками, потом запаришься вычищать

врапер юзай и будет тебе счастье

Каждому свое, у меня и так счастье)

а еще где ты устанешь вычищать, если обычная практика хранить венвы в одном месте

нашли тему для холивара, брр

на пустом месте

да и греп есть, если что

а еще где ты устанешь вычищать, если обычная практика хранить венвы в одном месте

Это кто сказал?

Я за то, что не надо новичков сразу приучать к своей структуре проекта

врапер юзай и будет тебе счастье

Это неплохой вариант. Но тут нужно быть уверенным, что создал венв с именем, которое соотв. проекту. А когда в одной папке - ничего не надо запоминать :D

Я за то, что не надо новичков сразу приучать к своей структуре проекта

Да я сам попросил. :) Как минимум, интересно узнать как работают другие.

Это неплохой вариант. Но тут нужно быть уверенным, что создал венв с именем, которое соотв. проекту. А когда в одной папке - ничего не надо запоминать :D

напиши скрипт, который будет делать это, и подтягивать реквайрементс, хули, не вижу проблемы особо

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

Ну ок, но джангисты порой выбешивают ленью и какими-то костылями

Более того я даже конфиги храню в этой папке, да мне лень

Хорошая песня на случай таких обсуждений ? https://www.youtube.com/watch?v=atxUuldUcfI

Где-то полгода назад начал класть venv в папку проекта. До этого клал проект в папку с окружением. Думаю, разница в удобстве этих двух подходов очевидная.

from .models

спасибо, за ответ! только если сделать .models начинает подсвечивать 'objects' : Item.objects.create(text=request.POST['item_text']) return redirect('/') items = Item.objects.all()

Тогда проверь менеджер своей модели, доступен ли objects

есть ли разница в возможностях geodjango в mysql/postgis? и где можно почитать сравнение postgis с mysql?

йоу ребята вы когда работаете бд локально юзаете или конектитесь к дев сервака?

Локально или staging

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

urls

url(r'^index/blog/$', ...etc?

нашел спс

Всем ку, подскажите плиз вот есть поле в моделе first_field = models.CharField(_('Value type'), choices=VALIDATELIST, max_length=100) и есть соответсвено список тюплов VALIDATELIST = [ ('validation_simple', _('One or more characters')), ('validation_integer', _('Integer')), ('validation_yesno', _('Yes/No')), ] Подскажите как в форме в зависимости от типа choice поля first_field, мне менять виджет отображаемый в шаблоне например при обновлении формы(если Integer -> <input type='integer', если yes/no -> <input type='radio' и тд), это надо в например в forms.ModelForm написать свой метод или какой то определенный нужно переопределить?

после перегрузки страницы ?

после перегрузки страницы ?

можно и после перезагрузки

по теории в форме в __init__ переопределять виджет для поля на основании входных данных

Привет, как в jinja2 в textarea добавить текст, типо как value в input?

Привет, как в jinja2 в textarea добавить текст, типо как value в input?

<textarea>your text or {{ you_var }}</textarea> такое не катит?

Через TextAreaField хотел, ну сейчас попробую так.

Всем привет.

Почитал. Вижу, есть еще вариант делать templates в каждом приложении отдельно. Когда это оправдано?

Это оправдано в случае если ты 1 приложение можешь в будущем использовать в других. Однако, если так будет, лучше это оормлять сразу в отдельный пакет. ну а вообще в сайтах лучше так не делать по опыту.

Это оправдано в случае если ты 1 приложение можешь в будущем использовать в других. Однако, если так будет, лучше это оормлять сразу в отдельный пакет. ну а вообще в сайтах лучше так не делать по опыту.

то есть общий templates на весь джанго проект лучше?

то есть общий templates на весь джанго проект лучше?

Ну, как общий. Внутри него тоже есть разбивка по приложениям.

В большинстве случаях да

Просто папка с шаблонами вынесена за пределы самого приложения.

не очень хорошо, с точки зрения понимания, когда у тебя код перемешан с шаблонами + всякие там сео заходят шаблоны правят, они не поймут если у тебя все разбросано по мллиону папок и ты им не объяснишь что все это разные приложения, они сайт видят целиком

@mr_rown а скриптом для этой разметки не поделитесь? а то много телодвижений на самом деле получилось :D

нечего сеошникам в мой уютненький кодик лазать

@mr_rown а скриптом для этой разметки не поделитесь? а то много телодвижений на самом деле получилось :D

Сори он слишком личный и он использует несколько личных пакетов для seo и оформления админки (стилизацию). Он тебе не подойдет

Понял :)

Даже не личный мой а компании скорее

а кто знает есть ли сервисы чтобы тестить фронт на эмуляторе iphona?

гугли mobile device browser test

Используете ли вы какой-то готовый модуль для регистрации / авторизации и прочего (не считая Social Auth)? Или все руками? :)

Почему не считая social auth? Его и использую для социалочек, удобно

Я для своего проекта хочу ручную регистрацию)

а, в обычной реге ничего сложного, но можно и пакетом каким-нибудь воспользоваться

Я смотрю как-раз обучающее видео как это делать встроенными средствами. Но там упоминалось, что есть какие-то крутые модули, которые это все еще больше упрощают.

например, https://github.com/ubernostrum/django-registration

Спасибо

Свою регу юзаю

Под каждый проект разную исходя из потребностей