Improved ajax support idea

[James Pic]

Hi all,

More projects use AJAX nowadays. Django could help them more.

For example, FormView, could check if request.is_ajax_request(), and in that case return a JSON dict for example:

{

    'html': <the rendered HTML form without the layout>,

    'messages': [<a list of messages if django.contrib.messages is installed>],

    'error_fields': [<perhaps a list of field names that did not validate>],

}

All generic views could do something like this. The point is to provide a consistent API usable in AJAX.

This doesn't seem like much work, but for some reason I like this idea a lot.

What do you think ?

I could work on a complete design document and documentation if you think it's worth it.

Regards

[Timothy Clemans]

I like the idea. Could you create a third party app so I could use it right away?

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Florian Apolloner]

Hi,

On Thursday, November 22, 2012 11:39:54 AM UTC+1, is_null wrote:

More projects use AJAX nowadays. Django could help them more.

Django somehow does that already: It doesn't stand in your way :)
 

All generic views could do something like this. The point is to provide a consistent API usable in AJAX.

Given tools like knockoutjs and backbone with mappings between clientside and server I don't think that your proposed solution would cover many usecases.One would also need hooks to add extra data like normal views do with get_context_data etc…
 

What do you think ?

Certainly nothing for Django-core at this time (at least in my personal opinion) and perfectly doable as 3-rd party app. Once your app gets traction and becomes the defacto-standard to use (more or less like south) we will think about including it.

Don't get me wrong, I am not against Django providing a few helpers to make ajax heavy apps easier, I just don't think that your current approach will reach anything near 80:20 usability (I'd happily be proven wrong). For example sending the form as html to the client is probably not something everyone wants given the js-templating solutions like mustache etc…

Best regards,
Florian

[rohit jangid]

I really liked the idea of more advanced inbuilt support for ajax in django . I use django for my work and more than 80% of our time we use ajax. would really like to participate and work on it .
thanks

[Russell Keith-Magee]

I use a lot of AJAX in my projects as well. 

However, it that doesn't mean that *Django* needs to include advanced AJAX support.

I (and other members of the core team) have said this many times in the past -- the Django community benefits when Django isn't a monolithic core. 

From a technical perspective, I see no reason why the sort of features you're talking about need to be in Django's core.

The only reason to put these views in Django's core would be social -- by putting them in core they get 'blessed' as a preferred approach. And there's a downside to doing this -- it means that the rate of development becomes tied to Django's own release cycle. It also means that maintenance is either limited to those in the core team, or we need to increase the size of the core team

As a case in point - there are several tools out there for building ReST APIs - TastyPie, Piston, Django ReST framework, and probably others. They all thrive as third party projects, and the broader community benefits from having competition. None of them need to be in trunk to gain popular support. They have independent release cycles, and independent development teams. And the broader Django community benefits as a result of this diversity.

So - from my perspective, I'd say a AJAX-enhanced generic views sounds like a great idea, and I'd love to see what you can develop. However, I don't think the core is the right place for those views to live.

Yours,

Russ Magee %-)

[Ariel Arias]

Hi! 

I use a lot of Ajax with Django too, but I agree that this kind of solutions should not be inside the core of Django. It can be very well solved by third party projects and include it in the core can make Django lose one of his better things : freedom. Because developers will "understand" that Django is telling you how to manage that.

Regards!

[James Pic]

Hello everybody,

Thank you for your feedback. And pretty soon I will tackle this problem in an external app - or consider joining the party if somebody else has started, in this case feel free to let me know.

I can understand most of the points made here, expect just one, please bare with me. Several hackers on this list stated that it has "obviously not its place in Django". I don't understand why generic non ajax views would have a their place in django, and ootb ajax support would not. But I'm really curious.

It would be great if someone could elaborate on that, because from what I understand:

- django has generic views, you are free to use them, you can use your own, or you can use those that are provided by external apps,

- if django had generic views with ajax support, you would be free to use the ajax support, or use your own, or use those that are provided by external apps.

I just fail to see the difference, it would be great if someone could explain that !

Thanks for your feedback.

[Jani Tiainen]

It's because generic views produces HTML that is pretty much standard across the different browsers. There is no magic involved there. But there is no standard that what ajax response should look like. Or actually that acronym includes word XML.

For JS most of us does use some JS framework like jQuery, Dojo toolkit, Mootools, ExtJS, just few to name. All of those like to have slightly different responses. See the pattern?

There exists also few nice additional frameworks like Tastypie or Rest framework that does excellent job to bring powerful tools that can talk restful services - and those are quite suitable for ajax consumption. Some of the frameworks even does have somekind of implementation to use them directly.

--
Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

[Russell Keith-Magee]

On Sun, Nov 25, 2012 at 1:10 AM, James Pic <jame...@gmail.com> wrote:

Hello everybody,

Thank you for your feedback. And pretty soon I will tackle this problem in an external app - or consider joining the party if somebody else has started, in this case feel free to let me know.

I can understand most of the points made here, expect just one, please bare with me. Several hackers on this list stated that it has "obviously not its place in Django".

Just in case you didn't know, one of the "several hackers" is a core developer… (cough cough)

 

I don't understand why generic non ajax views would have a their place in django, and ootb ajax support would not. But I'm really curious.

It would be great if someone could elaborate on that, because from what I understand:

- django has generic views, you are free to use them, you can use your own, or you can use those that are provided by external apps,

- if django had generic views with ajax support, you would be free to use the ajax support, or use your own, or use those that are provided by external apps.

I just fail to see the difference, it would be great if someone could explain that !

In all honesty, the best explanation isn't a good one -- it's historical. Django had generic views when it was publicly released (or very soon afterwards), and they've been part of the tutorial since that time. They're now embedded in the general consciousness of "what Django is", so it's hard to pull them out again.

I'll completely grant that this explanation is a little "post hoc, ergo procter hoc". If Django didn't have generic views today, and someone proposed adding them, they'd probably get the same response you're getting on adding AJAX capabilities.

However, if I had to try and justify the existence of generic views, I'd use a scaffolding argument -- that generic views wrap common pattern of data access, which can be useful when you're trying to throw up a skeleton for a site. However, as you need more and more functionality, you swap out parts of the scaffold for custom built views.

That said, I don't think generic views are a waste of time -- I think they're the start of a framework unto themselves. The broad patterns embodied in GCBVs -- show me details of a single object; show me a list of objects; etc -- are fairly familiar to anyone who builds sites, but modern sites need to do a whole lot more, like support AJAX, PJAX, web sockets and so on. I think there's plenty of room for a framework of generics -- I just question whether that framework needs to be part of Django's core.

Yours,

Russ Magee %-)

[ptone]

On Saturday, November 24, 2012 9:11:17 AM UTC-8, is_null wrote:

Hello everybody,

I can understand most of the points made here, expect just one, please bare with me. Several hackers on this list stated that it has "obviously not its place in Django". I don't understand why generic non ajax views would have a their place in django, and ootb ajax support would not. But I'm really curious.

It would be great if someone could elaborate on that, because from what I understand:

- django has generic views, you are free to use them, you can use your own, or you can use those that are provided by external apps,

- if django had generic views with ajax support, you would be free to use the ajax support, or use your own, or use those that are provided by external apps.

One distinction is that generic views don't provide anything in the way of default templates.  They help with the data pattern on the Django side, and you choose how it goes to the browser in a template.  In an ajax response, the data is returned directly to the JS code in the browser.  Because different JS frameworks may expect data in different arrangements - you end up coupling the generic ajax code to some expectation set by the browser JS code.

More relevant to such an effort would be whether there was anything in the CBVs that stood in the way fundamentally. The current thought is that there isn't, but one couldn't be sure until there was an attempt.

-Preston

[James Pic]

I understand what you mean, I realized my point of view was too user-centric and not very conceptual. So, thanks for that and I'm still totally up to make or help making an external app in my next re-factor session.

Here's a single point I'd like the list's attention: it would be great if we could make urls easier to reverse in Javascript. If you don't understand what I mean, here's a post which elaborates: http://blog.yourlabs.org/post/36514630158/django-ajax-how-to-reverse-urls-in-javascript-not

I know I'm no Tim Berners-Lee but maybe some of you will understand the point that I'm trying to make on reversing urls in Javascript.

And hell yeah Russ ! I've seen you look damn handsome on various conference videos xD do you know you're pretty famous ? hehehe gotcha ! Seriously, I really like your work; also I'm really happy with the work done by the Django core and users community. So, I'm confident in the future of Django which I've been loving for years too ... and I can understand very well how Django as a whole can have an important place in one's heart.

I'm sorry I didn't answer your mail one time I contacted the list about javascript in the admin, it simply didn't arrive to my mailbox (as did a few others) ... Maybe google groups feature "subscribe to my topics" became non-default ?! Anyway, you probably don't remember that email at all.

I did read your answer carefully though quite some month later, and I'm taking the same approach again, hence the small "javascript and url reversal" topic which is part of a bigger "django and ajax" topic. Maybe "javascript and url reversal" should be a new list topic ? I don't know, excuse me if it should.

[Javier Guerra Giraldez]

On Sun, Nov 25, 2012 at 12:04 PM, James Pic <jame...@gmail.com> wrote:
> it would be great if we could make urls easier to reverse in Javascript.

you shouldn't have to.

good REST design means not using database IDs. any response that
references server resources should send a whole URL. no need to
construct them in the client. check the HATEOAS principle.

http://www.slideshare.net/trilancer/why-hateoas-1547275



--
Javier

[James Pic]

Wow, thanks a lot.

I would like to thanks everybody who answered. I have learned a lot from this thread and thanks to you I believe I am a better programmer.

FTR, I've added an article to my blog which obsoletes the previous article.

Kind regards from Spain

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

--
http://blog.yourlabs.org
Customer is king - Le client est roi - El cliente es rey.