DjangoBot: #django

visik7 personally, I think it's best to keep them separated, yes.

you can get RequestContext with render_to_response as well, but it's more convoluted

tess, it is preference..but I am not sure if I understand..a plugin's size depends on what it is written, if it is compressed etc. not on JQuery itself. Regardless, it is a moot point.

Emilian, actually, i now remember the exact reason i dont use jQuery. the sortables serialize function. mootools is the only serializer that looks like [ "id", ["foo", "bar"], "baz"]. everyone else looks like [ "id_1", "bar_3", "foo_2", "baz_4"] and that is a pain.

what's the proper way of ensuring certain URLs are always HTTPS?

i mean, whats with the numbers? i would have had to make my own serializer just to format my sortables. with mootools i just try them in as a list. no numbers. pretty silly reason, but oh well.

whatever floats your boat

probably only of interest to myself, but it seems like you can feed strings as date values for object filtering. It seems to correctly convert to date vales for criteria (which SQL does internally anyway, but I couldn't figure out if django did too)

s/vales/values

no more s/// D:

In the docs for modelforms it says: "The form field's label is set to the verbose_name of the model field, with the first character capitalized." but this doesn't work for the label attached to the errors. Is that a bug?

aZmOO i LOOKED INTO IT

IT IS BY DESIGN

haha caps

!!

AzMoo: error keys never use the verbose_name or the label.

I was waiting for you to come online

and no, that isn't a bug

By design? Why?

Error keys always use the actual Python-level genuine name of the field.

the key in the ErrorDict is the field name not the field.label

AzMoo: well, what happens when someone translates your form class?

one normally shows errors next to a field

AzMoo: suddenly the key changes based on active language.

Whoops.

it could still pass the field.label though

not to mention that keys like "some label with text" wouldn't be valid in templates :)

Indeed.

er, 'with spaces' should've been there

So, for quite good reasons, the actual honest to goodness name of the field is used.

right but you can still pass the field.label in the errors

and keep the key as the field name

and then just display the field.label

Emilian: That's what I was thinking

damn, I was about to follow up on that with him.

I put in a ticket, maybe it will get changed

Magus-: I'm not talking keys, I'm talking about the label displayed by errors.as_ul

#6705

Emilian: Thanks for that mate, much appreciated.

no problem

Magus-: Although looking at the actual code for that part of it I see what you mean, but I think there'd be a better way to do that.

DRY... you already have the field label in the field list...

Yep, it's just longer.

Wait, what does DRY mean?

dont repeat yourself

Magus-: Yeah, it doesn't fit in this layout though, so I figured I'd put them all on top.

same here

it shouldn't be that hard to pass it in along with e.messages

Emilian: time to write a patch then ;)

I've thought about it

lol

the way I'd do it is by having the value be a dictionary with a label key and an errors key

does anyone know what file in django actually loads the settings file?

Now, this ticket: http://code.djangoproject.com/ticket/4046 <-- Is the reason that ubernostrum's patch hasn't been included because of the lack of tests?

brehaut: django.conf would likely give you a hint to that

Emilian: I think that'd be a great idea, but I'm thinking totally backwards incompatible.

since you do "from django.conf import settings" to get at them

yes

i had missed the __init__

i havent been in python or django land for a while

I don't see what it has to be compatible with

in the doc of django auth it say that we have to use login( request, user ) but when I run the code I get login() takes exactly 1 argument (2 given) .. any idea?

necrite: don't name your view login, of course

;)

that one got me too when I started as well

ha ha

WTF IS GOING ON?!

D:

Emilian: Existing code? Such a change would break anybody using ErrorDict, wouldn't it?

anyone using django.contrib.gis with the admin application?

Magus-, heheh is the most standar method :P

anyone know if there is a way to get a reference to the module that statements are executing in ?

brehaut: why?

magus: so i can dynamically add attributes to it

why?

so i can have attributes injected into a settings file dynamically

why?

can i specify a custom widget for just one _instance_ of a newform?

jump to the end result already

there's likely an easier way to do things

brehaut: enough with the how... tell us the WHY

brehaut: you have a problem you're attempting to solve via this method. What is the problem.

I'm having the following problem: http://dpaste.com/37833/ I checked the db, and the value I entered is definitely in there.

as much as anything its to see if i can. currently the project ive become involved in uses a bunch of if switches based on host name to let devs configure the settings (mostly DB etc) to their local machine configurations

i want to bust those out into their own domain based files

there's a far easier method for that

then import the relevant ones

insanely easier

Sunmaster_14: you need to set it with a date object, not a string

oh, ok

brehaut: http://dpaste.com/37834/

but it didn't complain at me when I saved it.

put that at the end of the file, then devs can have their own "local_settings.py"

it imports and overrides and boom

"the file" == settings.py, btw

yes i was aware of that

thats what i do myself

just don't put local_settings.py in source control