ты в методе post не передаешь form в контекст

то есть def post() менять надо?

даже не так =)

у тебя в посте форма передается ключом price_form

return render(request, self.template_name, args)?

поменяй на form

args = {'price_form': price_form, 'text_price': text_price, 'text_date':text_date, 'text_driver':text_driver } -> args = {'form': price_form, 'text_price': text_price, 'text_date':text_date, 'text_driver':text_driver }

выше то что у тебя ниже то что нужно

А , тоесть в аргументах ключ менять не надо?

ага

Но ведь самого form у меня там нигде кроме гет реквеста нету

price_form = SchedForm(request.POST)

form, тогда получается по дефолту?

price_form = SchedForm(request.POST)

Спасибо!

очень много порнухи тут. Ненужной

главным образом, потому что от TemplateView наследуется, а не от FormView

Во-первых, можно переписать как-то так (навскидку)

class ScheduleView(UserPassesTestMixin, FormView): template_name = 'somehtml' form_class = SchedForm def test_func(self): return self.request.user.groups.filter(name='groupofcoolguys').exists() def form_valid(self, form): price = form.save(commit=False) price.save() return self.render_to_response({ # WTF-1 'price_form': SchedForm(), # WTF-2 'text_price': form.cleaned_data['price'], 'text_date': form.cleaned_data['date'], 'text_driver': form.cleaned_data.get('driver'), })

обратите внимание на комменты # WTF-1 и WTF-2

WTF-2 означает следующее: зачем здесь инстанцировать новую, пустую форму? В контексте только что созданной записи логичнее использовать форму, которая связана с моделью

это имеет смысл, как мне кажется, для приёма "добавить ещё один чего-то-там"

что и приводит нас к метке #WTF-1

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

можно даже сделать return redirect('.'). Или return redirect(request.path_info), как больше нравится

и (барабанная дробь!) в этом случае вообще ничего не нужно делать

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

Спс за поправки) По пводу WTF2 действительно не подумав сдела) Только 8 дней в джанге)

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

Редирект не делаю спецом для того чтобы одни и теже даынне можно было засабмитить и засрать таким образом базу

Думаю добавить в поле, нде будут отображаться инфа из форм АЯКС дабы страницу не надо было обновлять и получать из ДБ инфу.

Спс за поправки) По пводу WTF2 действительно не подумав сдела) Только 8 дней в джанге)

8 дней на джанге, лучше пиши на функциях

лучше другую вьюху для этого сделать. Серьёзно

а, да

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

Хотя мне об этом говорили не однократно что нужен редирект, но именно в моем случае нужно чтобы база засиралась atpos

для "просто" создания код вьюхи будет примерно такой

class ScheduleView(UserPassesTestMixin, CreateView): template_name = 'somehtml' form_class = SchedForm def test_func(self): return self.request.user.groups.filter(name='groupofcoolguys').exists()

всё.

class ScheduleView(UserPassesTestMixin, CreateView): template_name = 'somehtml' form_class = SchedForm def test_func(self): return self.request.user.groups.filter(name='groupofcoolguys').exists()

Оп, спасибо большое!

8 дней на джанге, лучше пиши на функциях

Я писал на дефах, но тут мне сказали, что я не прав)

наврали

Я писал на дефах, но тут мне сказали, что я не прав)

почему ты не прав?

если нет опыта, лучше на дефах писать

без чёткого понимания, как КБВ работают, можно такого нагородить...

если нет опыта, лучше на дефах писать

Я тоже так считал но тутор был на CBV

бросай CBV пиши на функциях

почему ты не прав?

Забугры говорили, что тяжелов учении. Но не все. \\

практика показывает, что на серьёзных проектах гораздо проще забить и на CBV, и на DRF

Британец сказал учи CBV американец FBV

и писать всё теплыми ламповыми функциональными вьюзами

/me переписал несколько апишных эндпойнтов с DRF на обычные вьюхи. Всё ускорилось в ~2.5 раза

/me переписал несколько апишных эндпойнтов с DRF на обычные вьюхи. Всё ускорилось в ~2.5 раза

DRF это тулкит?

django rest framework

django rest framework

А в чем его преимущество?

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

и, увы, это лучшее, что есть на рынке для реализации RESTful API на джанге

ну, а написать своё?

/me переписал несколько апишных эндпойнтов с DRF на обычные вьюхи. Всё ускорилось в ~2.5 раза

просто JsonResponse ?

по сути просто да :)

свои обвязки, конечно, были для драйности.

но поскольку я чётко знал, чего хочу от API, они работают много быстрее: не пришлось делать всякого рода generic-решения

я уже 4 месяца не писал на джанге питон перешел на nodejs "отлично себя чувствую"(нет)

Самая жесть, конечно, это сериалайзеры. Очень тяжёлые

питон клёвый, зачем переходить.

Когда нету работы, приходиться

жс, правда, с выходом es6 тоже стал не таким чмом, как раньше

темболее для джуна

но всё же для асинхронности нужен специальный мозг :)

но всё же для асинхронности нужен специальный мозг :)

да не, привыкаеш через недели 2-3

ERROR: S client not available

если там завезли что-то типа async\await, то можно и не привыкать :)

вроде в какой-то из современных JS собирались?

если там завезли что-то типа async\await, то можно и не привыкать :)

да, псевдосинхронность)

вроде в какой-то из современных JS собирались?

не знаю

и не понял вопроса )

ну завезти async/await

сам проект на промисах

async/await для душы пишу

ну, промисы это всё-таки коллбеки

а async\await действительно выглядит так, как будто это что-то синхронное

queryset=Destination.objects.all() Можно ли сделать квери по related_name?

чо?

У меня есть две переменные с ForeignKey models.ForeignKey('Destination', on_delete=models.CASCADE) Он сказал, чтобы я задал related_name. Я задал des_from = models.ForeignKey('Destination', on_delete=models.CASCADE, related_name="des_from") des_to = models.ForeignKey('Destination', on_delete=models.CASCADE, related_name="des_to") В Формах такой вид forms.ModelChoiceField(queryset=Destination.objects.all(), empty_label="Не выбран", to_field_name= "name" И на странице он не отображает эти две формы, у меня есть подозрение что queryset нужно уточнить

привет подскажите по django-filter product__name = django_filters.CharFilter(lookup_expr='iexact') хочу что бы по подходящим словам искал

не понял ни один из двух последних вопросов :/

не понял ни один из двух последних вопросов :/

ДА я хотел отфильтрровать queryset по related_name) Думал, что из-за него не отображались формы, но ошибка была в другом

ДА я хотел отфильтрровать queryset по related_name) Думал, что из-за него не отображались формы, но ошибка была в другом

что нужно написать lookup_expr что бы не был чувствителен к верхниму регистру

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

что нужно написать lookup_expr что бы не был чувствителен к верхниму регистру

Я даже не знаю зачем вообще нужен django-filter

Я даже не знаю зачем вообще нужен django-filter

для поиска использую

Я даже не знаю зачем вообще нужен django-filter

в принципе удобная штука

icontains скорее

а не exact

Object.obects.filter(name="name").first()

в принципе удобная штука

Почитаю

icontains скорее

пробовал не помогает

нужно точное вхождение ?

А как сделать чтобы return self. выводил много параметров объекта?

@ra_010 sqlite?

contains тоже пробовал

нужно точное вхождение ?

нет

@ra_010 sqlite?

mysql