Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django Newbie Mistakes

code.djangoproject.com

Post reply on HN
Print view View original

181–190 of 225 posts

Re: Django Newbie Mistakes

#181

Post by Izkata »

ryanisnan wrote: post #80

I've worked with django for a considerable amount of time now (~9 years), and I have found the documentation a joy to work with. The documentation generally covers each piece of functionality, and the source code is rich with documentation. When it comes to django itself, there are nuances, and yep, some of them probably can be smoothed over for developer experience, but developers must have knowledge over their tool…

> and I have found the documentation a joy to work with.

> Maybe look at the source code?

My co-workers sometimes think I'm a magic supergenius with how easily I've been able to answer some of their Django questions. It always comes down to one of those two things: A vague memory of something I'd seen in the docs just scrolling through it in the past, or having seen the same problem they have now and used pdb to step through Django code to learn how parts of it work.

Re: Django Newbie Mistakes

#182

Post by collinmanderson »

purrpit wrote: post #81

Maybe not just Newbies, but I often notice even seasoned Django developers cribbing about Django's Class Based Views (CBV). I don't really understand why to be honest. There are many blog posts that express regretting the time invested in CBV by their respective authors by pointing out all sorts of pitfalls they fell into during usage. My ex-boss hates it as well, he even banned it from usage among developers. IMHO,…

I personally don't use them, except for date-based pages. I find plain old functions the most clear, even if there's a little bit of duplication.

Re: Django Newbie Mistakes

#183

Post by collinmanderson »

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…

There's recent talk of giving Django an async option:

https://groups.google.com/d/topic/django-developers/Kw7-xV6T...

Re: Django Newbie Mistakes

#184

Post by c0un7d0wn »

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…

Definitely agreed regarding django orm. And moment you decide not to use it or cannot use it because of legacy issues you're in a world of pain. We've developed https://github.com/shosca/django-rest-witchcraft and https://github.com/shosca/django-sorcery as the project was already using django+sqlalchemy and doing everything manually and also had to touch legacy db's (think composite pk's and all kinds of db quirks..)

Re: Django Newbie Mistakes

#185

Post by mgkimsal »

ubernostrum wrote: post #169
mgkimsal wrote: post #151

Earlier quoted context omitted.

"Created on" and "last modified". I see last modified way at the bottom of a long page in light grey. I did not even notice it was a wiki until others point it out. Biggest text on the page says 'code'. I plead nav-blindness to not seeing 'wiki' in the floating navbar. Perhaps a date on every block section? Or... something that throws a big block at the top if the last edit was more than 2 years ago?

Honestly I'm not convinced it's worth the amount of work involved in doing all this, and the number of places available for people to share tips/tricks/etc. has drastically increased since 2005. So if it were up to me the wiki would either go away, or become read-only with prominent "only for historical purposes, don't use information here" warnings. But I'll think it over.

i was meaning probably more in a general sense, not so much for this particular page. the notice at the top of that specific entry does the trick. a notice at the top of all wikis which aren't intended as the 'official word' indicating such would mitigate a bit of this sort of confusion.

Re: Django Newbie Mistakes

#186

Post by dwaltrip »

douglaswlance wrote: post #41
akx wrote: post #21

Earlier quoted context omitted.

DRF is nice enough 90% of the way, but when you need to do something that its authors haven't really thought of, you need to dig in very deep to fix things, I've found. :/

If that's the case, you should take a step back and think about it from another angle to make absolutely sure that you're not attacking the problem from the wrong vector.

I have heard great things about DRF, and often it is good to resist coloring outside the lines.

That being said, your comment assumes that DRF has indeed thought of everything. All abstractions leak, some more than others. Clean escape hatches are very valuable.

Re: Django Newbie Mistakes

#187

Post by iliaznk »

nnq wrote: post #152
iliaznk wrote: post #142

Earlier quoted context omitted.

Django Rest Framework is getting close to that.

Huh?! Any moderately complex usage of DRF requires tons of boilerplate, or ton of app-specific abstractions... Also, just having to write a view, then a serializer ... to actually write it!! Imho the ideal framework would work with a models definition, json or yaml, not code, with extra anatotions for everything needed to have the logic of stuff like serializers and views instantiated from them. And keep the "custom…

Well, of course complex and specific stuff will require more boilerplate, but if you just need a basic CRUD on a model – just define a view set and you're done, URLs and methods will be created automatically.

Re: Django Newbie Mistakes

#188

Post by iliaznk »

nnq wrote: post #152
iliaznk wrote: post #142

Earlier quoted context omitted.

Django Rest Framework is getting close to that.

Huh?! Any moderately complex usage of DRF requires tons of boilerplate, or ton of app-specific abstractions... Also, just having to write a view, then a serializer ... to actually write it!! Imho the ideal framework would work with a models definition, json or yaml, not code, with extra anatotions for everything needed to have the logic of stuff like serializers and views instantiated from them. And keep the "custom…

> json or yaml, not code only to sooner or later realise that those definitions have turned into a DSL – or code, for that matter, anyway.

Re: Django Newbie Mistakes

#189

Post by jenaimarre »

jojo64 wrote: post #83
jtchang wrote: post #36

One of the things that makes me sad is there is no project even remotely close comparable to Django for say Golang or Scala. I love the fact that you get an admin interface out of the box. And tons of documentation. The views/template stuff is a bit dated since everyone started moving to frontend/backend services and SPAs but we still have DRF which is incredible in the amount you get for "free". I've had the "pleasu…

Indeed we are also looking for a framework to change our Django/python. We were looking at golang as half of our backend is in go but the lack of ORM make the choice impossibile. Gorm, xorm.. are not supporting Foreign Key... Yes you can write your raw SQL query but that means that your backend can't support MySQL and Postgresql (one of our prerequisites for on-premise deployment). So we are ending with phoenix. Very…

Why wouldn't you be able to support both MySQL and PostgreSQL without an ORM?

Re: Django Newbie Mistakes

#190

Post by jojo64 »

jenaimarre wrote: post #189
jojo64 wrote: post #83

Earlier quoted context omitted.

Indeed we are also looking for a framework to change our Django/python. We were looking at golang as half of our backend is in go but the lack of ORM make the choice impossibile. Gorm, xorm.. are not supporting Foreign Key... Yes you can write your raw SQL query but that means that your backend can't support MySQL and Postgresql (one of our prerequisites for on-premise deployment). So we are ending with phoenix. Very…

Why wouldn't you be able to support both MySQL and PostgreSQL without an ORM?

This implies to create 2 queries each time you want to hit the database. One query for PostgreSQL and one query for MySQL. This is something we can't afford. Do you have some good tips to manage this ? To be honest the ORM is required only to support multiple database.
Post reply on HN