С включеным дебагом

Лол

В джанге, например, можно проверять в темплейтах или лучше декоратором перед самой вьюхой

Но мы шас за плотный фррнт с бэком

Просто систематичности хотелось бы в этом процессе.

Так вот я и не пойму как это всё в кучу связать

Ну напиши свой декоратор

Что бы у тебя любой кому не поподя не послал бы post какой нить на /api/v1 и не грохнул ничего

Так авторизация же

GET запросы общедоступны, остальные по авторизации с токеном

И тогда @логинреквайред

GET запросы общедоступны, остальные по авторизации с токеном

Не все GET должны быть всегда доступны.

Продолжая мюсль богера

GET запросы общедоступны, остальные по авторизации с токеном

Например список юзеров со всеми полями и правами доступа?

Не все GET должны быть всегда доступны.

Не спорю, я про общий случай

Если особенно публичное АПИ, то канеш.

Да и не все остальные для всех групп должны быть)

DEL к примеру)

Ну, апи может быть и публичным и некоторые методы приватными

Окей, а как контроллить такой проект с плотным фронтом? Это надо фронту давать список методов и доку по ним

И писать чтоле паблик/приват

Ну валидация на фронте в любом случа нужна

Лан... нада поработать)))

Давай, я тож

Окей, а как контроллить такой проект с плотным фронтом? Это надо фронту давать список методов и доку по ним

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

Паша, го во флудилку

Окей, а как контроллить такой проект с плотным фронтом? Это надо фронту давать список методов и доку по ним

Да, документировать апи

И версионность во все щели

Окей, а как контроллить такой проект с плотным фронтом? Это надо фронту давать список методов и доку по ним

Или писать всё самому?

Хотя всё равно дока нужна. Запутаешься со временем.

Мы тут @pyflood

кк

https://github.com/hellpirat/django-cookiecutter-boilerplate я тут кстати шаблончик собрал себе для будущих проектов:) на основе cookiecutter, многое у django-cookiecutter подглядел :) Может кому пригодиться, да и попробует. Не уверен насчет настроек docker надо бы их потестить по лучше и посмотреть. В нем я пока еще не очень силен, не давно ток с ним стал знаком :) . Может есть какие-нибудь рекомендации:)

Всем привет!

У меня в проекте есть несколько приложений, и одно из них, так сказать, устарело и более не нужно, и хотелось бы его скрыть, но не удалять. Как этого достичь? Т.е. не удалять сам код, а просто, возможно по урлам выскакивала 404 например, или как такое в джанге делается?

выпиливаешь просто из юрл

отключить приложение чтоле

доступ к этой приложухе и в инсталед аппс

Ну

кхм, ща попробуем-с

Если не нужно, то и не храни его. Смело удаляй, кому надо - из истории коммитов поднимет.

у меня ещё есть приложение как главное приложение, в котором перечисляются все остальные приложения — я для этого завёл модельку, в которой вручную вписываю название, описание, название приложения, вручную урл в виде test_app:index и тому подобное... пришлось добавить туда поле Показывать приложение? булево

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

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

обычный ListView, не?

кхм, у меня всё по методам, а не class based

или это не сложно запилить?

три строки кода. :)

плюс хтмл

просто я придерживаюсь мнения, что если структура одна в приложениях, то лучше её придерживаться

везде одной

кхм, надо будет почитать эту тему

а то например, я изменю урл индекса, и мне придётся ещё менять его и там... а хотелось бы автоматики

в идеале бы вообще хотелось, чтобы, мол, при startapp, задавались 2 кастомных доп.вопроса, типа для названия и описания приложухи, а потом автоматом создавалась запись в модельке

namespace в корневом urls.py, name='index' в урлах приложениё

я не знаю, можно ли такое как то сделать?

а, ну да, он не меняется же обычно

http://mmcardle.github.io/django_builder/#/home типа такого?:D

интересно, юзает кто-нибудь

интересно, юзает кто-нибудь

> Added some new fields from Django 1.1 забавная запись в истории проекта.

http://mmcardle.github.io/django_builder/#/home типа такого?:D

т.е. он автоматом генерит код для моделей?

хз, я так потыкался на сайте, типа того походу wysiwig для модели:D

я имел в виду, что есть главное приложение в виде главной страницы сайта, на которой перечисляются все остальные приложения; а как они перечисляются? для этого есть моделька с полями name, app_name, description, link, is_show например, в которой можно задать название, описание, ссылку на индекс приложения, поставить флаг отображать его на главной странице или нет

напомнило генераторы в рельсах :) я тебя понял:)

startapp generate title:charfield description:textfield

?

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

startapp generate title:charfield description:textfield

не пробовал, надо посмотреть

ERROR: S client not available

я про генераторы в рельсах уже забыл :(

А был же какой-то проект, который пытался воссоздать генераторы рельсов для Django.

https://github.com/modocache/django-generate-scaffold вот, кажется.

ребят, подскажите плиз. Раньше делал так, теперь даже нагуглить не могу( Есть моделька с несколькими полями, как сделать так, чтобы в админке, на странице с объектами модели, было отображение не только заголовка, но и еще описания? Чтобы было два поля допустим, заголовок и описание например.

def __repr__

list_display = ['title', 'descritption']

list_display = ['title', 'descritption']

вот так в admin.py, не работает class ProjectAdmin(admin.ModelAdmin): list_display = ['title', 'description']

@admin.register(Blog) class BlogAdmin(admin.ModelAdmin): list_display = ['title', 'category', 'active']

@admin.register(Blog) class BlogAdmin(admin.ModelAdmin): list_display = ['title', 'category', 'active']

во, с декратором заработало, спасибо

Вариант извращённого использования репра в модели: @classmethod def __repr__(cls): return '%s/%s' % (__package__, str(cls.__name__).lower()), cls._meta.verbose_name_plural.capitalize()

Использовалось для передачи ссылки в шаблон и заголовка на странице)

Кто как отправку сообщение реализует? Имею ввиду сам сервер почты.

smtp google

Ну, классика. Доверенное приложение, ключ, ключ в сеттингс.

Клиент хочет, чтобы к нему сообщения формы контакты приходило письмо к нему на gmail

Да. И для этого тоже.

Кто как отправку сообщение реализует? Имею ввиду сам сервер почты.

можешь еще sendgrid глянуть

Такой вопрос. Мне нужны raw sql, они большие, там джоин по 5 таблиц. Во view пихать глупо, поделитесь опытов, как вы организовывали свои raw sql в проекте. Как разбивали на файлы, все в один в рамках проекта или делали модуль и еще как-то дробили?

знаю, что делают часто utils, но мне кажется, что это не подходящее место для SQL

А почему просто это не делать python way - модули и пакеты?

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

как обычно делают

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

Имхо где хранить еще и от текущей структуры проекта зависит

Как и любой импорт. Смотри, что и куда ты будешь импортировать. Есть смысл, наверное, разделить квери по моделям откуда тащишь. А вообще, это уже скорее вопросы предпочтений.

у меня запросы к моделям конкретным не относятся. У меня запрос возвращает набор, собранный из 5 разных таблиц.

это нужно все в пределах одного аппа. Другим аппам в проекте эти запросы не нужны

Менеджер тебе не подходит?

http://whitenoise.evans.io/en/stable/

Спасибо

Ну тогда my_app/queries

manager.raw()? или про что ты?