#django

Hello. Where is the best™ place to implement a constraint for ManyToMany fields? I don't want to allow certain combinations of m2m on instances. The first I can think of is an explicit through model and its save() method. Any better idea?

doesn't somebody else wish forms came with a default prefix? something like self.__class__.__name__.lower()?

Hmm, i'm trying to get swapper thing working. Do i even need it if i don't want to provide default implementation?

vlt: sounds about what I was thinking

vlt: https://docs.djangoproject.com/en/2.0/ref/model... but I don't recall whether this works for m2ms

I think you might be right, or at least use this on the through model, rather than on the parent

FunkyBob, lacrymology: Thanks.

Hey, got a question around form generating. When I do {{ form }} in my template and then edit record via view tied to that template I get one of the radio buttons selected (according to value set for that record in Model). Its all working fine. One of the radios would have 'checked' attribute which indicates its state. I am in the process of writing my own form and got to the point where I need

to select specific radio, but have no idea how can I access this attribute in my template. Does anyone know?

crs, https://docs.djangoproject.com/en/2.0/topics/fo...

crs: I don't think I understand your problem exactly. What are you trying to do, and what are you missing? generally, {{ form.that_field }} should render the <input> correctly. Setting `instance` in a ModelForm or `initial` in a regular Form should pre-set the `selected` attribute for you

lacrymology: well, for the 80% case, there's only 1 form on a given request, so there's no *need* for a prefix. The same is true if there's no overlapping fieldnames, so it's only multiple forms which share field names which would really require it, which is off the beaten path enough that setting it on the class or instance is easy enough

Thanks guys, so, I need to call some js on wrapping container for preselected radio (https://getbootstrap.com/docs/4.0/components/bu...). So I need to know which one it is somehow. I got a field with three options and want to have buttons like in the link I pasted.

I'm unable to use django's template filters inside a js script tag: i.e. this `{{ extent.geometry.geojson | safe }}` doesn't work? is there an alternative?

hi

Design pattern question: Where would I best put the handling of AJAX requests where the response would be a JSON - very related to a model? As the view.py is kind of the controller (?), I would be tempted to have it in there, is this the right approach or should I potnetially create a new app, call it api, and have all the AJAX things done in there, given that there will be a lot of AJAX going

on. (Django 2.0, Python 3.6, Python experienced, Django novice)

kezabelle: but on the other hand it doesn't hurt any, and would fix a lot of simple bugs, and would make the whole thing escalate better for the cases in which you start with only one form, but start extending.

overall, support for multiple forms in stock is pretty poor.

and I haven't been able to devise a general strategy that convinces me either

lacrymology: So I am iterating over my radios and one of them is like this: <input type="radio" name="style" value="3" id="id_style_3" required checked /> -- how can I check if this 'checked' attr is there so I can add a class to wrapper container (css)?

lacrymology: I kinda see your point, dunno how existing prefixes might play with formsets, but shrug. I've always just lived with putting it on the instance (or the class, when that started being supported) ... it's not that hard, and it makes it clear which form cares about which prefixes if its inline :)

crs: ahhh

crs: https://stackoverflow.com/questions/9221010/how... the selected answer covers that, I think? just check {% if field.value == option_value %}.

I'd almost check whether it's worth subclassing RadioChoiceInput

lacrymology: Not sure if that question covers what I need. Unless I am not understanding it properly.

lacrymology: They are iterating over choices there, I do: {% for radio in form.style %} where style is my field.

lacrymology: I know one of radio.tag will contain 'checked'. Maybe I can just search for it somehow?

crs: and what does that iterate over?

lacrymology: all radios available for field. Please have a look here: http://wklej.org/id/3376231/ -- you will see that last last radio has checked - for this radio, I would like to add active to its label's classes.

crs: I checked it on the shell, let me show you

lacrymology: Please note, if you haven't noticed yet, I am super beginner :)

crs: https://dpaste.de/Zp8N

lacrymology: Actually, managed to do it like this: {% if 'checked' in radio.tag %} and then tag with active, otherwise tag without… Is it very ugly?

crs: so {% for radio in form.style %}<div class="{% if radio.choice_value == radio.value %}checked {% endif %}">{{ radio }}</div>{% endfor %}

crs: yes, it's pretty ugly

Ahaaaa!

first, you're doing full-text search inside the tag string

I get it!

second, there might be a different "checked' substring somehow. You might eventually have an "unchecked" class within the tag, for example. A contrieved example, but since you've got access to the actual data you want, it's definitely better

"checked" may be the value of the style, too

like, it might be one of the options

Hmm, that makes so much sense. Thanks a lot! So, I added it to my radio loop (haha! (sorry)) and it added checked to every single one of them. ;/

?

you added what?

lacrymology: <label class="btn btn-outline-secondary{% if radio.choice_value == radio.value %}checked{% endif %}" for="{{ radio.id_for_label }}">

missing space, but that's not the problem, it adds checked to every item it iterated through

And I htink I know why…

Ah, no, actually I don't know why.

let me test

lacrymology: Thanks a lot!

works for me

crs: ^

paste your code

lacrymology: Hmm, odd. What I did now was to add things like: Radio value: {{ radio.value }} to my template. It seems like they are not printing anything. Perhaps it is boolean? Not sure. Anyway, id doesn't print anything for all radios…

lacrymology: 1s

you can also debug like this, maybe? https://dpaste.de/otVg#L2

Ah, perfect. :)

paste your actual template code, and possibly the Form class and instantiation as well?

Yeah, it returns: <!-- -- -->

lacrymology: Can I send you link to the repo on /query?

can't you just paste to dpaste.de?

I mean, I assume you haven't committed what you've just done anyway

lacrymology: I did. :) New thing, not carrying about the history at all just yet.

ok, whatever

crs: for reference: it should work (https://dpaste.de/Q5vA)

hi all. Super basic question. Model A has a one-to-many relationship to model B. Meaning, for every A object, it can link to multiple B objects. What's the difference conceptually between defining my ForeignKey field inside model A vs B?

trying to find a way I can always remember this basic concept

blip99: depending on where the FK is, decides where the one is in "one to many"

blip99: if the model has the FK its the many

blip99: if the thing can have only 1, the FK goes there. So the B has 1 A, so the FK goes there, and the A gets the "many" part via a reverse relationship

GraysonBriggs, kezabelle: Perfect. That wording makes it stick. I always end up thinking or wondering while looking at a UML diagram, that I must define the FK on the model which is connected to other models - else Django can't follow the relations (I know, nonsense, not sure where the thought comes from) :)