111–120 of 141 posts
I'm learning node now for another mini project, is there anything similar? I know how it achieve certain tasks but to structure in a proper way I know nothing, all tutorials I've done never really go that deep
I think there are too many concepts in this, but rather than being negative, here are some tips: Always keep your models slim. Don't stuff template related stuff in there. You need to look at those models often, so compact is a win. course_has_finished(course) is not much longer than course.has_finished(), and will allow you to expand the functionality as time goes on. Do precomputation if you need the information in…
Fat models think controllers is the suggested strategy. It works well in my opinion / experience, though I guess it could get out of hand on very large projects.
There is something that feels very unnatural and unintuitive about your course_has_finished(course) versus course.has_finished() example. This was one of the principles behind OOP, keeping your data and functions / methods together, though I know OOP isn't trendy these days. It's far more natural to have it as a method of course than some random function, stored who knows where. I worked on a system with this type of design, it was pretty bad.
One thing I would like to see for larger projects is the ability to easily split models into separate files - a bit more like Java does with one class per file. Maybe you can do this already.
Class based views mean that a lot of code is written and tested for you. I'll agree that your view does need to be somewhat "standard" in what it's doing (anything you would see in the admin, list, create, edit, detail, login, etc), so if you have something more complex multiple forms in one view, then thy don't give a great deal of advantage. In that situation I would still likely choose a basic View class over functional views, but more for consistency.
I am probably in agreement on separate apps.
Migrations are one of the best features of Django. I have just spent 4 years working on a a system without them and it was a shambles as you would expect. Everyone is scared to make database changes, so you get a ton of shitty application code to compensate for shitty database modelling. Tech debt in other words.
I can't think of any 3rd party apps where I have used the models directly, or if I did it was frictionless enough for me not to remember. So no real opinion on that one. 3rd party apps can be pretty hit and miss, especially if they get abandoned as you upgrade Django, so I would say use with caution, particularly for more obscure ones (just been revisiting django-celery-beat, that's been around for years so I doubt it's going away).
Earlier quoted context omitted.
Always keep your models slim. Don't stuff template ...course_has_finished(course) is not much longer than course.has_finished() I disagree with this. When trouble shooting or expanding code it is super convenient to import a model and have all of your methods on auto complete. Especially when you need the same functionality in a view, a cron job, a celery task, and an DRF end point. If you want to keep it clean you c…
In my view (hehe), Django's class based views is a good idea implemented poorly. In theory you should be able to use any of the built-in class based generic views with minimal customizations to suit your needs, except when you want to do such customizations you're left dealing with a huge inheritance tree of mixins. It's all magic unless you know or wanna read the documentation on what each mixin brings to the view,…
I think there are too many concepts in this, but rather than being negative, here are some tips: Always keep your models slim. Don't stuff template related stuff in there. You need to look at those models often, so compact is a win. course_has_finished(course) is not much longer than course.has_finished(), and will allow you to expand the functionality as time goes on. Do precomputation if you need the information in…
> Always keep your models slim. At least never put your business logic in your views, forms or even templates.
I've been heavily inspired by this styleguide over the years, but I still think it's a bit too complex. A few random thoughts: - I think "services" is too much of a loaded term. I prefer "actions", and I always use the function-based style. - I hate the naming of "APIs" in this document. They use the term "API" when they mean "endpoint" or "view". - "Reuse serializers as little as possible" is the single best piece o…
> We use Celery for the following general cases: > > Communicating with 3rd party services (sending emails, notifications, etc.) > Offloading heavier computational tasks outside the HTTP cycle. > Periodic tasks (using Celery beat) Sigh. No mention of the trade-offs. There's simpler ways to do all these things. Celery is a big complex beast and it always pains me to see it as the default suggestion for simple tasks.
Earlier quoted context omitted.
You want to add an ORM to the ORM? Why?
How is that adding an ORM to the ORM? I want all django orm access to happen at defined places, instead of the spaghetti mess it is when people do SomeOtherModulesModel.objects.filter(..) and expose themselves to the internal workings of that module. Access it through a selector instead.
What you're describing takes a selector, and maps it onto an object. Is it just that you want type hints or something?
Earlier quoted context omitted.
> Always keep your models slim. As simple as possible, but no simpler. Django models are meant to deal not just with the data, but also with business logic. If `course.has_finished` is a property of the course, why would you want to have a separate function outside of the class? > Do precomputation if you need the information in a template If the precomputation is only needed in a template, you can (should, IMO) use…
> If `course.has_finished` is a property of the course, why would you want to have a separate function outside of the class? Because one should avoid passing Django models around. It leads to bad design. Have a selector or something that uses the ORM, but exposes some dataclass or pydantic model instead, and put the logic there.
For example, if you do a query like Model.objects.filter(related_model__in=RelatedModel.objects.filter(...)) the ORM will only run a single query, silently converting the second one into a JOIN.
If you pass lists of "RelatedModel" however you would've had to first one one query to get that list (raising potential edge-cases with regards to atomicity and transactional isolation) and then pass the list of IDs to the outer query in an "WHERE related_model_id IN (...)", resulting in 2 queries in the end.
Earlier quoted context omitted.
In my view (hehe), Django's class based views is a good idea implemented poorly. In theory you should be able to use any of the built-in class based generic views with minimal customizations to suit your needs, except when you want to do such customizations you're left dealing with a huge inheritance tree of mixins. It's all magic unless you know or wanna read the documentation on what each mixin brings to the view,…
Are you aware of https://ccbv.co.uk/ ? After I discovered that, class based views became easy.
I think there are too many concepts in this, but rather than being negative, here are some tips: Always keep your models slim. Don't stuff template related stuff in there. You need to look at those models often, so compact is a win. course_has_finished(course) is not much longer than course.has_finished(), and will allow you to expand the functionality as time goes on. Do precomputation if you need the information in…
_(99% kidding, but i disagree with most of this lol)_