Django Newbie Mistakes • Hacker News Board

Re: Django Newbie Mistakes

#121

Post by Rjevski » Thu, Jun 28, 2018, 6:46 PM UTC

blorenz wrote: post #115

scrollaway wrote: post #105

Earlier quoted context omitted.

Forms are a nightmare to work with. It's a component in Django I systematically avoid, even when using actual forms. Nowadays I use DRF for everything though. Serializers > Forms. And React > Templates. As for the ORM, I long for a world where the ORM is replaceable by SQLAlchemy. Django's ORM is nice and simple, but as soon as you want typed complex queries, SQLAlchemy is really good.

Agreed. Django Forms' hay-day was back in the Request/Response rendering of page state era of the web. They introduced the ability to bind data for validation, rendering in the Template, programmatic generation based on Model and sanitization of form input data. They still can be utilized loosey-goosey on the backend in the world of APIs. Why bother when better tooling now exists? The use-case of Forms now is the Adm…

Just wondering, what do you use instead of Forms for non-Javascript websites?

Re: Django Newbie Mistakes

#122

Post by swah » Thu, Jun 28, 2018, 6:49 PM UTC

jnbiche wrote: post #82

maerF0x0 wrote: post #79

From my perspective there's little reason to be building html serving webservers these days. 1) Frontend React+Redux paired with an API (eg golang http server serving json) 2) Your boss is going to want "APIs!" soon anyways. le sigh. 3) IMO its as easy to do a JSON API HTTP server in golang as python, but you get typesafety, compiled code and multicore ...

> React+Redux paired with an API For building a REST API, there are no frameworks or languages I know of that are easier, quicker, or more user-friendly than Django REST Framework. I say this of someone who is not a big fan of Django in general (although it's not a bad framework). However, I wish that Django REST Framework were build on top of an async HTTP server. Although it's never been an issue, I've occasionally…

I'm trying DRF now (last project in Golang) and one point I have no idea which way to go is how to deliver updates to the mobile client (avoiding polling every N seconds).

I'm not sure I want to try Django channels, which comes with its own spec (ASGI?) and possibly changes the entire way the Django application is run[1].

Should I go with Django channels or - my alternative idea - deploy a separate Golang server only for "real time updates" ? Then I can send updates by simply POSTing from Django to Golang, which forwards the update to the mobile client.

[1] For example: https://channels.readthedocs.io/en/latest/topics/databases.h...

Re: Django Newbie Mistakes

#123

Post by ubernostrum » Thu, Jun 28, 2018, 6:52 PM UTC

jonknee wrote: post #69

Great post, though this bit stuck out for me: current_zip = meta.IntegerField(max_length=5, blank=True) You should not store zip data as an integer as they can start with 0. Zip codes use numbers, but aren't actually numbers themselves (leading zeros, no arithmetic, etc). Plus, someday you'll want to ship something to Canada.

The 'meta' there indicates that you're looking at something properly ancient. The ORM stuff in 'meta' is from the Django 0.9x era, meaning 2006.

If you want to store a US zip code today, use the 'localflavor' add-on:

https://django-localflavor.readthedocs.io/en/latest/

Which provides model and form fields and validation for various country-specific data types. It includes a US zip code field.

Re: Django Newbie Mistakes

#124

Post by pure_ambition » Thu, Jun 28, 2018, 6:52 PM UTC

k1ns wrote: post #11

n0us wrote: post #2

If you're writing a REST api, invest the time to learn Django Rest Framework. It is well worth it.

Seconded. It provides an API similar to that of Django's various Form classes. It should feel somewhat familiar, even to newcomers. Their documentation is also great with rich examples and explanations.

It's my understanding that you can use Django's Form classes to replicate any POST/UPDATE/DELETE operations you'd like to use DRF for. I'm not sure what else DRF gets you besides more API-like auth - for example I don't know how well Django would support token-based auth out-of-the-box as compared to DRF.

Re: Django Newbie Mistakes

#125

Post by pwf » Thu, Jun 28, 2018, 6:59 PM UTC

jaffee wrote: post #13

I feel like I just got into a time machine - this is the top post on hacker news? People are learning Django in 2018? I guess its fine if you have a small project and aren't going to see much traffic, but Python is so slow and difficult to maintian compared to (e.g.) Go. I say this as someone who worked in Python for a long time, and on several large Django projects.

The stuff we used Go for was the right choice for Go for sure, but I don't think the API would have been any easier in Go (though I haven't used those frameworks before...).

We also could have done Django a lot better. And all of the Celery stuff probably should have been Go, especially with the Cassandra driver we were using. Still, I'm using Django today and as long as you don't abuse the ORM and nested DRF serializers too much, it's very scalable. I think as long as you make separate services in other languages at the right time for the right use cases, it's a very valid choice for rapidly building an API.

Re: Django Newbie Mistakes

#126

Post by ubernostrum » Thu, Jun 28, 2018, 6:59 PM UTC

mgkimsal wrote: post #113

> current_zip = meta.IntegerField(max_length=5, null=True, blank=True) This is given as the 'correct' way? Storing a ZIP code as an integer? What does an 'integer' length of 5 mean? Integers have max values, not lengths. "The django docs are so great! They educate you!" I'm presuming most people aren't being sarcastic when they post that sort of sentiment, but it's hard to take those endoresements seriously.

Someone dug up a 13-year-old page from the community wiki and presented it as "this is totally the official Django documentation".

I've added a gigantic warning at the top of it to address this. See also my other comments in this HN thread, for the right way to do what that particular example was trying to do.

Re: Django Newbie Mistakes

#127

Post by ubernostrum » Thu, Jun 28, 2018, 7:01 PM UTC

tiglionabbit wrote: post #44

A lot of these things are only common mistakes because of Django's unusual behavior. > POST to views loses POST data The middlewares shouldn't be redirecting POSTs then! They could have returned a client error instead. > Blank object names They could have provided a fallback of __class__.__name__. > Integer & NULLS If the admin interface knows the field is required, why does it even attempt to insert a null value? It…

Someone apparently decided to link a 13-year-old unmaintained community wiki page on HN.

I've added a big note at the top of the page explaining that, and providing a link to the actual Django documentation.

Re: Django Newbie Mistakes

#128

Post by mixmastamyk » Thu, Jun 28, 2018, 7:02 PM UTC

Django is great at being "batteries included," with tons of functionality for free. One thing that bugs me about these frameworks however is that you have to wire everything together by hand, sometimes from both sides.

Would be great if there were a product built on top that let you drop a model or a view file in a folder and everything would be wired automatically for the default case, customizable later of course.

Re: Django Newbie Mistakes

#129

Post by ubernostrum » Thu, Jun 28, 2018, 7:03 PM UTC

silvestrov wrote: post #71

jonknee wrote: post #69

Great post, though this bit stuck out for me: current_zip = meta.IntegerField(max_length=5, blank=True) You should not store zip data as an integer as they can start with 0. Zip codes use numbers, but aren't actually numbers themselves (leading zeros, no arithmetic, etc). Plus, someday you'll want to ship something to Canada.

It's even worse: zip codes can contain letters and spaces in United Kingdom: https://en.wikipedia.org/wiki/Postcodes_in_the_United_Kingdo...

Falsehoods programmers believe about this HN thread: it links to Django's documentation.

It linked to a 13-year-old unmaintained community wiki page, and people apparently didn't look too closely at it. I stuck a big honkin' warning at the top of the page to clarify that.

If you want to handle US zip codes, UK postcodes, or other country-specific data types in Django, may I suggest this, which formerly was bundled with Django and now is maintained as a separate add-on:

https://django-localflavor.readthedocs.io/en/latest/

It includes such things as a correct dedicated US zip code field, and a correct dedicated UK postcode field.

Re: Django Newbie Mistakes

#130

Post by mgkimsal » Thu, Jun 28, 2018, 7:15 PM UTC

ubernostrum wrote: post #126

mgkimsal wrote: post #113

> current_zip = meta.IntegerField(max_length=5, null=True, blank=True) This is given as the 'correct' way? Storing a ZIP code as an integer? What does an 'integer' length of 5 mean? Integers have max values, not lengths. "The django docs are so great! They educate you!" I'm presuming most people aren't being sarcastic when they post that sort of sentiment, but it's hard to take those endoresements seriously.

Someone dug up a 13-year-old page from the community wiki and presented it as "this is totally the official Django documentation". I've added a gigantic warning at the top of it to address this. See also my other comments in this HN thread, for the right way to do what that particular example was trying to do.

Thanks... ?

Having dates on the pages would probably help avoid some of this in the first place.

People point to a lot of the PHP comments in their docs as "bad" (and many are) but they're also dated, and you can use a comment date of 2009 when trying to give weight to how relevant/useful something may be.

"blank=..." anything is, imo, more confusing than "required=", regardless of what version/age of the docs though.