Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-03-31 Thread Nathan Gaberel
Hi everyone,

I've been working on this for a while too (for React & Webpack
specifically) and will be sharing my current setup at DjangoCon Europe
next week.
For those of you attending, please come and talk to me, I'd love to
get your feedback and maybe we can exchange ideas. :)

Best,
Nathan

On Thu, 28 Mar 2019 at 01:11, Maciek Olko  wrote:
>
> Thank you all for all your responses!
>
> It's been a long time (sorry!), but:
> * I've added a Django ticket considering topic discussed here. [1]
> (* I updated a bit AJAX Django wiki page. [2])
>
> Aymeric, in terms of copyright ownership, would you agree on rephrasing 
> fragments of your articles to put it into Django docs?
>
> Regards,
> Maciej
>
> [1] https://code.djangoproject.com/ticket/30296
> [2] https://code.djangoproject.com/wiki/AJAX
>
> śr., 27 lut 2019 o 15:37 użytkownik Jamesie Pic  napisał:
>>
>> FTR I published my own writeup here:
>> https://blog.yourlabs.org/post/183077442308/django-js-research-report
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAC6Op184WMaf09CD1NqznfCQv%2BqhcMePB8nUdTKpTns1Fejc0A%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-developers/KVAZkRCq9KU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CALYYG80eYMHMqis10UpxsehTdQRObxKP5c7c%2Bfr9TF6fLdxTwA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAO052S3JR3u5-_fW1t0yvycgv%3DSnH9ydp0XhR%3D5906zjng_aXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-03-27 Thread Maciek Olko
Thank you all for all your responses!

It's been a long time (sorry!), but:
* I've added a Django ticket considering topic discussed here. [1]
(* I updated a bit AJAX Django wiki page. [2])

Aymeric, in terms of copyright ownership, would you agree on rephrasing
fragments of your articles to put it into Django docs?

Regards,
Maciej

[1] https://code.djangoproject.com/ticket/30296
[2] https://code.djangoproject.com/wiki/AJAX

śr., 27 lut 2019 o 15:37 użytkownik Jamesie Pic  napisał:

> FTR I published my own writeup here:
> https://blog.yourlabs.org/post/183077442308/django-js-research-report
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAC6Op184WMaf09CD1NqznfCQv%2BqhcMePB8nUdTKpTns1Fejc0A%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALYYG80eYMHMqis10UpxsehTdQRObxKP5c7c%2Bfr9TF6fLdxTwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-27 Thread Jamesie Pic
FTR I published my own writeup here:
https://blog.yourlabs.org/post/183077442308/django-js-research-report

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op184WMaf09CD1NqznfCQv%2BqhcMePB8nUdTKpTns1Fejc0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-25 Thread Jamesie Pic
On Mon, Feb 25, 2019 at 10:39 PM Jamesie Pic  wrote:
> component = dict(
> template_name='django/forms/widgets/textarea.html',
> script='your/textarea.js',
> style='your/style.css'
> )

Actually do NOT try this, for static i think the more efficient
refactor would be to enable widgets and things to touch
request.static.scripts and request.static.styles, so that scripts that
you load in your parent template would not be re-added by the widgets.
At the same time, programing perimeter for widget statics would
increase since this would no more reduce it to a declarative
structure.

And maybe you want to try to change from templates to python rendering
functions, if not for transpiling or performance, performance, maybe
just for easier reuse across python code in general. But then you
would use a python library that

FTR GDAPS is also having research on this as we speak :
https://gitlab.com/nerdocs/gdaps/issues/2

Have fun

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18G0897i333BgRmcOur5bGGceuAy7ak6XN%3DZ2rmOuW7MQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-25 Thread Jamesie Pic
Also in Django maybe try to change things like:

class Textarea(Widget):
template_name = 'django/forms/widgets/textarea.html'

With

component = dict(
template_name='django/forms/widgets/textarea.html',
script='your/textarea.js',
style='your/style.css'
)

Or something component='your.favorite.TextArea', then you could also hack
django.forms.widgets.component to change the default rendering at the
project level. Maybe then distribute more exciting component objects that
accepts this dict interface in pip packages that could work with any python
framework.

Anyway, keep on pursuing your dream stack, always happy to read some
exciting discussions on this matter ;)

Have a great day

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op191PpSz_EZT8H-zSz5cgePAD-j%3DBHQQfCvT0KTgVyJQrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-11 Thread Jani Tiainen
Hi,

As we are heavy ExtJS and DojoToolkit users we've encountered quite a much
problems since both frameworks do have their own toolchain and it doesn't
seem to fit to webpack or rollup or anything like that.

So if such a feature is planned for core I really hope that non mainstream
tools are left out, at least without possibility to make them work easily.


On Mon, Feb 11, 2019 at 12:50 AM Josh Smeaton 
wrote:

> For the vast majority of users, right now, Vue or React are the only real
> options. Let's not try predicting the future, and just focus on what the
> trends currently are. Users going for newer targets are likely more
> advanced, and can figure out the necessary changes.
>
> Aymerics articles are fantastic, and our team has gotten a lot of value
> out of them for our newer projects. Especially the customisations to static
> files which removes the re-hashing of static content. I would be very keen
> for Django to provide a first class integration method with Webpack, in
> particular, but most popular bundler frameworks if the necessary interfaces
> exist.
>
> - "Importing" static content that has already been bundled and hashed
> - Automatic reloading of static content as it is being changed
> - Visual debugging in editors
>
> I think the idea of a how-to that considers authentication and
> communication between frontend and backend is also what we need.
>
> So while I don't think Django needs to bless a particular frontend
> framework, I think we have to provide a really nice integration story so
> that the most popular JS frameworks do not have to jump through a lot of
> hoops, including copy and pasting large sections of code, to get their
> existing tooling working with Django. I no longer think it's enough to
> require 3rd party django libraries to make the frontend integration
> possible.
>
> On Sunday, 10 February 2019 04:50:54 UTC+11, Dmitriy Sintsov wrote:
>>
>> Very nice tuturials! Although there is web components standard gradually
>> being adapted by major browsers, which should bring custom tags /
>> components not having to use the third party Javascript libraries like Vue
>> or React. So, while in Python world the leadership of Django is quite
>> stable and obvious one, in Javascript world it's not so easy to say whether
>> Vue and React would dominate in a long run. Maybe Marko or Stencil.js are
>> closer to the future vision of Javascript.
>>
>> On Sat, Feb 9, 2019 at 8:32 PM Aymeric Augustin <
>> aymeric@polytechnique.org> wrote:
>>
>>> Hello,
>>>
>>> I wrote a three-part essay on this question last year:
>>> 1.
>>> https://fractalideas.com/blog/making-react-and-django-play-well-together/
>>> 2.
>>> https://fractalideas.com/blog/making-react-and-django-play-well-together-hybrid-app-model/
>>> 3.
>>> https://fractalideas.com/blog/making-react-and-django-play-well-together-single-page-app-model/
>>>
>>> Even though I took a narrower view — I only considered React — I found
>>> enough decisions factors to write over 2000 words in the first post, which
>>> is too long for a FAQ :-)
>>>
>>> On one hand, I'm not sure the Django docs should go into this level of
>>> detail and provide specific information about a particular JS framework. On
>>> the other hand, it's rather useless to talk about integrating Django with a
>>> JS frontend without discussing authentication and it's hard to discuss
>>> authentication in less than 2000 words — which were just for justifying my
>>> favorite solution, not for investigating every option!
>>>
>>> I think we need a how-to guide rather than a FAQ entry. I would find it
>>> nice:
>>>
>>> *A. To describe the Singe Page App model — where Django only serves the
>>> API*
>>>
>>> We need to explain CORS and CSRF in the clearest terms possible. Many
>>> devs end up shotgun-debugging CORS or CSRF errors, which always results in
>>> insecure deployments.
>>>
>>> My consulting experience suggests that we have a problem there: I never
>>> did an audit where the client got that right, even though they're all smart
>>> people trying to get things right.
>>>
>>> Perhaps a condensed version of my third post could do the job?
>>>
>>> Some may disagree with my recommendation against JWT, which may too
>>> opinionated for the Django docs. Again, in my experience, people tend to
>>> get security more wrong with JWT, which is why I prefer discouraging it and
>>> letting those who know what they're doing ignore my advice.
>>>
>>> *B. To say something about integrating a modern JS framework with
>>> django.contrib.staticfiles *
>>>
>>> It's perfectly doable and provides all the benefits of
>>> django.contrib.staticfiles. However, it requires a bit of duct tape, as
>>> shown in my second post.
>>>
>>> I'm a huge fan of this technique for simple website but I'm afraid I'm
>>> biased by my experience with Django. This is unlikely to be a popular
>>> option for those who are more familiar with a modern frontend framework
>>> than with django.contrib.staticfiles.
>>>

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-10 Thread Josh Smeaton
For the vast majority of users, right now, Vue or React are the only real 
options. Let's not try predicting the future, and just focus on what the 
trends currently are. Users going for newer targets are likely more 
advanced, and can figure out the necessary changes.

Aymerics articles are fantastic, and our team has gotten a lot of value out 
of them for our newer projects. Especially the customisations to static 
files which removes the re-hashing of static content. I would be very keen 
for Django to provide a first class integration method with Webpack, in 
particular, but most popular bundler frameworks if the necessary interfaces 
exist.

- "Importing" static content that has already been bundled and hashed
- Automatic reloading of static content as it is being changed
- Visual debugging in editors

I think the idea of a how-to that considers authentication and 
communication between frontend and backend is also what we need.

So while I don't think Django needs to bless a particular frontend 
framework, I think we have to provide a really nice integration story so 
that the most popular JS frameworks do not have to jump through a lot of 
hoops, including copy and pasting large sections of code, to get their 
existing tooling working with Django. I no longer think it's enough to 
require 3rd party django libraries to make the frontend integration 
possible.

On Sunday, 10 February 2019 04:50:54 UTC+11, Dmitriy Sintsov wrote:
>
> Very nice tuturials! Although there is web components standard gradually 
> being adapted by major browsers, which should bring custom tags / 
> components not having to use the third party Javascript libraries like Vue 
> or React. So, while in Python world the leadership of Django is quite 
> stable and obvious one, in Javascript world it's not so easy to say whether 
> Vue and React would dominate in a long run. Maybe Marko or Stencil.js are 
> closer to the future vision of Javascript.
>
> On Sat, Feb 9, 2019 at 8:32 PM Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> Hello,
>>
>> I wrote a three-part essay on this question last year:
>> 1. 
>> https://fractalideas.com/blog/making-react-and-django-play-well-together/
>> 2. 
>> https://fractalideas.com/blog/making-react-and-django-play-well-together-hybrid-app-model/
>> 3. 
>> https://fractalideas.com/blog/making-react-and-django-play-well-together-single-page-app-model/
>>
>> Even though I took a narrower view — I only considered React — I found 
>> enough decisions factors to write over 2000 words in the first post, which 
>> is too long for a FAQ :-)
>>
>> On one hand, I'm not sure the Django docs should go into this level of 
>> detail and provide specific information about a particular JS framework. On 
>> the other hand, it's rather useless to talk about integrating Django with a 
>> JS frontend without discussing authentication and it's hard to discuss 
>> authentication in less than 2000 words — which were just for justifying my 
>> favorite solution, not for investigating every option!
>>
>> I think we need a how-to guide rather than a FAQ entry. I would find it 
>> nice:
>>
>> *A. To describe the Singe Page App model — where Django only serves the 
>> API*
>>
>> We need to explain CORS and CSRF in the clearest terms possible. Many 
>> devs end up shotgun-debugging CORS or CSRF errors, which always results in 
>> insecure deployments.
>>
>> My consulting experience suggests that we have a problem there: I never 
>> did an audit where the client got that right, even though they're all smart 
>> people trying to get things right.
>>
>> Perhaps a condensed version of my third post could do the job?
>>
>> Some may disagree with my recommendation against JWT, which may too 
>> opinionated for the Django docs. Again, in my experience, people tend to 
>> get security more wrong with JWT, which is why I prefer discouraging it and 
>> letting those who know what they're doing ignore my advice.
>>
>> *B. To say something about integrating a modern JS framework with 
>> django.contrib.staticfiles *
>>
>> It's perfectly doable and provides all the benefits of 
>> django.contrib.staticfiles. However, it requires a bit of duct tape, as 
>> shown in my second post.
>>
>> I'm a huge fan of this technique for simple website but I'm afraid I'm 
>> biased by my experience with Django. This is unlikely to be a popular 
>> option for those who are more familiar with a modern frontend framework 
>> than with django.contrib.staticfiles.
>>
>> The docs should at least give the general idea of "compile your frontend 
>> to somewhere Django can find the files, then run collectstatic".
>>
>> If someone starts writing documentation about this, I'm interested in 
>> reviewing it.
>>
>> Best regards,
>>
>> -- 
>> Aymeric.
>>
>>
>>
>> On 5 Feb 2019, at 11:17, Carlton Gibson > > wrote:
>>
>> I think this topic is very interesting. 
>>
>> Two sides of it: 
>>
>> * Static files handling
>> * APIs
>>
>> Curtis is right, there are 

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-09 Thread Dmitriy Sintsov
Very nice tuturials! Although there is web components standard gradually
being adapted by major browsers, which should bring custom tags /
components not having to use the third party Javascript libraries like Vue
or React. So, while in Python world the leadership of Django is quite
stable and obvious one, in Javascript world it's not so easy to say whether
Vue and React would dominate in a long run. Maybe Marko or Stencil.js are
closer to the future vision of Javascript.

On Sat, Feb 9, 2019 at 8:32 PM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> I wrote a three-part essay on this question last year:
> 1.
> https://fractalideas.com/blog/making-react-and-django-play-well-together/
> 2.
> https://fractalideas.com/blog/making-react-and-django-play-well-together-hybrid-app-model/
> 3.
> https://fractalideas.com/blog/making-react-and-django-play-well-together-single-page-app-model/
>
> Even though I took a narrower view — I only considered React — I found
> enough decisions factors to write over 2000 words in the first post, which
> is too long for a FAQ :-)
>
> On one hand, I'm not sure the Django docs should go into this level of
> detail and provide specific information about a particular JS framework. On
> the other hand, it's rather useless to talk about integrating Django with a
> JS frontend without discussing authentication and it's hard to discuss
> authentication in less than 2000 words — which were just for justifying my
> favorite solution, not for investigating every option!
>
> I think we need a how-to guide rather than a FAQ entry. I would find it
> nice:
>
> *A. To describe the Singe Page App model — where Django only serves the
> API*
>
> We need to explain CORS and CSRF in the clearest terms possible. Many devs
> end up shotgun-debugging CORS or CSRF errors, which always results in
> insecure deployments.
>
> My consulting experience suggests that we have a problem there: I never
> did an audit where the client got that right, even though they're all smart
> people trying to get things right.
>
> Perhaps a condensed version of my third post could do the job?
>
> Some may disagree with my recommendation against JWT, which may too
> opinionated for the Django docs. Again, in my experience, people tend to
> get security more wrong with JWT, which is why I prefer discouraging it and
> letting those who know what they're doing ignore my advice.
>
> *B. To say something about integrating a modern JS framework with
> django.contrib.staticfiles *
>
> It's perfectly doable and provides all the benefits of
> django.contrib.staticfiles. However, it requires a bit of duct tape, as
> shown in my second post.
>
> I'm a huge fan of this technique for simple website but I'm afraid I'm
> biased by my experience with Django. This is unlikely to be a popular
> option for those who are more familiar with a modern frontend framework
> than with django.contrib.staticfiles.
>
> The docs should at least give the general idea of "compile your frontend
> to somewhere Django can find the files, then run collectstatic".
>
> If someone starts writing documentation about this, I'm interested in
> reviewing it.
>
> Best regards,
>
> --
> Aymeric.
>
>
>
> On 5 Feb 2019, at 11:17, Carlton Gibson  wrote:
>
> I think this topic is very interesting.
>
> Two sides of it:
>
> * Static files handling
> * APIs
>
> Curtis is right, there are other options but, Django REST Framework is
> (whilst not perfect) pretty solid on the API front. I think Django has a
> good story here.
> It's pretty hard not to find DRF if you follow any guide, or any searching
> at all.
>
> The static files story is a little different. It seems to me we don't tell
> the best story there.
>
> Rails has two things which we could be envious of, even if we didn't want
> to copy exactly:
>
> * The frontend framework integration that's already been mentioned.
> * The very easy "Ajax your form", with controllers (i.e. for us "generic
> views") automatically handling ajax form submissions.
>
> Both these features get users further quicker in these aspects than we are
> able to offer.
>
> We struggle to think of areas for improvements (re GSoC for example) but
> maybe here is an area.
>
> This ties into Claude's proposal here:
> https://groups.google.com/d/topic/django-developers/KYmNnvwXDUI/discussion
>
> My own story is, I've had lots of success with, and still use, Django
> Compressor.
>
>- At it's simplest you just map a content type to a shell command to
>run and then include your Sass/Less/React/Elm/whatever files in your HTML
>(with script or link tags, almost in the old-school way).
>- In development these are processed (& cached) per request.
>- For deployment you just run an offline compression task (management
>command) and then upload the files.
>- That's it.
>
> It's not a coverall approach — a frontend engineer will come along and
> totally replace Compressor with whatever is this week's Top 

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-09 Thread Aymeric Augustin
Hello,

I wrote a three-part essay on this question last year:
1. https://fractalideas.com/blog/making-react-and-django-play-well-together/
2. 
https://fractalideas.com/blog/making-react-and-django-play-well-together-hybrid-app-model/
3. 
https://fractalideas.com/blog/making-react-and-django-play-well-together-single-page-app-model/

Even though I took a narrower view — I only considered React — I found enough 
decisions factors to write over 2000 words in the first post, which is too long 
for a FAQ :-)

On one hand, I'm not sure the Django docs should go into this level of detail 
and provide specific information about a particular JS framework. On the other 
hand, it's rather useless to talk about integrating Django with a JS frontend 
without discussing authentication and it's hard to discuss authentication in 
less than 2000 words — which were just for justifying my favorite solution, not 
for investigating every option!

I think we need a how-to guide rather than a FAQ entry. I would find it nice:

A. To describe the Singe Page App model — where Django only serves the API

We need to explain CORS and CSRF in the clearest terms possible. Many devs end 
up shotgun-debugging CORS or CSRF errors, which always results in insecure 
deployments.

My consulting experience suggests that we have a problem there: I never did an 
audit where the client got that right, even though they're all smart people 
trying to get things right.

Perhaps a condensed version of my third post could do the job?

Some may disagree with my recommendation against JWT, which may too opinionated 
for the Django docs. Again, in my experience, people tend to get security more 
wrong with JWT, which is why I prefer discouraging it and letting those who 
know what they're doing ignore my advice.

B. To say something about integrating a modern JS framework with 
django.contrib.staticfiles 

It's perfectly doable and provides all the benefits of 
django.contrib.staticfiles. However, it requires a bit of duct tape, as shown 
in my second post.

I'm a huge fan of this technique for simple website but I'm afraid I'm biased 
by my experience with Django. This is unlikely to be a popular option for those 
who are more familiar with a modern frontend framework than with 
django.contrib.staticfiles.

The docs should at least give the general idea of "compile your frontend to 
somewhere Django can find the files, then run collectstatic".

If someone starts writing documentation about this, I'm interested in reviewing 
it.

Best regards,

-- 
Aymeric.



> On 5 Feb 2019, at 11:17, Carlton Gibson  wrote:
> 
> I think this topic is very interesting. 
> 
> Two sides of it: 
> 
> * Static files handling
> * APIs
> 
> Curtis is right, there are other options but, Django REST Framework is 
> (whilst not perfect) pretty solid on the API front. I think Django has a good 
> story here. 
> It's pretty hard not to find DRF if you follow any guide, or any searching at 
> all. 
> 
> The static files story is a little different. It seems to me we don't tell 
> the best story there. 
> 
> Rails has two things which we could be envious of, even if we didn't want to 
> copy exactly:
> 
> * The frontend framework integration that's already been mentioned. 
> * The very easy "Ajax your form", with controllers (i.e. for us "generic 
> views") automatically handling ajax form submissions. 
> 
> Both these features get users further quicker in these aspects than we are 
> able to offer. 
> 
> We struggle to think of areas for improvements (re GSoC for example) but 
> maybe here is an area. 
> 
> This ties into Claude's proposal here: 
> https://groups.google.com/d/topic/django-developers/KYmNnvwXDUI/discussion
> 
> My own story is, I've had lots of success with, and still use, Django 
> Compressor.  
> At it's simplest you just map a content type to a shell command to run and 
> then include your Sass/Less/React/Elm/whatever files in your HTML (with 
> script or link tags, almost in the old-school way). 
> In development these are processed (& cached) per request. 
> For deployment you just run an offline compression task (management command) 
> and then upload the files. 
> That's it. 
> It's not a coverall approach — a frontend engineer will come along and 
> totally replace Compressor with whatever is this week's Top Javascript Build 
> System™ BUT it is a good 80:20: it lets me do something (that approximates) 
> respectable, without knowing hardly anything about the latest frontend 
> hotness. (GNU Make FTW! ) 
> 
> I think if we were to offer something out-of-the-box that got as far as 
> Compressor, or further, we'd:
> satisfy most of our users, 
> allow yet more to get off the mark quickly, 
> and... well... those that need the full frontend toolchain would still be 
> free to use it. 
> I worry we'd never get anything like this into core... but I think it would 
> be good. (As I say, I think it's one area where we are lacking/behind the 
> competition.)
> 
> 

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-07 Thread Jamesie Pic
Well, there's also Graphene. It's at least REST or GraphQL.

Le mar. 5 févr. 2019 à 03:09, Cristiano Coelho  a
écrit :

> Pointing to Django Rest Framework should be more than enough. Anyone
> starting a project with Django and a SPA/JS architecture, will pretty much
> end up with DRF. Correct me if I'm wrong.
>
>
> El lunes, 4 de febrero de 2019, 19:52:42 (UTC-5), Maciek Olko escribió:
>>
>> I didn't find this topic being discussed before.
>>
>> It seems to me to be good idea to place "How do I get Django and my JS
>> framework to work together?" or similar question and answer to it in FAQ in
>> Django's docs.
>>
>> Having very big popularity of JS frameworks now it is indeed very common
>> question being asked or searched on the Internet. Such question for ReactJS
>> has 65k views on StackOverflow [1].
>>
>> The answer could briefly explain that one can make use of Django backend
>> and produce API to be consumed by JS clients. Probably it would be good to
>> link to Django REST API project as a suggestion for big projects.
>>
>> What do you think about such addition to FAQ?
>>
>> Regards,
>> Maciej
>>
>> [1]
>> https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/87fb9a35-b274-4d62-b17c-602114719ad5%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_WxEiVOML8za6UfYWyFintJx60TqvPsF-d7SNzeTYm%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-06 Thread Dan Davis
The problem with ModelForm is translating validation to something
front-end, like jquery Validator.   Here, DRF does better, because swagger
spec includes something like jsonschema (neither are a standard as I used
to know them, in the WSDL/SOAP days), and so you can use jsonschema
validation to validate on the front-end.   I think what is needed is some
way to map validate-only to the back-end, and do a sort of 2-phase commit -
validate before the user presses OK, and then save (PATCH) when the user
presses save/apply/OK.


On Wed, Feb 6, 2019 at 10:03 AM Dmitriy Sintsov 
wrote:

> Speaking of Rails AJAX forms. It's quite trivial to submit Django
> ModelForm in Javascript AJAX request. It's a bit harder to have the
> customizable success action and to display the field validation errors via
> AJAX response.
>
> I implemented AJAX viewmodels for that:
>
>
> https://django-jinja-knockout.readthedocs.io/en/latest/viewmodels.html#ajax-actions
>
> However it's the mixed traditional forms + AJAX approach, not the pure
> SPA. In pure SPA Django becomes the "data supplier" where most of the
> templates, forms, presentation is performed by Javascript framework.
>
> So, the question is, whether the features of Django such as inline
> formsets and custom widgets are required, or should Django become the data
> store only.
>
> On Tuesday, February 5, 2019 at 3:52:42 AM UTC+3, Maciek Olko wrote:
>>
>> I didn't find this topic being discussed before.
>>
>> It seems to me to be good idea to place "How do I get Django and my JS
>> framework to work together?" or similar question and answer to it in FAQ in
>> Django's docs.
>>
>> Having very big popularity of JS frameworks now it is indeed very common
>> question being asked or searched on the Internet. Such question for ReactJS
>> has 65k views on StackOverflow [1].
>>
>> The answer could briefly explain that one can make use of Django backend
>> and produce API to be consumed by JS clients. Probably it would be good to
>> link to Django REST API project as a suggestion for big projects.
>>
>> What do you think about such addition to FAQ?
>>
>> Regards,
>> Maciej
>>
>> [1]
>> https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0cafc96d-bc4f-4316-9022-28e5134a1bcd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFzonYZvqTVigfjohY6GUqJicuJeOH4pzwd32KAsR4XmnHt9hA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-06 Thread Dmitriy Sintsov
Speaking of Rails AJAX forms. It's quite trivial to submit Django ModelForm 
in Javascript AJAX request. It's a bit harder to have the customizable 
success action and to display the field validation errors via AJAX response.

I implemented AJAX viewmodels for that:

https://django-jinja-knockout.readthedocs.io/en/latest/viewmodels.html#ajax-actions

However it's the mixed traditional forms + AJAX approach, not the pure SPA. 
In pure SPA Django becomes the "data supplier" where most of the templates, 
forms, presentation is performed by Javascript framework.

So, the question is, whether the features of Django such as inline formsets 
and custom widgets are required, or should Django become the data store 
only.

On Tuesday, February 5, 2019 at 3:52:42 AM UTC+3, Maciek Olko wrote:
>
> I didn't find this topic being discussed before.
>
> It seems to me to be good idea to place "How do I get Django and my JS 
> framework to work together?" or similar question and answer to it in FAQ in 
> Django's docs.
>
> Having very big popularity of JS frameworks now it is indeed very common 
> question being asked or searched on the Internet. Such question for ReactJS 
> has 65k views on StackOverflow [1]. 
>
> The answer could briefly explain that one can make use of Django backend 
> and produce API to be consumed by JS clients. Probably it would be good to 
> link to Django REST API project as a suggestion for big projects.
>
> What do you think about such addition to FAQ?
>
> Regards,
> Maciej
>
> [1] 
> https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0cafc96d-bc4f-4316-9022-28e5134a1bcd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-05 Thread Jamesie Pic
Throwing in some food for thought that may be worth mentioning and that we
like to play with:

- django-webpack-loader merged code chunking recently
- transcrypt allows coding ie with react in Python, transcrypt also
supports webpack
- chp is a project that aims to replace templates as we know them by
functions, it's a minimal port of react, it relies on transcrypt for
isomorphic support

>From my pov it seems webpack is establishing as a standard worth
supporting, but code chunking is really nice to have for a better loading
experience.

In pure Django we used to chunk by extending a script block in non-base
templates.

Le mar. 5 févr. 2019 à 11:17, Carlton Gibson  a
écrit :

> I think this topic is very interesting.
>
> Two sides of it:
>
> * Static files handling
> * APIs
>
> Curtis is right, there are other options but, Django REST Framework is
> (whilst not perfect) pretty solid on the API front. I think Django has a
> good story here.
> It's pretty hard not to find DRF if you follow any guide, or any searching
> at all.
>
> The static files story is a little different. It seems to me we don't tell
> the best story there.
>
> Rails has two things which we could be envious of, even if we didn't want
> to copy exactly:
>
> * The frontend framework integration that's already been mentioned.
> * The very easy "Ajax your form", with controllers (i.e. for us "generic
> views") automatically handling ajax form submissions.
>
> Both these features get users further quicker in these aspects than we are
> able to offer.
>
> We struggle to think of areas for improvements (re GSoC for example) but
> maybe here is an area.
>
> This ties into Claude's proposal here:
> https://groups.google.com/d/topic/django-developers/KYmNnvwXDUI/discussion
>
> My own story is, I've had lots of success with, and still use, Django
> Compressor.
>
>- At it's simplest you just map a content type to a shell command to
>run and then include your Sass/Less/React/Elm/whatever files in your HTML
>(with script or link tags, almost in the old-school way).
>- In development these are processed (& cached) per request.
>- For deployment you just run an offline compression task (management
>command) and then upload the files.
>- That's it.
>
> It's not a coverall approach — a frontend engineer will come along and
> totally replace Compressor with whatever is this week's Top Javascript
> Build System™ BUT it is a good 80:20: it lets me do something (that
> approximates) respectable, without knowing hardly anything about the latest
> frontend hotness. (GNU Make FTW! )
>
> I think if we were to offer something out-of-the-box that got as far as
> Compressor, or further, we'd:
>
>- satisfy most of our users,
>- allow yet more to get off the mark quickly,
>- and... well... those that need the full frontend toolchain would
>still be free to use it.
>
> I worry we'd never get anything like this into core... but I think it
> would be good. (As I say, I think it's one area where we are lacking/behind
> the competition.)
>
> Kind Regards,
>
> Carlton
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/49deee81-0230-48a0-8c2a-b12eb0956810%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_zPHFamYefkLPkYiRTnXjAbrX9wLa9XkQmYv5foNJKYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-05 Thread Carlton Gibson
I think this topic is very interesting. 

Two sides of it: 

* Static files handling
* APIs

Curtis is right, there are other options but, Django REST Framework is 
(whilst not perfect) pretty solid on the API front. I think Django has a 
good story here. 
It's pretty hard not to find DRF if you follow any guide, or any searching 
at all. 

The static files story is a little different. It seems to me we don't tell 
the best story there. 

Rails has two things which we could be envious of, even if we didn't want 
to copy exactly:

* The frontend framework integration that's already been mentioned. 
* The very easy "Ajax your form", with controllers (i.e. for us "generic 
views") automatically handling ajax form submissions. 

Both these features get users further quicker in these aspects than we are 
able to offer. 

We struggle to think of areas for improvements (re GSoC for example) but 
maybe here is an area. 

This ties into Claude's proposal here: 
https://groups.google.com/d/topic/django-developers/KYmNnvwXDUI/discussion

My own story is, I've had lots of success with, and still use, Django 
Compressor.  

   - At it's simplest you just map a content type to a shell command to run 
   and then include your Sass/Less/React/Elm/whatever files in your HTML (with 
   script or link tags, almost in the old-school way). 
   - In development these are processed (& cached) per request. 
   - For deployment you just run an offline compression task (management 
   command) and then upload the files. 
   - That's it. 

It's not a coverall approach — a frontend engineer will come along and 
totally replace Compressor with whatever is this week's Top Javascript 
Build System™ BUT it is a good 80:20: it lets me do something (that 
approximates) respectable, without knowing hardly anything about the latest 
frontend hotness. (GNU Make FTW! ) 

I think if we were to offer something out-of-the-box that got as far as 
Compressor, or further, we'd:

   - satisfy most of our users, 
   - allow yet more to get off the mark quickly, 
   - and... well... those that need the full frontend toolchain would still 
   be free to use it. 
   
I worry we'd never get anything like this into core... but I think it would 
be good. (As I say, I think it's one area where we are lacking/behind the 
competition.)

Kind Regards,

Carlton

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/49deee81-0230-48a0-8c2a-b12eb0956810%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread ludovic coues
My current job is working on the django backend of a SPA/JS. Truth is, our
django does not serve any JS file. The whole SPA is a bunch of static
files, served by nginx. Every and only request with a path starting with
/api are routed to Django.

On Tue, Feb 5, 2019, 04:16 Curtis Maloney  On 2/5/19 1:09 PM, Cristiano Coelho wrote:
> > Pointing to Django Rest Framework should be more than enough. Anyone
> > starting a project with Django and a SPA/JS architecture, will pretty
> > much end up with DRF. Correct me if I'm wrong.
>
> It's likely they'd end up with DRF, however there are alternatives.
>
> However, by explicitly listing DRF, it might give the impression it's
> the "blessed" solution by Django...
>
> --
> Curtis
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/77e1f7b8-d5c7-31a9-4e8d-55fc094cc968%40tinbrain.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEuG%2BTbJU51NE0n2u%3DopdisOANM%3Dp%3Dn-h%3DvdABdzrzUj7F4a7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Curtis Maloney

On 2/5/19 1:09 PM, Cristiano Coelho wrote:
Pointing to Django Rest Framework should be more than enough. Anyone 
starting a project with Django and a SPA/JS architecture, will pretty 
much end up with DRF. Correct me if I'm wrong.


It's likely they'd end up with DRF, however there are alternatives.

However, by explicitly listing DRF, it might give the impression it's 
the "blessed" solution by Django...


--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/77e1f7b8-d5c7-31a9-4e8d-55fc094cc968%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Dan Davis
I kind of disagree that saying it works with DRF is enough.  One issue that
needs to be addressed is matching any possible path with re_path, so that
an SPA that takes over the browser history API will work with bookmarks.

Django is opinionated.  The winning strategy for npm frameworks is to let
the CSS/JS/assets come from the framework.  While many projects have used
django-pipeline or django-compressor to good effect, if you use
webpack+react or angular cli, then the output can be a couple of pre-cache
busted bundles, and the solution is:
   (a) tell the javascript framework to put its output files in a
particular directory,
   (b) tell Django to look there with STATICFILES_DIRS,
   (c) Write something to generate tags for the static assets, either a
templatetag or a staticfiles finder/storage.

I think it would be good to include with Django some template tags that can
find a cache-busting bundle by the bundle name, maybe using a manifest
generated during create static.   My code isn't great, but it works like
this:

from django.templatetags.static import static
from ng_loader.utils import BundleMap


logger = logging.getLogger(__name__)

if not settings.DEBUG:
_map = BundleMap(settings.STATIC_ROOT)

register = template.Library()


@register.simple_tag
def ng_load_cssbundle(name):
if settings.DEBUG:
fname = '{}.bundle.css'.format(name)
else:
fname = _map.get_bundle('css', name)
logger.debug('Serving css bundle {} from {}'.format(name, fname))
return mark_safe(''.format(static(fname)))


@register.simple_tag
def ng_load_jsbundle(name):
if settings.DEBUG:
fname = '{}.bundle.js'.format(name)
else:
fname = _map.get_bundle('js', name)
logger.debug('Serving js bundle {} from {}'.format(name, fname))
return mark_safe(''.format(static(fname)))

With the bundle map being created like this:

import os
import re


class BundleMap(object):

def __init__(self, rootpath):
self.rootpath = rootpath
self.rebuild()

def rebuild(self):
self.map = { 'css': {}, 'js': {} }
for name in os.listdir(self.rootpath):
m = re.match(r'([a-z]+)\.[a-z0-9]+\.bundle.(js|css)', name)
if m is not None:
bname = m.group(1)
btype = m.group(2)
if btype in self.map:
self.map[btype][bname] = name

def get_bundle(self, btype, name):
return self.map[btype][name] if name in self.map[btype] else None



On Mon, Feb 4, 2019 at 9:31 PM Jason Johns  wrote:

> Tom Christie wrote this about what DRF brings to the table over plain
> Django:
>
> Django REST framework isn't required, but it helps you get a lot of things
> right that will be time consuming and error prone if you're working from
> core Django.
>  • Serializers
> The Django serializers are not really suitable for anything other than
> dumping and loading fixture data - they don't allow you to customize the
> representation in any substantial way.
> Using Django Forms for validation isn't suitable either as they're
> intended for HTML only validation and can't eg handle nested validation.
> REST frameworks serializers are designed for API usage and cover both JSON
> or form validation, as well as being able to represent as either HTML Forms
> or formats such as JSON. They also give you lots of scope for handling the
> representation of relationships, such as using hyperlinked relations.
>  • Authentication and permissions
> REST framework's authentication will gracefully handle both session based
> and token based schemes at the same time, and get the CSRF behavior right.
> You'll find that really awkward to do if using plain Django. It also helps
> ensure you're issuing failure responses that are suitable for API clients
> (eg get 401 vs 403 responses right)
> The auth, permissions and throttling are also more flexible because
> they're defined at a view level, rather than as middleware or a view
> decorator. This makes it easier to eg combine multiple schemes, or to apply
> different schemes to different parts of your application.
>  • Views
> Django's generic class based views are suitable to HTML applications. REST
> framework's generic class based views are suitable for API services.
> Typicallly API views have slightly different behavior by convention. Eg
> create in an HTML application might typically redirect the user to the
> created item, whereas an API will respond with a 201 CREATED response.
> There's stacks of other functionality and behavior that makes using Django
> REST framework simpler, quicker and likely more correct than if you start
> with plain Django. But those are some of the obvious differences to get
> started with.
>
> https://reddit.com/r/django/comments/3h9oj8/_/cu5pzu9/?context=1
>
> Seems pretty concise and self explanatory to me. This could easily be
> adapted to be in the docs.
>
> --
> You received this message because you are subscribed to the 

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Jason Johns
Tom Christie wrote this about what DRF brings to the table over plain Django:

Django REST framework isn't required, but it helps you get a lot of things 
right that will be time consuming and error prone if you're working from core 
Django.
 • Serializers
The Django serializers are not really suitable for anything other than dumping 
and loading fixture data - they don't allow you to customize the representation 
in any substantial way.
Using Django Forms for validation isn't suitable either as they're intended for 
HTML only validation and can't eg handle nested validation.
REST frameworks serializers are designed for API usage and cover both JSON or 
form validation, as well as being able to represent as either HTML Forms or 
formats such as JSON. They also give you lots of scope for handling the 
representation of relationships, such as using hyperlinked relations.
 • Authentication and permissions
REST framework's authentication will gracefully handle both session based and 
token based schemes at the same time, and get the CSRF behavior right. You'll 
find that really awkward to do if using plain Django. It also helps ensure 
you're issuing failure responses that are suitable for API clients (eg get 401 
vs 403 responses right)
The auth, permissions and throttling are also more flexible because they're 
defined at a view level, rather than as middleware or a view decorator. This 
makes it easier to eg combine multiple schemes, or to apply different schemes 
to different parts of your application.
 • Views
Django's generic class based views are suitable to HTML applications. REST 
framework's generic class based views are suitable for API services. Typicallly 
API views have slightly different behavior by convention. Eg create in an HTML 
application might typically redirect the user to the created item, whereas an 
API will respond with a 201 CREATED response.
There's stacks of other functionality and behavior that makes using Django REST 
framework simpler, quicker and likely more correct than if you start with plain 
Django. But those are some of the obvious differences to get started with.

https://reddit.com/r/django/comments/3h9oj8/_/cu5pzu9/?context=1

Seems pretty concise and self explanatory to me. This could easily be adapted 
to be in the docs.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/af24d69f-1d16-40db-9558-11745fce2399%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Cristiano Coelho
Pointing to Django Rest Framework should be more than enough. Anyone 
starting a project with Django and a SPA/JS architecture, will pretty much 
end up with DRF. Correct me if I'm wrong.


El lunes, 4 de febrero de 2019, 19:52:42 (UTC-5), Maciek Olko escribió:
>
> I didn't find this topic being discussed before.
>
> It seems to me to be good idea to place "How do I get Django and my JS 
> framework to work together?" or similar question and answer to it in FAQ in 
> Django's docs.
>
> Having very big popularity of JS frameworks now it is indeed very common 
> question being asked or searched on the Internet. Such question for ReactJS 
> has 65k views on StackOverflow [1]. 
>
> The answer could briefly explain that one can make use of Django backend 
> and produce API to be consumed by JS clients. Probably it would be good to 
> link to Django REST API project as a suggestion for big projects.
>
> What do you think about such addition to FAQ?
>
> Regards,
> Maciej
>
> [1] 
> https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/87fb9a35-b274-4d62-b17c-602114719ad5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Curtis Maloney

On 2/5/19 11:52 AM, Maciek Olko wrote:

I didn't find this topic being discussed before.



I guess it wouldn't take much to say "Just like any other server-side 
framework that can parse and generate arbitrary content, Django can be 
used to support any Javascript or Mobile app that talks HTTP(S)."


Since Django doesn't care what the client is, so long as it talks HTTP...

--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bde91f87-1afe-2f15-4b0b-8e37fd5780dd%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Kye Russell
Say what you want about the arguably unnecessary proliferation of complex
JavaScript applications / build pipelines upon the Internet over the past 5
or so years, but there’s no denying it’s becoming a necessary component in
a large portion of complex web projects.

I also think that—if it hasn’t already been done so already—the Django
documentation should at least contain a passing acknowledgement of this, as
well as some guidance on how to accomplish this.

Compare this to the latest iteration of Rails (I’ve never done more than
take a passing glance at the framework’s progress and am certainly no
expert) which includes a full webpack JS / asset pipeline as standard. I’m
aware of the philosophical differences between Django and Rails, and I’m
not necessary saying that bolting on Webpack was the right decision, but
it’s certainly speaks to how ‘back end’ framework development could lend a
helping hand beginners with a project that lends itself to a JS /
API-driven approach.

Kye


On 5 February 2019 at 8:52:38 am, Maciek Olko (maciej.o...@gmail.com) wrote:

I didn't find this topic being discussed before.

It seems to me to be good idea to place "How do I get Django and my JS
framework to work together?" or similar question and answer to it in FAQ in
Django's docs.

Having very big popularity of JS frameworks now it is indeed very common
question being asked or searched on the Internet. Such question for ReactJS
has 65k views on StackOverflow [1].

The answer could briefly explain that one can make use of Django backend
and produce API to be consumed by JS clients. Probably it would be good to
link to Django REST API project as a suggestion for big projects.

What do you think about such addition to FAQ?

Regards,
Maciej

[1]
https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CALYYG81uHehznRBvR4obTZr8685u0nm9y7yeUykPx8j0%3DJ-GyA%40mail.gmail.com

.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANK-yk%3DOWqmfCfSLOVKBxZJz2zxvJr74DFqUUkRac7w9yvr4%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.