#django

I have dashboard for my users, and they'll differ based on the user type. Can I have both running under the same url, but be parsed by different views?

Sure, one view can behave differently based on request.user

Or it can serve as a simple dispatcher to other views.

mattmcc: so, I need 3 views: one main, that will check a condition, and then call my_view_1(request) or my_view_1(request), and in those 2 views I'll have return render...?

my_view_1(request) or my_view_2(request)

That's how I'd do it.

makes sense, thanks

mattmcc: also, what I don't understand about decorator redirect, like @login_required: it redirects anonymous user to login page, setting the `next` parameter to previous url, which is good. Now, how do I make user actually get to said next url after login, given I have custom login view?

If you're not using the default login view, then yes, you'd have to handle doing the redirect yourself.

Are you sure you can't replace your custom view with a LoginView subclass?

mattmcc: https://dpaste.de/QBa7

Yeah, I'd really suggest reworking that to subclass LoginView.

It's a FormView, which means you can modify the form in get_form()

what is a FormView, LoginView?

They're class-based views. LoginView is the default login view.

mattmcc: I can't seem to find anything on the topic in docs

mattmcc: is the way I'm doing it now 'bad' in any way except that 'you should make it easier by utilizing already made loginview'?

Eh, I wouldn't say it's bad, but it puts a burden on you to keep up with changes to the default view.

Back before the login view was a CBV, there might've been an argument for going the fully custom route.

has any one handled SaaS application with twilio integration? I am worried about the right way of doing billing/transactions for SaaS clients usage of Twilio resources i.e calling charges/ phone number purchases etc

I think there are pitfalls in implementing this and need some advice from someone who has worked on similar usecase

mattmcc: the problem is I don't understand how'd I subclass LoginView properly

would I simply override get and post methods, or there's more to it?

or, in my use-case, simply override only post method?

actually, only get method

RandomSerb, you want to redirect user on login?

GinFuyou: I want to redirect user to next url when using @login_required

mattmcc said it's better to subclass LoginView than the way I'm doing it right now - https://dpaste.de/QBa7

RandomSerb, yes but do get your "next" parameter?

I could have simply used default loginview, but I need to change placeholders and class params on fields for my AuthenticationForm

GinFuyou: do I get it? yes

As for LoginView you'll probably want to extend form_valid(), touching post() or get() usually not very clean

GinFuyou: only thing I need `custom` for my login is class html parameter to my fields.

and placeholder

There's a get_form method that handles instantiating the form object. So that'd be where you mess with field attributes.

Yeah, that ^ then

I thought you wanted to mess with redirect too

Useful resource http://ccbv.co.uk/projects/Django/2.0/django.vi... (though I didn't look how LoginView is constructed)

so that means subclassing LoginView, this or that way...

I don't understand the way this works, nor what to override exactly. That said, I'll most likely keep the current code

and implement next redirect myseld

any one has idea how to approach implementing "pay-as-you-go" model for billing system , any resources/help is helpfu;

Stripe supports that pretty well.

FunkyBob: Can't believe you made a million dollar deal with DRF and let them buy out django-nap

sms: hey! not before the embargo expires!

mattmcc, I will tell you my scenario and stripe is not fiiting into my scenrio

i have a SaaS app which has sort of call centre implemented via twilio , I want to manage billing for SaaS clients usage of Twilio resources i.e calling charges/ phone number purchases et

FunkyBob: At least they threw that Lamborghini Diablo into the deal, I'm sure that's why you've been so inactive lately!

mattmcc, I am using subaccounts feature in twilio to bifurcate each organisation's billing who have signed up for my app

do you reckon stripe to be fit for this usecase ?

sms: yah... trying to offload it ASAP

I would assume the Twilio API allows you to query for usage data, which you could use to fill out a Stripe invoice for a given billing period.

FunkyBob: I'll take it off your hands for 15 kilos of soy (just make sure you don't let anybody know what soy is code for)

sms: "soy" ... gotcha *taps side of nose knowingly*

i didnt realise django-nap was sold

its been legacy for a while and i know drf superseded it, but i thought it was just the maintainer not doing it, not because it was sold

thats nuts

but congrats to them i guess

FunkyBob: Thanks, I'll have somebody over to pick it up and the soy should be in your PO box

This is a strange conversation.

mattmcc: recently a couple of people somehow thought nap (a) preceded DRF, and (b) was dead.... I assume duoi and sms are just riffing on the joke

I know I am... nap is alive and well

FunkyBob: Oh what, I didn't realize it was a meme. There was a Buzzfeed publication about django-nap. That's when you know it's official!

jarshwa__: That's a lot of underscores!

FunkyBob: How have you been lately? I heard you had a Pycon talk?

More than one...

schinckel: Thank you for correcting me!

I didn't realize FunkyBob has ascended to a serial Pycon presenter

(Well, one of them is _technically_ a DjangoConAU talk, but meh)