Django Web Framework: The 'D' is silent dumbass

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

«‹›3 »

Dominoes: Sep 20, 2007

Thermopyle posted:

Snake case because most of your coding should be done on the backend, not the front.

That depends on what you're doing. There are lots of things that can be calculated in-browser without having to pass data over the internet.

# ¿ Sep 14, 2018 20:23

Adbot: ADBOT LOVES YOU

# ¿ May 16, 2024 21:24

Dominoes: Sep 20, 2007

Business posted:

I'm just learning and going through tutorials and I have a dumb question. When people work on a project in django, are they generally just VIMing or whatever around to the different things they need to edit each time they add something? I hope it's just a learning curve thing but I'm finding it hard to keep a 'map' of every file that needs to be edited each time I add a new page or template or whatever. Relatedly, is there a good way to keep track of your db models other than just keeping them in a text file?
I feel like I get how the pieces fit together over the course of a tutorial or whatever and debugging hasn't been bad but I'm having a hell of a time keeping up with all the moving parts even in a small project

Tabs in Pycharm

# ¿ Feb 11, 2019 06:08

Dominoes: Sep 20, 2007

I love the new model enums; it's something I've wanted for a while. Gives you different varieties based on how you want it to be stored in the db, ie integer, char, or something else, then works like a normal enum in the Python code.

Migrating's easy, assuming you don't change how the data's represented in the DB.

Ie replace this:

Python code:

# choices
A = 0
B = 1
C = 2

class AModel(models.Model):
    CHOICES = (
        (A, "A"),
        (B, "B"),
        (C, "D"),
    )    
   val = models.IntegerField(default=A, choices=CHOICES)


#...
if my_model.val == models.A:
    pass

with:

Python code:

class Choice(models.IntegerChoices):
    A = 0  # Still explicitly define the integer value for frontend compatibility
    B = 1
    C = 2

class AModel(models.Model):
   val = models.IntegerField(default=Choice.A, choices=Choice.choices)

#...
if my_model.val == models.Choice.A:
    pass

There are probably other patterns compared to the first one I posted; I'd been using that since it was relatively clean, but involved unassigned module-level vars, which I don't like. It now feels like a proper enum.

Dominoes fucked around with this message at 03:59 on Dec 3, 2019

# ¿ Dec 3, 2019 03:48

Dominoes: Sep 20, 2007

The only thing that broke for me was having to replace { % load staticfiles %} with { % load static %}. Check out the list of removed features.

I finally was able to remove this comment from my models.py: # Choices listed here; Django should just support enums directly...

# ¿ Dec 3, 2019 03:56

Dominoes: Sep 20, 2007

epalm posted:

Can we talk about Class Based Views for a sec?

I understand the motivation behind CBV. If you kept iterating on how Django views work in a CRUD context, and kept automating away any duplicate/boilerplate code, I can see how you'd end up at CBV. But suddenly, How Things Work is now hidden behind a bunch of inherited classes, and because I haven't sat down and formally learned the ins/outs of each class, I have to constantly check the source to figure out how they work, which variable to set, what types they expect, the order in which all these functions get called, etc.

I get that they've built this nice efficient machine to get work done in the smallest possible amount of code, and I agree that's a Good Thing, but what they've lost is the simplicity of FBV. Here's the function, here's the Request, just do what you need and return a Response.

I know the right answer is for me to stop whining, buckle up, and just learn CBV, but what drew me to Django in the first place was it's simplicity, and I feel like the transition from FBV to CBV is an increase in complexity.

Anyone else feel this way?

Never use them; no reason in particular, it's just that Django has a huge surface area, and you don't need it all to get things done. That said, I'm curious what I'd get out of them, since function views are quite elegant and minimal as they are.

# ¿ Dec 3, 2019 18:30

Dominoes: Sep 20, 2007

Much appreciated. I think I need to read one of those tutorials and see where it would make the code cleaner.

Does anyone know how to handle CSRF tokens for forms? If I'm making a normal fetch request, I can pass the token as a header, after retrieving from document.cookie and doing some processing.

For using the <form /> approach, which I've been using for file downloads (There may be a way to download files with Fetch, but I'm struggling on that too), I've been using a React component, where you just insert this tag somewhere in your form: <DjangoCSRFToken />. How can I do form based approaches without the React module? I'm doing a non-react project, and want to download a file, but am struggling.

Edit: I think I solved it, by passing an input with type="hidden", name="csrfmiddlewaretoken", and value, the result of the document.cookie used in the first approach. Gleaned from the Github of that React helper page.

Dominoes fucked around with this message at 21:07 on Dec 3, 2019

# ¿ Dec 3, 2019 20:48

Dominoes: Sep 20, 2007

Hey - I'm having a struggle with preventing people from making superusers from the default Admin User page. About 80% of the time my custom form without the superuser tick works, but sometimes the original form works, and lets staff members make someone a useruser. (eg from mashing F5, or getting lucky) Relevant code:

Python code:

admin.site.unregister(User)

@register(User)
class CustomUserAdmin(UserAdmin):
    def get_form(self, request, *args, **kwargs):
        form = super(CustomUserAdmin, self).get_form(request, *args, **kwargs)

        self.fieldsets = (
            (None, {"fields": ("username", "password", "is_active")}),
            (_("Personal info"), {"fields": ("email",)}),
            (_("Permissions"), {"fields": ("is_staff", "groups")}),
            (_("Important dates"), {"fields": ("last_login", "date_joined")}),
        )

        return form

Any idea what's going on, ie why it sometimes works and sometimes doesn't?

Is there a more "hard" way to prevent people from creating superusers at a deeper level than hiding fields? Using the latest Django. Thank you.

# ¿ Sep 18, 2021 16:03

Dominoes: Sep 20, 2007

Thank you. That worked!

# ¿ Sep 21, 2021 10:39

Dominoes: Sep 20, 2007

Data Graham posted:

Someone please tell me if there's a better way to do this.

Python code:

class Category(Enum):
    A = auto()
    B = auto()


@dataclass
class Widget:
    widget_type = models.CharField(max_length=20)
    category = Category
    thing = models.ForeignKey('things.Thing', null=True, blank=True, on_delete=models.SET_NULL)
    customer = models.ForeignKey('users.Customer', null=True, blank=True, on_delete=models.SET_NULL)
    timestamp = models.DateTimeField(auto_now_add=True)
    field = models.IntegerField()

# ¿ Mar 19, 2022 02:05

Adbot: ADBOT LOVES YOU

# ¿ May 16, 2024 21:24

Dominoes: Sep 20, 2007

death cob for cutie posted:

I'm helping to take over Votefinder, a Django project for keeping track of voting in games of Mafia on the forums.

That virtue signalling is kind of scummy

# ¿ Apr 1, 2023 01:58

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

«‹›3 »