Re: Improved ajax support idea
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 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/kgFbG9jc9IQJ. 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.
RedirectView supporting View-Names
Hi, is there a specific reason why the RedirectView does not have a "view_name" attribute and out-of-the-box supporting to reverse it? if self.url: url = self.url elif self.view_name: url = reverse(self.view_name, kwargs=kwargs, request=request) else: return None best regards ludwig -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/YaZrSyhb7fEJ. 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.
Re: Django Admin Revamp - Any updates?
For the record: It's bad timing for Idan. He lives in Tel Aviv which is currently receiving intermittent rocket attacks. He may be a bit slow to respond. ;) Let's wish him and his family safety and the luxury of worrying about django's admin in good time. On Thu, Nov 15, 2012 at 7:23 AM, Victor Hooi wrote: > Hi, > > I'm guessing there aren't any updates on this? Lol. > > Idan - you mentioned you'd like to get thoughts on what we hope to achieve > in a new admin - basically, what is the purpose of Django's contrib.admin - > is that right? > > Is there some place that people can brainstorm or contribute their thoughts > on this? Should somebody make a wiki page for collecting all this? > > Cheers, > Victor > > > On Friday, 18 May 2012 20:18:59 UTC+10, patrickk wrote: >> >> I agree with Idan. We mainly did Grappelli because of the look & feel (and >> then added some functionality like autocompletes). >> >> However, it just doesn´t make sense to simply "beautify" the existing >> admin-interface. Rethinking the functionality, adding flexibility, being >> able to customize ... these are all necessary steps IMHO, but I´m still >> missing a clear approach/roadmap on how/when this should happen. >> >> I planned to give a talk on djangocon.eu about how to improve the >> admin-interface. Unfortunately, I had to step back from that idea because of >> some customer-related projects. Still, the thoughts are there and I´m happy >> to discuss this issue anytime. This discussion could start with defining the >> so-called "trusted editor" – what does he/she knows resp. needs to know when >> dealing with the admin-interface? What are the consequences (e.g., does an >> editor care about an app-list, does he even know what it is)? What >> working-groups do we need (python, html/css, js, ...)? How can we publish >> the process/discussion? And much more ... let´s start ... but how? >> >> best, >> patrick >> >> >> Am Montag, 30. April 2012 23:41:14 UTC+2 schrieb Idan Gazit: >>> >>> >>> >>> On Monday, April 30, 2012 at 10:16 AM, Brett H wrote: >>> >>> > Increasing the flexibility for development and integration is more >>> > important than trying to 2nd guess where we are going to be in 5 years >>> > time. >>> >>> Fair enough, but that sort of flexibility is available now. Nothing is >>> preventing you from starting your 3rd-party admin app today. >>> >>> >>> >>> The issue is Django's officially-blessed, officially-documented admin. >>> I'm not sure it's better to have admin in contrib (or contrib at all, but >>> that's a separate ball of wax). I have a feeling that this issue will >>> probably be addressed once again now that we're on github. >>> >>> All the same, if there's going to be an official django admin, I'd like >>> it to give some thought to the issues I've raised. I have no problem (read: >>> would love) to draw upon existing solutions for an admin revamp, but right >>> now I don't have a fitness function to guide my decisions, and I think that >>> is necessary. Not a spec, just an attempt to step back and think about what >>> the admin should do. >>> >>> -I >>> >>> > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/CTFFiNcb9KMJ. > > 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.
Re: Improved ajax support idea
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': ,
> 'messages': [ installed>],
> 'error_fields': [],
> }
>
> 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.
Re: dumpdata with custom auth model
I have the same issue with django 1.5. I have a custom User model that extends AbstractUser. Regards -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/VFhbHqt6P4cJ. 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.
Re: Trigger an event on add another
All Django admin would have to do is call:
$(this).trigger('django.admin.another_added') or something like that.
It really sounds like little work and would allow user defined callbacks to
be executed.
What do you think ?
On Fri, Nov 9, 2012 at 12:29 PM, James Pic wrote:
> Hi all,
>
> Is it possible to trigger an event on add-another ?
>
> Or is there a better solution to work around this problem ?
> https://github.com/yourlabs/django-autocomplete-light/blob/master/autocomplete_light/static/autocomplete_light/widget.js#L267
>
> Thanks for answering
>
> Regards
>
--
http://blog.yourlabs.org
Customer is king - Le client est roi - El cliente es rey.
--
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.
Re: Trigger an event on add another
My bad I didn't see Mark's mail, I'll subscribe to the list and hopefully this shouldn't happen again. Thanks Mark for answering -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/0SuXBSwTQMoJ. 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.
Re: RedirectView supporting View-Names
See https://code.djangoproject.com/ticket/15273 On 23 November 2012 23:30, Ludwig Kraatz wrote: > Hi, > > is there a specific reason why the RedirectView does not have a > "view_name" attribute and out-of-the-box supporting to reverse it? > > if self.url: > url = self.url > elif self.view_name: > url = reverse(self.view_name, kwargs=kwargs, request=request) > else: > return None > > best regards > ludwig > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/YaZrSyhb7fEJ. > 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.
Re: Django Admin Revamp - Any updates?
Hi, Aha, I didn't realise he live in Tel Aviv. Perhaps I should FB stalk people more *grins*. Well, our prayers are with you, Idan, hope you're keeping safe =). Cheers, Victor On Thu, Nov 22, 2012 at 1:01 PM, Jeremy Dunck wrote: > For the record: It's bad timing for Idan. He lives in Tel Aviv which > is currently receiving intermittent rocket attacks. He may be a bit > slow to respond. ;) > > Let's wish him and his family safety and the luxury of worrying about > django's admin in good time. > > On Thu, Nov 15, 2012 at 7:23 AM, Victor Hooi wrote: > > Hi, > > > > I'm guessing there aren't any updates on this? Lol. > > > > Idan - you mentioned you'd like to get thoughts on what we hope to > achieve > > in a new admin - basically, what is the purpose of Django's > contrib.admin - > > is that right? > > > > Is there some place that people can brainstorm or contribute their > thoughts > > on this? Should somebody make a wiki page for collecting all this? > > > > Cheers, > > Victor > > > > > > On Friday, 18 May 2012 20:18:59 UTC+10, patrickk wrote: > >> > >> I agree with Idan. We mainly did Grappelli because of the look & feel > (and > >> then added some functionality like autocompletes). > >> > >> However, it just doesn´t make sense to simply "beautify" the existing > >> admin-interface. Rethinking the functionality, adding flexibility, being > >> able to customize ... these are all necessary steps IMHO, but I´m still > >> missing a clear approach/roadmap on how/when this should happen. > >> > >> I planned to give a talk on djangocon.eu about how to improve the > >> admin-interface. Unfortunately, I had to step back from that idea > because of > >> some customer-related projects. Still, the thoughts are there and I´m > happy > >> to discuss this issue anytime. This discussion could start with > defining the > >> so-called "trusted editor" – what does he/she knows resp. needs to know > when > >> dealing with the admin-interface? What are the consequences (e.g., does > an > >> editor care about an app-list, does he even know what it is)? What > >> working-groups do we need (python, html/css, js, ...)? How can we > publish > >> the process/discussion? And much more ... let´s start ... but how? > >> > >> best, > >> patrick > >> > >> > >> Am Montag, 30. April 2012 23:41:14 UTC+2 schrieb Idan Gazit: > >>> > >>> > >>> > >>> On Monday, April 30, 2012 at 10:16 AM, Brett H wrote: > >>> > >>> > Increasing the flexibility for development and integration is more > >>> > important than trying to 2nd guess where we are going to be in 5 > years > >>> > time. > >>> > >>> Fair enough, but that sort of flexibility is available now. Nothing is > >>> preventing you from starting your 3rd-party admin app today. > >>> > >>> > >>> > >>> The issue is Django's officially-blessed, officially-documented admin. > >>> I'm not sure it's better to have admin in contrib (or contrib at all, > but > >>> that's a separate ball of wax). I have a feeling that this issue will > >>> probably be addressed once again now that we're on github. > >>> > >>> All the same, if there's going to be an official django admin, I'd like > >>> it to give some thought to the issues I've raised. I have no problem > (read: > >>> would love) to draw upon existing solutions for an admin revamp, but > right > >>> now I don't have a fitness function to guide my decisions, and I think > that > >>> is necessary. Not a spec, just an attempt to step back and think about > what > >>> the admin should do. > >>> > >>> -I > >>> > >>> > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/django-developers/-/CTFFiNcb9KMJ. > > > > 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.
Re: Improved ajax support idea
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 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': ,
> > 'messages': [ installed>],
> > 'error_fields': [ 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.
Re: dumpdata with custom auth model
Hi Benoit, Like I said in my last response, I'm *not* seeing the problem. Saying "I'm seeing the problem" doesn't help me. Saying "I've got a custom User" doesn't help me either -- I've got a custom User (several, actually - a test case extending AbstractUser and one extending AbstractBaseUser, plus a of live projects using custom user models), and dumpdata is working fine for me on all of them. What I need is a complete project that demonstrates the problem -- the minimal set of instructions necessary to reproduce the problem you are seeing. I also need you to tell me what version of trunk you're using. Django 1.5 hasn't been released yet, so the problem is with a specific revision, not with a final release, and since the branch is under constant development, the *exact* revision matters. Yours, Russ Magee %-) On Fri, Nov 23, 2012 at 5:33 PM, Benoit Petit wrote: > I have the same issue with django 1.5. I have a custom User model that > extends AbstractUser. > > Regards > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/VFhbHqt6P4cJ. > > 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.
