#django

haha rather.

But we have if self.request.method == 'POST': now

I figured it wasn't required anymore.

that doesn't matte if you never reach that code!

you turned my view function back into a view class...

True.

so in my function ... the part that was before the "if request.method == 'POST': " ... is now in dispatch, effectively

and then the other bits become the get() and post() methods, roughly

So i still need seperate clasess for add,edit, list etc?

I sort of combined it all into one.

I've confused myself. :/

no

how many URLs are you dedicating to this effort?

list, edit, delete, add.

for events.

well, we _were_ working on the add view...

however, since bits of this class can be shared (the get_set_event method) ... we can still keep that dry

Yes, that's where I was going.

then when declaring your view class... "class EventAddView(EventMixin, View):"

That's handy.

OK, I'll try with that quickly.

wait 'til you discovere the class-based Generic views :)

and how CreateView and UpdateView already do most of your work :)

hehe. It has been an experience.

as well as ListView and DetailView

Oh yeh, I worked on that for an API a few days ago.

It's just so quick and easy to maintain. And making changes sort sort themselves out. It avoids spaghetti code down the track.

But doesnt this mean the if self.request.method == 'POST' is redundant?

yes

It feels like we've gone full circle, but with. a mixin now.

looking better

however, since you only want set_event for the template context

ah, well... we're just using View, not TemplateView or anything else that renders for us....

I was going to move the get_set_event() call into get_context_data... but you're not using that [yet]

ok. I'll turn on edit, delete and list and see how I go.

def get(request):

that should be "def get(self, request):"

Yeh, just updated that.

for reference, if you used a CreateView, this is what it'd take: http://dpaste.com/3ZT7BYJ

oops... b0rked the indenting

because handling form processing is such a common task, there's a _generic_ class pre-defined for it

FormView [for forms in general], CreateView for one that creates a model instance with a modelform, and UpdateView and DeleteView [you'll guess :)]

Oh, that's different to what I saw the other day, and even cleaner again.

actually, youj might also need to specify the model.... don't recall

So I should never copy the migrations directory to a production machine, it must create it's own one right?

no no!

exactly the opposite

Oh really?

you _always_ include the migrations dir

it describes how to migrate from one DB state to another

and may also include data migrations the developers have written along the way

OK, I need to go read up on that again, I've misunderstood it.

I saw it as just a cache of what's been done managed by makemigrations.

no, it's not a cache

this is why "makemigrations" and "migrate" are separate steps

afk... going on a picnic with the fambly

Thanks for your help!

django.db should actually be a standalone package, I love the django orm

hey is **kwargs the same as **extra_fields ie as long as i have **followed by a name of some sort ..it is effectively kwargs

i could say **god_bless_america

and it would effectively be == **kwargs

yup

**god_bless_north_korea is the same as **kwargs. *args works the same. *args is equal to *god_bless_china

I have an insert that is causing an integrityerror because of a duplicate entry (it's defined in unique_together in the model). How do I catch the exception?

except (Model.DuplicateEntry): ?

I went with except IntegrityError as e:

gcain: do you use get_or_create?

No, it's a Model Form, I just used save()

gcain: sounds like you should catch during form validation

and yes, IntegrityError too if necessary

Something like over ride form_validate?

gcain: clean()

Perfect, thanks.