Re: Improved ajax support idea

[Russell Keith-Magee]

On Sun, Nov 25, 2012 at 1:10 AM, James Pic  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 %-)

-- 
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: Confusion with Unicode

[Russell Keith-Magee]

On Sat, Nov 24, 2012 at 9:55 PM, Santiago Basulto <
santiago.basu...@gmail.com> wrote:

> Hey guys, i'm posting this here because I posted this on django-users
> yesterday and didn't get any help.
>
> I realise someone has now answered your question -- but *please* don't use
django-developers as "second tier" technical support. Django-dev is for
discussing the development of Django itself, not for general usage queries.
You should only be posting to django-dev if you want to get involved in the
development of Django itself.

It's unfortunate that nobody answered your question on django-users, but
this is a volunteer community -- sometimes that means you're not going to
get a response. All I can suggest is that you wait, try rephrasing your
question, or try another forum -- e.g. IRC.

Yours,
Russ Magee %-)

-- 
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

[Jani Tiainen]

On Sat, Nov 24, 2012 at 7:10 PM, James Pic  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". 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 !
>
>
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...

-- 
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: Confusion with Unicode

[Ian Kelly]

On Sat, Nov 24, 2012 at 6:55 AM, Santiago Basulto
 wrote:
> Hey guys, i'm posting this here because I posted this on django-users
> yesterday and didn't get any help.
>
> I'm kind of confused here...
>
> If I get data from a request, say:
>
> request.GET.get("something") or request.POST.get("something")
>
> Is that data automatically being encoded based on the Encoding of the
> request? Or I should take care of it explicitly?

The contents of a Django HttpRequest.GET or HttpRequest.POST are
automatically decoded to Unicode for you, using the encoding specified
in HttpRequest.encoding.

-- 
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

[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.

-- 
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 1.5 release plans

[Aymeric Augustin]

The beta is released when there aren't any release blockers left, or when the 
remaining ones are considered sufficiently benign to be fixed later on.

https://dashboard.djangoproject.com/metric/blockers/

-- 
Aymeric.

-- 
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 1.5 release plans

[Thiago Carvalho D' Ávila]

According to Jacab s plan the distance between alpha and beta release is a
month. As the alpha was released 25 of October, I think beta is near..
unless there are new delays to come.
Em 21/11/2012 21:40, "Emil Kjer"  escreveu:

> Is there an ETA for release of Django 1.5 beta?
>
> Thanks
> Emil
>
> On Wednesday, September 12, 2012 12:22:20 AM UTC+10, Jacob Kaplan-Moss
> wrote:
>>
>> Hi folks --
>>
>> I wanted to fill everyone in on our plans for the Django 1.5 release.
>> The highlights are:
>>
>> * Feature freeze October 1st, final out before Christmas.
>>
>> * One marquee feature of Django 1.5 is experimental Python 3 support.
>> This is where we need your help the most: we need to be sure that our
>> support for Python 3 hasn't destabilized Django on Python 2. We need
>> lots of testing here!
>>
>> * Most features of 1.5 have already landed, but we're also hoping to
>> land the new pluggable User model work, add support for PostGIS 2.0,
>> start the process of deprecating django.contrib.localflavor, and a few
>> other small things.
>>
>> * This'll be our first "master never closes" release: work, including
>> new features, can continue to land on master while we ship the
>> release.
>>
>> Please read on for details.
>>
>> Timeline
>> 
>>
>> Oct 1: Feature freeze, Django 1.5 alpha.
>> Nov 1: Django 1.5 beta.
>> Nov 26: Django 1.5 RC 1
>> Dec 10: Django 1.5 RC 2
>> Dec 17: Django 1.5 RC 3, if needed
>> Dec 24 (or earlier): Django 1.5 final
>>
>> (All dates are "week of" - we'll do the releases that week, though not
>> neccisarily that exact day.)
>>
>> Notice the longer-than-usual timeline from beta to final. We're doing
>> this to provide some extra time stablizing the release after landing
>> the Python 3 work. Please see below for details and how you can help.
>>
>> Python 3 support
>> 
>>
>> Django 1.5 includes experimental support for Python 3 (it's already
>> landed on master). We're taking a "shared source" approach: Django's
>> code is written in a way that runs on both Python 2 and Python 3
>> (without needing 2to3's translation). This means that we've touched
>> nearly the entire codebase, and so the surface area for possible bugs
>> is huge.
>>
>> WE REALLY NEED YOUR HELP testing out Django 1.5 *on Python 2*. Please
>> grab master, or one of the upcoming alpha/beta/RC releases, and test
>> it against your apps and sites. We need you to help us catch
>> regressions.
>>
>> We're not yet recommending that people target Python 3 for deployment,
>> so our main focus here is ensuring that we're still rock-solid on
>> Python 2. If you *want* to give Python 3 a whirl things should be
>> pretty solid, but we *especially* need real-world reports of success
>> or failure on Python 2.
>>
>> Features in 1.5
>> ---
>>
>> Besides the stuff that's already landed (see
>> https://docs.djangoproject.**com/en/dev/releases/1.5/),
>> there are a few
>> other features we're hoping to land:
>>
>> * The "pluggable User model" work (Russell Keith-Magee).
>> * Some early low-level schema alteration plumbing work (Andrew Godwin).
>> * Moving django.contrib.localflavor out into individual external
>> packages (Adrian Holovaty).
>> * Support for PostGIS 2.0 (Justin Bronn).
>> * Python 3 support in GeoDjango (Aymeric Augustin).
>> * App-loading (Preston Holmes) is "on the bubble" - there's some
>> debate among the core team over whether its ready, but it's close.
>>
>> Of course, as with our previous releases, the *real* list of what'll
>> go in 1.5 is "whatever's done by October 1st". If you want to help
>> with any of the above areas, contact the person doing the bulk of the
>> work (listed above) and ask to help. And if you have other features
>> you'd like to land, get 'em done!
>>
>> Master never closes
>> ---
>>
>> This'll mark our first release where "master never closes".
>>
>> To recap: in previous releases, once we hit feature freeze we froze
>> the development trunk, forcing all feature work out to branches. In
>> practice, this meant months-long periods where new features couldn't
>> be merged, and led to some stuff withering on the vine.
>>
>> That's not going to happen this time. Instead, when we release 1.5
>> alpha we'll make a 1.5 release branch right at that point. Work will
>> continue on master -- features, bugfixes, whatever -- and the
>> aplicable bugfixes will be cherry-picked out to the 1.5 release
>> branch.
>>
>> The upshot is a bit more work for us committers -- we'll have to be
>> sure to merge the aplicable commits over -- but no more "sorry you
>> have to wait three months to merge this work." I'm very happy about
>> this!
>>
>> [Committers: I'm happy to assist with this porting of bugfixes from
>> master to the release branch.]
>>
>> See you on the other side, folks!
>>
>> Jacob
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django 

Re: dumpdata with custom auth model

[Bruno Renié]

Hello,

On Sat, Nov 24, 2012 at 7:43 AM, Russell Keith-Magee
 wrote:
> 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.

Out of curiosity I ran 'dumpdata auth' on one of our projects that
uses the 1.5 branch and got the same error. I tried to reproduce it
and it turns out this was fixed very recently, in c8985a8a73 [0].

With Django installed using
https://github.com/django/django/tarball/0a0a0d66b3 -> error on
'manage.py dumpdata auth'

With Django installed using
https://github.com/django/django/tarball/c8985a8a73 -> no error.

Christian, Benoit: could you try again using a recent tarball of the 1.5 branch?

Russel: thanks for your work on this feature, which is already proving
very useful for us :)

Regards,
Bruno

[0] https://github.com/django/django/commit/c8985a8a73

> 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.

-- 
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

[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!

On Fri, Nov 23, 2012 at 10:53 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> 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.
>

-- 
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.

Confusion with Unicode

[Santiago Basulto]

Hey guys, i'm posting this here because I posted this on django-users 
yesterday and didn't get any help.

I'm kind of confused here... 

If I get data from a request, say: 

request.GET.get("something") or request.POST.get("something") 

Is that data automatically being encoded based on the Encoding of the 
request? Or I should take care of it explicitly? 

Thank you. 

-- 
Santiago Basulto.- 

-- 
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/-/PEHu7nmzFwAJ.
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.