6 ms·

You might know Python but it sounds like you don't know Django very well. Django does have built in JSON support[1]. There's also Django Rest Framework[2], whi

You might know Python but it sounds like you don't know Django very well. Django does have built in JSON support[1]. There's also Django Rest Framework[2], which while not built into the core, is well supported and hardly a burden to add. And finally, Django's "scaffolding" functionality is built around its models. You define your model as a plain Python class inheriting from Django's model class, and then the various generic[3]/"scaffolding" views work by being told what model they're for, with the ability to override and extend whatever you want to. [1]-https://docs.djangoproject.com/en/2.1/ref/request-response/#jsonresponse-objects https://docs.djangoproject.com/en/2.1/ref/request-response/#... [2]-http://www.django-rest-framework.org/ http://www.django-rest-framework.org/ [3]-https://docs.djangoproject.com/en/2.1/topics/class-based-views/generic-display/ https://docs.djangoproject.com/en/2.1/topics/class-based-vie...

0xADEADBEE 8y ago
I fear you've contrived to miss both underlying points. In order to access a JSON endpoint in Django, I need to install DRF, integrate it with Django, configure it, edit my urls.py and perhaps set up a serialiser. I won't detail the procedure in your first link because I think you very well know that is simply a response object with a crude serialiser and a content header set. The inclusion of both misses the point, which is that in Rails, I would simply navigate to /model-name.json (so in fact, yes, it is absolutely a burden to go through that when you compare the two). That's it. No parsing. No route configuration. No concerning myself with edge-cases unless I'm doing something odd. Requirement satisfied, and I can sleep soundly knowing I'm not bequeathing some custom car-crash on whoever inherits my codebase. Debate aside, I wholeheartedly encourage you to try out this framework sometime - I've found going from Django to Rails to be an absolute joy to develop with. Generic Views. Ah. Well that has its own set of problems. Why am I wading through the docs (or more accurately ccbv.co.uk because the actual docs are a verbose, time-sinking miasma; recall that in my previous comment, I am championing the development-velocity of Rails in contrast to Django) to discover which method from which class I need to override to implement the functionality I need? I can intuit a lot more now, after doing this for years, but why do I need this knowledge at all? It is the job of the framework to abstract and ameliorate bullshit. Corollary: why is it that every Django codebase I inherit has at some point converged on its natural state of 'car-crash' because of the combination of a bunch of rigid inheritance chains and my predecessors not putting in an escape hatch? At risk of being a bit of a zealot, MI is almost always an anti-pattern and I would prefer the flexibility afforded to me by composing things in the traditional fashion. In Rails, I would build a model like this in my shell: `rails g scaffold Blog title:string content:text`. That's again, literally it. From that, I now have a Blog model with title and content, created and updated fields, controllers (or 'Views' in Django parlance for some reason) and both HTML and JSON views ('Templates', in Django-land), unit tests, assets for my asset pipeline (we don't have to run collect static btw - it seamlessly transitions into production because it was designed on the basis that people might actually be deploying their projects), my equivalent of urls.py has been updated to accommodate my new model and I have full CRUD functionality at this point. Genuinely, I implore you to try this framework. Django has come a long way since I first used it but it's nowhere near the level that modern frameworks like Phoenix [1] (you should give this a go too - the third party libs aren't quite there yet but it's a really well thought-out framework) are at, and I'm genuinely curious as to why. [1] - https://phoenixframework.org/ https://phoenixframework.org/
- pythonaut_16 8y ago
  We'll have to agree to disagree about Django. I think Django and Rails both offer good developer productivity/velocity, they just make different tradeoffs. Django tends to be more explicit, which might lead to a slightly higher learning curve, but after that I've found it's easier to trace through Django applications to understand what's happening. I've seen my fair share of terrible Django and terrible Rails applications. Bad code can be written in any language and framework. Don't get me wrong, Django definitely has its pain points, but I think it offers a very competitive alternative to Rails. I definitely agree with you on Phoenix though! Elixir/Phoenix is my current stack of choice. I actually think they do a really great job of capturing the high points of both Rails and Django while also improving on the weak points of both as well. (For example, Phoenix offers a lot of the "magic" of Rails but it's all backed by explicit code that Phoenix generates while creating your project.)

0xADEADBEE 8y ago

I fear you've contrived to miss both underlying points. In order to access a JSON endpoint in Django, I need to install DRF, integrate it with Django, configure it, edit my urls.py and perhaps set up a serialiser. I won't detail the procedure in your first link because I think you very well know that is simply a response object with a crude serialiser and a content header set. The inclusion of both misses the point, which is that in Rails, I would simply navigate to /model-name.json (so in fact, yes, it is absolutely a burden to go through that when you compare the two). That's it. No parsing. No route configuration. No concerning myself with edge-cases unless I'm doing something odd. Requirement satisfied, and I can sleep soundly knowing I'm not bequeathing some custom car-crash on whoever inherits my codebase. Debate aside, I wholeheartedly encourage you to try out this framework sometime - I've found going from Django to Rails to be an absolute joy to develop with. Generic Views. Ah. Well that has its own set of problems. Why am I wading through the docs (or more accurately ccbv.co.uk because the actual docs are a verbose, time-sinking miasma; recall that in my previous comment, I am championing the development-velocity of Rails in contrast to Django) to discover which method from which class I need to override to implement the functionality I need? I can intuit a lot more now, after doing this for years, but why do I need this knowledge at all? It is the job of the framework to abstract and ameliorate bullshit. Corollary: why is it that every Django codebase I inherit has at some point converged on its natural state of 'car-crash' because of the combination of a bunch of rigid inheritance chains and my predecessors not putting in an escape hatch? At risk of being a bit of a zealot, MI is almost always an anti-pattern and I would prefer the flexibility afforded to me by composing things in the traditional fashion. In Rails, I would build a model like this in my shell: `rails g scaffold Blog title:string content:text`. That's again, literally it. From that, I now have a Blog model with title and content, created and updated fields, controllers (or 'Views' in Django parlance for some reason) and both HTML and JSON views ('Templates', in Django-land), unit tests, assets for my asset pipeline (we don't have to run collect static btw - it seamlessly transitions into production because it was designed on the basis that people might actually be deploying their projects), my equivalent of urls.py has been updated to accommodate my new model and I have full CRUD functionality at this point. Genuinely, I implore you to try this framework. Django has come a long way since I first used it but it's nowhere near the level that modern frameworks like Phoenix [1] (you should give this a go too - the third party libs aren't quite there yet but it's a really well thought-out framework) are at, and I'm genuinely curious as to why. [1] - https://phoenixframework.org/ https://phoenixframework.org/

pythonaut_16 8y ago
We'll have to agree to disagree about Django. I think Django and Rails both offer good developer productivity/velocity, they just make different tradeoffs. Django tends to be more explicit, which might lead to a slightly higher learning curve, but after that I've found it's easier to trace through Django applications to understand what's happening. I've seen my fair share of terrible Django and terrible Rails applications. Bad code can be written in any language and framework. Don't get me wrong, Django definitely has its pain points, but I think it offers a very competitive alternative to Rails. I definitely agree with you on Phoenix though! Elixir/Phoenix is my current stack of choice. I actually think they do a really great job of capturing the high points of both Rails and Django while also improving on the weak points of both as well. (For example, Phoenix offers a lot of the "magic" of Rails but it's all backed by explicit code that Phoenix generates while creating your project.)