On Sat, May 25, 2013 at 1:00 AM, Shai Berger <[email protected]> wrote:
> Hi Karol, > > On Saturday 18 May 2013 13:26:53 Karol Sikora wrote: > > Hi, > > > > We was talked with Russell on djangocon eu about integrating more rich > > support for working django as rest api provider, focused on dealing with > > one-page web applications. > Apologies, but I don't recall this specific conversation (I had a few over the DjangoCon week :-), but it sounds like either I misunderstood the intention of your question, or you misunderstood my answer. I know I advocated for the Django ecosystem to pay more attention to the ways that the web is changing (and one-page apps are part of those changes); however, I don't recall suggesting that this necessarily meant Django's *core* needed to gain a ReST framework implementation. > The motivations that currently without third party modules like > > django-rest-framework or tastypie its quite impossible to create rich web > > applications working as one-page. > Saying "It's impossible to build a 1 page app without using external apps" implies that it's difficult to install external apps, or that you should be able to build a one-page app without external dependencies. Neither of these things are true. > > As django aims to follow "batteries included" philosophy, so maybe it > will > > be a good idea to integrate support for dealing with modern web > > applications. > No - Django *doesn't* aim to follow a batteries included philosophy. We aim to include the parts that are necessary to solve the core parts of the web problem - the parts necessary to turn an RFC-compliant HTTP request into a HTTP response, and those supporting tools that are so common or difficult to implement that there is value in having an agreed common implementation. We actively encourage the development of an ecosystem of third party applications for everything else. We specifically *don't* wan't Django to become a library of *everything* you need to do stuff on the web. > My understanding of Django's philosophy is quite different; in contrast to > what > you imply, I think that the rich eco-system of 3rd-party packages, > including > mini-frameworks, is one Django's important strengths. > > In other words, I don't see the requirement to use a third-party module as > a > problem in itself. If this requirement causes you some other problems, > please > explain what they are. > > Other than that, I read your suggestion as "let's make a new REST-API mini- > framework, but make it in core". That's not the way Django has done such > things in the past -- usually, a third-party package that gained wide > acceptance, to the point that it was a de-facto standard, is then accepted > into core. A classic example for this is staticfiles. True for static files, but not universally true. contrib.messages, for example, was born out of an attempt to merge the best parts out of half a dozen user-messages frameworks that were in use at the time. If it appears that the ecosystem is developing a large range of substantially similar approaches to the same problem, there's an argument to be made to solve the problem once and for all, and get it in core. However, from my knowledge of TastyPie and ReST Framework, that isn't what has happened. I'm not convinced that the differences are purely cosmetic -- there are a couple of significant architectural differences. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
