Re: prepopulate form with model instance values using UpdateView and ModelForm

Hi Sergiy,

Thanks for your help!

1) I tried overriding the GET request as you suggested and the print statement never went through. It looks like by default it calls `get_object()`, and my `get_object()` code is running, so I'm not sure why it doesn't appear.

2) The form is appearing with the correct fields but it wasn't populating. All of the weird overrides I had in `display_field_values()` were populating the fields but it looks like for some widgets that's not a good solution (I mean, probably a bad solution even when I could get it to work.) Those were running in the form's `__init__`.

I think at this point I may just take Melvyn's advice and include the pk or a slug in the url. Appreciate the help though. If you're able to share the solution that you found to your problem I'd be very interested to see it.

On Thu, Jan 19, 2017 at 8:02 AM, Benjamin Dauer <dauer.benjamin@gmail.com> wrote:

Hi Sergiy,

Thanks for your help!

1) I tried overriding the GET request as you suggested and the print statement never went through. It looks like by default it calls `get_object()`, and my `get_object()` code is running, so I'm not sure why it doesn't appear.

2) The form is appearing with the correct fields but it wasn't populating. All of the weird overrides I had in `display_field_values()` were populating the fields but it looks like for some widgets that's not a good solution (I mean, probably a bad solution even when I could get it to work.) Those were running in the form's `__init__`.

I think at this point I may just take Martin's advice and include the pk or a slug in the url. Appreciate the help though. If you're able to share the solution that you found to your problem I'd be very interested to see it.

On Thu, Jan 19, 2017 at 2:57 AM, Sergiy Khohlov <skhohlov@gmail.com> wrote:

Hello, 

 I had a similar problem  (but I'm using DetailView for sending some additional data) and I hope I  can help

 Usually editing page  is  using GET for receiving  default data and POST for sending  data from  form to  view ( we are skipping ajax way)

1) You would like to set initial data to the page but  default get is not customized 

Could you please  add    next code to view 

def get(self, request, *args, **kwargs):

    """  Default  GET view"""

    print ("Default view is calliable")

    return super(ModifyTaskView, self).get(request, *args, **kwargs) 

2) Also  have you seen any printing of your form ? 

 I would like to separate task in two simplest task 

 1) Verify if view is preparing data for form 

2) Verifing populating form by data 

Many thanks,

Serge


+380 636150445
skype: skhohlov

On Thu, Jan 19, 2017 at 3:22 AM, Melvyn Sopacua <m.r.sopacua@gmail.com> wrote:

On Wednesday 18 January 2017 14:26:52 Benjamin Dauer wrote:

> Hi Melvyn,

>

> That's exactly what I'm trying to do, but prior to making the changes

> it wasn't prepopulating. At each stage I tested and was getting blank

> fields albeit based off of the correct model.

>

> Maybe it's because I don't provide the pk in the URL? I was trying to

> avoid that.

 

Gotcha! By default the class-based generic views provide two ways to identify the instance:

- pk

- slug

 

Look at slug_field and slug_url_kwarg here.

 

But in the end, this is passed to get_object() (method also shown on that handy page) and this shall return the instance to be shown.

The tricky part about passing this in a form, is that you're fighting the order: the form is processed after the instance is loaded.

 

The best way to go is to put something in the URL that uniquely identifies the object and then override get_object() to work with that. Note that little added security is gained from hiding the PK, but if user-friendly URLs is what you're after, slugs (or some other field(s) with unique=True) are the way to go.

 

--

Melvyn Sopacua

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/17336152.2CZh43FIzZ%40devstation.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CADTRxJMyg9cW0SEfdu69f8T12KggrqxQCnYHdiJ7FGFL_HzstA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2BeihEjBuVYW7fh0UL-R8ixs4hzR3Bn9yP-ROxd74s%3D7kmxHyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.