#django

indeed

any advice on my question?

desophos: sorry, JS isn't really my thing

override __init__

FunkyBob: on what?

on the form

are you trying to do a dynamic cascading select?

no, not cascading

everything stays the same except the form

i mean the input fields

i just want to populate the fields of the form based on the fields of the model, but i want to be able to do that by selecting a model on the page

i don't even have a custom form defined

how can you have a form with no form defined?

if you use a basic ModelForm, as it shows you in the docs you can pass the model as instance= and it will populate it

sorry, that's what i meant

a basic ModelForm

I'm confused about what you are saying and what you are saying you meant

FunkyBob: Greetings of the season!

sorry. i know about instance=; that's what i was planning to use, but how do i get the model that the user chose in order to pass it as instance?

wait... I think you may need to start this again

i want to repopulate the form with the model fields every time the user selects a new model

what do you mean "the model the user chose"?

or do you mean the instance of the model?

cilkay: hey... how's things ?

Making progress on my DRF + AngularJS application. The question above reminds me why I chose AngularJS. :)

How are things with you?

cilkay: heh... personally I'm a fan of KO...

when i do this: http://dpaste.com/2XXCJDH

things are ok.. I'm the only one in the office, and am writing extensive and pdenatic tests for a revised API using nap

i end up with raw strings in my HTML src

instead of <label> tags

is that normal ?

limbera: how are you rendering it?

{{ field.label }}

Tests... who needs 'em? :)

cilkay: this client... badly

in a {% for fields in form %}

FunkyBob: sorry, i'm still not totally clear on the terminology. i mean that there's a <select> dropdown with a list of different customers, and the user chooses one, which corresponds to a DB entry; then, the form text fields should be populated according to that entry's fields. once the form is populated, the user can select another customer from the <select> dropdown, which overwrites the existing form fields with its own data.

and i'm not sure of the best way to accomplish that

desophos: ok, so you want to use AJAX to populate your HTML form fields according to the instance selected by a select list

yes

so you need either: a) a view that returns the instance values as a JSON blob and b) JS to update your form inputs with this data

or (a) a view that returns the HTML for the form, and (b) JS to replace your form markup with what's returned

well, one more thing is that all the values for all the relevant instances are already in the context

desophos: that's meaningless... you're talking about doing work in the browser... so there is no context any more

the template is rendered, the game is over...

oh, ok

in that case, i'm trying to do the former of the two options you mentioned

but isn't there another option? i.e. give the view the instance values and have it populate the form using instance=

FunkyBob: am i not rendering it correctly (regarding form labels)

limbera: dpaste the actual template

ok

desophos: as I said, you could have the view render the HTML for you

limbera: I think you want {{ form.label_tag }}

gotcha

perfect thank you

FunkyBob: oh right i see, what i just said was what you were referring to with the latter option

so then, which is the better choice?

desophos: well, that's the $64,000 question, innit? :)

if your app is likely to provide mroe of a RESTful interface to your data, then the JSON approach is probably best

hmm... unfortunately, the option values aren't enough information to find the correct instance in the DB (not unique identifiers). is it bad to include PKs in the HTML?

'Allo. My client has asked for two things to be in an upcoming release: (a) upgrade to django 1.7 (b) include a fix that will require a data migration and a database schema migration. So I'm in the position of working out how to do a switch from south -> django migrations AND some migrations as well. On a scale of one to bad, how bad an idea is this?

Django's default method of rendering selects is to use the object PK as the option value

Derailed: not bad

FunkyBob -> you think it's workable?

Derailed: my path would probably be: (a) make sure all existing deploys are fully migrated, (b) rename migrations/ to south_migrations/ in all apps, (c) create initial migrations for django 1.7, (d) create data/schema migrations in django 1.7

FunkyBob, does the rename make them invisible to South, or does south still find them?

Derailed: South 1.0+ will prefer south_migrations/

^^ looking at docs I see

cool, that's a good first step then

Cheers -- I admit I asked before going through the docs in detail (sorry FunkyBob), I'll read through and see what's what.

the migration has to delete some stuff from the database and then add a constraint to prevent it happening again

I haven't had to do a data migration like that before

it's simple

at least, it is in South :)

Hi there, had a quick questions on migrations as well. I’m trying to alter my primary key into using a UUID but I get the following error on runing migrate https://gist.github.com/rserna2010/e765ba3aaa48..., here’s my model https://gist.github.com/rserna2010/67ca122e407f... and here’s the migration I’m attempting to run: https://gist.github.com/rserna2010/037bc7d88fca...

ras__: the nightmare of changing your PK type is you have to also update any other model that has a FK/1to1 to it

ah this is still in development with no real data to store, do you just suggest deleting the migrations and dropping the table?

FunkyBob: if i were to go the form-repopulation-route with instance=, how would i re-render just the one form without messing up the other parts that depend on passed context?

desophos: well, you wouldn't use instance=

unless you were trying to leverage a ModelForm as a cheap API serialiser tool [a valid approach]

oh, ok; the appeal of instance= for me was that it would automatically handle the fields, giving some degree of future-proofing

so i wouldn't have to fiddle with the fields manually every time i change the model

desophos: I think you're confused about what's going on

probably

and how things work

definitely

instance= is an option for passing to a ModelForm

but if you're passing JSON blobs.... typically you don't use the modelform

well, i mean instead of passing a JSON blob (for that i would just return an HttpResponse to an ajax GET request, right?)

uhh wait

mmm?

if you don't return a JSON blob, what are you returning?

well, instead of having the view serialize the instance, it would use the instance directly to recreate the ModelForm

and then what?

what will your view return to your JS?

nothing; the view would re-render the template

it's sounding increasingly like you have trouble understanding what's client side and what's server side

re-render the whole template?

ouch

I thought you were going with an AJAX solutino

to avoid re-rendering the whole page

right, i was also trying to figure out if there's a way to re-render just the one form

yes, and can also be done using AJAX