#django

ICheeseYou: ?

you wrote "ICheeseYou: !" after I said " morning all (in this side of the world)"

hence Im a bit confused

consider it a positive greeting

HOLY SHIT IT WORKS

omg. I can't believe it.

heh

gaze upon that beautiful code

consider it considered

I should snippets this.

It's that friggin' elegant

heh

please to critique, FunkyBob

Can I not do this with templates? http://pastebin.com/qhq5JYBy

picoguy: you can't conditionally define blocks, no

blocks are defined at template parse time

Evening all, was wondering if someone could help me with a best practice type question. I've seen about 3-4 approaches to what I'm trying to do and just need some second opinions

FunkyBob: alright :( thanks

Reddog[0]: shoot

I have some user form pages I'm trying to make friendly, and I've got a main model with some just ordinary CharFields on it. This Model can also have images associated with it, and so I'm wanting to create an ajax view that allows me to upload the images on the fly

That's all working fine

My question is how I then can associate the images that have been uploaded with the main model on that form

My first thought was maybe a modelformset, get ids back from the ajax call, and stuff them in hidden input boxes

FunkyBob: is there an easy way to restrict a page to specific users?

but that seems maybe like overkill

picoguy: user_passes_test decorator?

Reddog[0]: hrm... tricky

hcalves: me again regarding multiple model managers. the problem I have now is that i have to inherit from both manager Models, which seem impossible. i'm trying to combine django-fts with a model that already uses geodjango ( https://github.com/ryszard/django-fts/blob/mast... and https://docs.djangoproject.com/en/dev/ref/contr... )

FunkyBob: ok ill look into it

Yeah... For the sake of clarity let's say the main form / page is an "Event" and the ajax-y upload things would be photos for that event

To skip the model formset I could use like a hidden input box with a comma delimted list, or json-encoded array, but that seems awfully hacky

sonmi: it certainly isn't, because I already did something similar

sonmi: you just need to find the Manager class GeoDjango appends to the model class, and inherit from it

sonmi: more specifically, https://github.com/django/django/blob/master/dj...

hcalves: multiple inheritance of bother the geodjango and fts manager into a new manager class? okay, but what about my model itself having to derive from both fts.SearchableModel and the geodjango Model?

sonmi: MyModel(GeoDjangoModel, SearchableModel)?

sonmi: there's nothing too magical going on. just inherit a new Model and Manager base class

hcalves: doing that leads to "TypeError: Error when calling the metaclass bases | Cannot create a consistent method resolution | order (MRO) for bases Model, SearchableModel"

FunkyBob: Any ideas or general direction you can think of? Or, almost as good, any "definitely don't do that" advice?

sonmi: SearchableModel is just this: https://github.com/ryszard/django-fts/blob/mast...

you can just inherit the managers if you want

Reddog[0]: you sound like you're on the right path... assuming you must "ajax" upload the images before you submit the form...

you'll might have to tweak some stuff though, I remember trying to use this django-fts library and found a bunch of problems with custom querysets

hmm, good point, although I wonder what the module private _VectorField() will do - would that be missing hten?

or you could just have them uploaded to the right spot, and stuff those paths into a formset

FunkyBob: I don't necessarily *have* to, but I think it makes the user experience considerably nicer

hmm

sonmi: if you only need to support full text search in postgres, I would recommend taking a look at this library: https://github.com/hcarvalhoalves/django-tsearch2

sonmi: django-fts only provides a search() method on the manager, you can't search on querysets

hcalves: taking a look at your library, thanks. is there a usage example?

I should probably update it and add documentation

will do that no

*now

hcalves: haha, thanks!

the options are very similar django-fts though

there's a sample project you can look for usage, under tsearch2_dev

hcalves: okay. will mixing SearchableModel and geodjango Model go smoothly though? i might have to find out the hard way

hi -- is it possible to define a group with certain permissions in code, rather than in the DB? this group doesnt need to admin access, so i rather it be stored in code and available to all instances of the site (staging, production, testing)

sonmi: I remember I wrote this library specifically because I had trouble inherint from GeoDjango and using full text search fields from other libraries

sonmi: I'll add documentation then it might help you

hcalves: cool, thanks

anyone know a good way for me to override `upload_to` on this line (https://github.com/stephenmcd/cartridge/blob/ma...) without forking Cartridge?

ah the joys of bringing an IRC channel to its knees

__love__: the real question is.... why?

because i don't want file name conflicts and i don't want to maintain a fork of cartridge?

I reckon stephenmcd might accept a patch that let you set the valeu for that in settings...

stephenmcd: what say you?

I actually rejected it a while back

lol

stephenmcd: why's that?

it was a while ago so I don't recall it well, but I believe the rationale was that they wanted to use a different location entirely which I said should be handled by a storages backend

and that there's probably a dozen or so file upload fields across the project, should every single one have a different configurable setting?

CARTAGE_STORAGE_DIRECTORIES = {}

that or namespace your upload_to's ;)

it just seems like solving it at the wrong level

the notion is that "product" conflicts with some other app's upload directory

should every single third-party app in a project have a configurable upload directory?

ideally, yes

your hardcoded idea will never be right in 100% of cases. probably not even in 50%

as soon as you introduce the idea of multiple users creating products, anonymously to each other, your hardcoded path has become nothing but a giant naming conflict waiting to happen

hey FunkyBob - if you define get_query_set in a Manager, can you pass a parameter to it for use in a queryset filter?

what do multiple users have to do with it, doesn't Django handle duplicate filenames?

stephenmcd: it can (and does by default, yes). but it also gives me one giant directory of images

how would changing the value of "product" change having a single directory for all of the images for that field?

stephenmcd: if it's a function, i can pass in the user's id/username, the product name, whatever, to help namespace things

right that's a good argument, I didn't know you could pass a function in

yea passing a function into upload_to is awesome

dstufft: i never do anything else

personally I don't see a problem with a single directory, but that's just me

that doesn't work so well whne you have a ton of people uploading the same thing :)

you know linux does have a limit on # of files in one directory, right? (at least AFAIK)