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 %-)
On Fri, Nov 23, 2012 at 10:12 PM, rohit jangid <rohit.nsi...@gmail.com>wrote:
> 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
> On 22-Nov-2012, at 4:09 PM, James Pic wrote:
>
> > 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
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
