Re: Thank you to our security aware developers

[Russell Keith-Magee]

Hi Chris,

Thanks for the kind words. It's always nice to know when your efforts are
appreciated.

As for the suggestion about the error message -- that's sounds like a
reasonable idea to me; feel free to open a ticket. If you're looking to get
involved in the development of Django itself, this should be a fairly easy
issue to fix, too (since you're just changing/clarifying the text of an
existing error message).

Yours,
Russ Magee %-)

On Sat, Dec 1, 2012 at 7:03 AM, Chris Cogdon  wrote:

> I want to give a big "thumbs up" to the folk that worked on
> InlineForeignKeyField, inlineformset_factory, and their friends.
>
> I just used inlineformset_factory for my project, saw that it was writing
> the parent id out into hidden form variables and, thinking that this seemed
> "unnecessary" and a possible vector for an attack. Ie, anything that's in
> the hands of the end-user should never be trusted.
>
> So, I faked up a page that had all the proper stuff, but changed one of
> the IDs in the hidden field to point to a different parent, and submitted.
> I got: "The inline foreign key did not match the parent instance primary
> key."
>
> Woot! Very good. Thank you, guys!
>
> The only nit I'd have about this is that (I think) this error message
> should never occur, and if it does, something is wrong that is outside the
> hands of a (normal) end-user. Something less "you did something (too
> complex to understand) wrong" would likely be better , such as:
>
> "Web-site internal error. Inline foreign key mismatch."
>
> To an end-user that seems like enough programmer-ese that they'll not try
> hunting to figure out what _they_ did wrong.
>
>  --
> 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/-/qlav3hLbnOoJ.
> 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.

Thank you to our security aware developers

[Chris Cogdon]

I want to give a big "thumbs up" to the folk that worked on 
InlineForeignKeyField, inlineformset_factory, and their friends.

I just used inlineformset_factory for my project, saw that it was writing 
the parent id out into hidden form variables and, thinking that this seemed 
"unnecessary" and a possible vector for an attack. Ie, anything that's in 
the hands of the end-user should never be trusted. 

So, I faked up a page that had all the proper stuff, but changed one of the 
IDs in the hidden field to point to a different parent, and submitted. I 
got: "The inline foreign key did not match the parent instance primary key."

Woot! Very good. Thank you, guys!

The only nit I'd have about this is that (I think) this error message 
should never occur, and if it does, something is wrong that is outside the 
hands of a (normal) end-user. Something less "you did something (too 
complex to understand) wrong" would likely be better , such as:

"Web-site internal error. Inline foreign key mismatch."

To an end-user that seems like enough programmer-ese that they'll not try 
hunting to figure out what _they_ did wrong.

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

testing tutorial feedback needed! (was: Testing documentation)

[Tim Graham]

Bumping this in hopes of getting a couple more reviews.

Please leave comments on the ticket or pull request:
https://code.djangoproject.com/ticket/9962
https://github.com/django/django/pull/548

On Tuesday, November 13, 2012 3:54:15 PM UTC-5, Tim Graham wrote:
>
> This looks great, thanks for your work on this!  I've made some minor 
> revisions and put up an HTML version of the new tutorial for easier review.
>
> http://techytim.com/django/9962/intro/tutorial05.html
>
> On Monday, November 5, 2012 12:06:53 PM UTC-5, Daniele Procida wrote:
>>
>> I have done some work on writing up a tutorial for testing (part 5 of the 
>> existing tutorial, in effect). 
>>
>> My draft so far: 
>>
>> <
>> https://github.com/evildmp/django/blob/testing-tutorial/docs/intro/tutorial05.txt>
>>  
>>
>>
>> I'd really appreciate feedback, on any aspect of this. 
>>
>> Trac ticket is . 
>>
>> Thanks, 
>>
>> Daniele 
>>
>>

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

Modify .save() implementation

[Anssi Kääriäinen]

I would like to change the implementation of .save(). In the following
case:

s = SomeModel.objects.get(pk=somepk)
s.somefield = val
s.save()

we currently do this:

SELECT (from .get())
SELECT (from .save())
UPDATE

The second SELECT is redundant. We have knowledge that the model was
loaded from the same DB in s._state. So, we could instead do just:
SELECT (from .get())
UPDATE

If the UPDATE doesn't match anything (due to concurrent delete for
example), then we can still do an INSERT. So, from user perspective
the behaviour isn't changed.

The force_update flag isn't doing the exact same thing - when using
force_update and the UPDATE doesn't change anything the INSERT isn't
done, instead an error is risen.

In most UPDATE situations this should reduce one SELECT from
model.save().

The only problem I can see is that we have very explicitly documented
how .save() behaves. The generated queries are documented. I don't
consider the generated queries part of the publlic API, just the
behaviour.

All tests on all core backends do pass using the "UPDATE, if not
updated INSERT" behaviour. See ticket #16649 for patch & details.

Any objections moving forward with this plan?

 - Anssi

-- 
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: Yet another __ne not equal discussion

[Anssi Kääriäinen]

On 30 marras, 19:16, Florian Apolloner  wrote:
> On Friday, November 30, 2012 6:12:43 PM UTC+1, Shai Berger wrote:
>
> > live_articles = Article.objects.exclude(status="archived")
> > live_cats = Category.objects.filter(article__in=live_articles)
>
> That works and it has the positive side-effect to kill any mysql server in
> a matter of seconds :)

Is there any change in performance if EXISTS was used instead of IN?
Or is it just that MySQL and subqueries do not mix well?

 - Anssi

-- 
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: Yet another __ne not equal discussion

[Anssi Kääriäinen]

On 30 marras, 15:29, Marek Brzóska  wrote:
> Has the matter been completely put away?
>
> I would like to bring it up again.
>
> I have Articles and Categories. An Article belongs to Categories:
>
> class Category(model):
>   pass
> class Article(model):
>   category = ManyToManyField(Category)
>   status = CharField(max_length=10)
>
> Now I want all categories with articles that have status different than
> "archived".
>
> I cannot do this with django's ORM!
>
> Category.objects.filter(~Q(article_status="archived"))
>
> will result in a query like this (simplified for readibility):
> SELECT * FROM
> category LEFT OUTER JOIN articlecategory ON category.id =
> articlecategory.category_id
> WHERE NOT
> "category"."id" IN (
>   SELECT U1."category_id"
>   FROM "articlecategory" U1 INNER JOIN "article" U2 ON (U1."article_id" =
> U2."id")
>   WHERE
>   (
>       U2."status" = 'Archived'
>       AND U1."category_id" IS NOT NULL
>    )
> )
>
> The key problem here is that the ~Q() part negates whole big part of SQL
> query, and instead of getting all categories with at least one not archived
> article, I get all categories that have no archived articles! You must
> agree, that it is not very unlikely that someone wants to query for sth
> like this. I cannot use Q(__lt)|Q(__gt) becouse this is not integer. If
> status was enumerated, I could select all values that are different than
> "archived". But in this case I cannot do anything (except custom sql which
> seems like overkill to such simple need).

Hmmh, it would be nice if there was a way to get the wanted query
using the ORM.

Still, if ~Q() is different than __ne that is going to be somewhat
surprising for those users who do not know the ORM well.

For other solutions, one way is custom lookups. They might be reality
for 1.6, see: #16187. Using custom lookups you could have __not_in and
__ne if you so wish.

Another solution might be some sort of aliasing support:
qs.alias(articles1='article',
subquery=False).exclude(articles1__category='archived')
in general I would really like to have aliasing support, it could
allow for some fancy things, like aliasing raw SQL into the query...

All in all I think it is better to have some way to get the wanted
query out of the ORM than no way at all. Even if that way is a bit non-
obvious.

 - Anssi

-- 
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: Yet another __ne not equal discussion

[Florian Apolloner]

On Friday, November 30, 2012 6:12:43 PM UTC+1, Shai Berger wrote:
>
> live_articles = Article.objects.exclude(status="archived") 
> live_cats = Category.objects.filter(article__in=live_articles) 
>

That works and it has the positive side-effect to kill any mysql server in 
a matter of seconds :) 

-- 
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/-/iWU496Kw27IJ.
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: Yet another __ne not equal discussion

[Shai Berger]

On Friday 30 November 2012, Marek Brzóska wrote:
> Has the matter been completely put away?
> 
> I would like to bring it up again.
> 
> I have Articles and Categories. An Article belongs to Categories:
> 
> class Category(model):
>   pass
> class Article(model):
>   category = ManyToManyField(Category)
>   status = CharField(max_length=10)
> 
> Now I want all categories with articles that have status different than
> "archived".
> 
> I cannot do this with django's ORM!
> 

live_articles = Article.objects.exclude(status="archived")
live_cats = Category.objects.filter(article__in=live_articles)

Doesn't this do the trick for you?

-- 
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: Yet another __ne not equal discussion

[Alex Ogier]

To be fair, the query you describe is significantly more expensive than
Marek's query.


On Fri, Nov 30, 2012 at 10:20 AM, Tom Evans wrote:

> On Fri, Nov 30, 2012 at 2:51 PM, Marek Brzóska 
> wrote:
> >
> >
> >
> > 2012/11/30 Tom Evans 
> >>
> >> On Fri, Nov 30, 2012 at 1:29 PM, Marek Brzóska 
> >> wrote:
> >> > Has the matter been completely put away?
> >> >
> >> > I would like to bring it up again.
> >> >
> >> > I have Articles and Categories. An Article belongs to Categories:
> >> >
> >> > class Category(model):
> >> >   pass
> >> > class Article(model):
> >> >   category = ManyToManyField(Category)
> >> >   status = CharField(max_length=10)
> >> >
> >> > Now I want all categories with articles that have status different
> than
> >> > "archived".
> >> >
> >> > I cannot do this with django's ORM!
> >> >
> >> > Category.objects.filter(~Q(article_status="archived"))
> >>
> >> What precisely is wrong with:
> >>
> >> Category.objects.exclude(article_status='archived')
> >
> > It excludes all categories that have at least one archived article.
> >
> > And I want categories that have at least one NOT archived article.
> >
> > Example: I have one category: politics. I have two articles in this
> > category: "Vote Obama!" which archived and "U.S wars" which is not
> archived.
> > Category.objects.exclude(article_status='archived')
> > will show no categories, while I want my only category to show, because
> > there is one not archived article, "U.S. wars".
>
> That's a very different question:
>
>
> Category.objects.exclude(article__status='archived').annotate(num_articles=Count('article')).filter(num_articles__gt=0)
>
> Still answerable via the ORM.
>
> Cheers
>
> Tom
>
> --
> 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: Yet another __ne not equal discussion

[Marek Brzóska]

>
> >> What precisely is wrong with:
> >>
> >> Category.objects.exclude(article_status='archived')
> >
> > It excludes all categories that have at least one archived article.
> >
> > And I want categories that have at least one NOT archived article.
> >
> > Example: I have one category: politics. I have two articles in this
> > category: "Vote Obama!" which archived and "U.S wars" which is not
> archived.
> > Category.objects.exclude(article_status='archived')
> > will show no categories, while I want my only category to show, because
> > there is one not archived article, "U.S. wars".
>
> That's a very different question:
>
>
> Category.objects.exclude(article__status='archived').annotate(num_articles=Count('article')).filter(num_articles__gt=0)
>
> Still answerable via the ORM.
>

No!  The moment you wrote exclude(article__status='archived') you excluded
my category, because it has an article with status "archived". Please
reread my original message, you seem to miss my point completely.

>
Marek Brzóska
brzoskama...@gmail.com

-- 
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: Yet another __ne not equal discussion

[Tom Evans]

On Fri, Nov 30, 2012 at 2:51 PM, Marek Brzóska  wrote:
>
>
>
> 2012/11/30 Tom Evans 
>>
>> On Fri, Nov 30, 2012 at 1:29 PM, Marek Brzóska 
>> wrote:
>> > Has the matter been completely put away?
>> >
>> > I would like to bring it up again.
>> >
>> > I have Articles and Categories. An Article belongs to Categories:
>> >
>> > class Category(model):
>> >   pass
>> > class Article(model):
>> >   category = ManyToManyField(Category)
>> >   status = CharField(max_length=10)
>> >
>> > Now I want all categories with articles that have status different than
>> > "archived".
>> >
>> > I cannot do this with django's ORM!
>> >
>> > Category.objects.filter(~Q(article_status="archived"))
>>
>> What precisely is wrong with:
>>
>> Category.objects.exclude(article_status='archived')
>
> It excludes all categories that have at least one archived article.
>
> And I want categories that have at least one NOT archived article.
>
> Example: I have one category: politics. I have two articles in this
> category: "Vote Obama!" which archived and "U.S wars" which is not archived.
> Category.objects.exclude(article_status='archived')
> will show no categories, while I want my only category to show, because
> there is one not archived article, "U.S. wars".

That's a very different question:

Category.objects.exclude(article__status='archived').annotate(num_articles=Count('article')).filter(num_articles__gt=0)

Still answerable via the ORM.

Cheers

Tom

-- 
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: Yet another __ne not equal discussion

[Marek Brzóska]

2012/11/30 Tom Evans 

> On Fri, Nov 30, 2012 at 1:29 PM, Marek Brzóska 
> wrote:
> > Has the matter been completely put away?
> >
> > I would like to bring it up again.
> >
> > I have Articles and Categories. An Article belongs to Categories:
> >
> > class Category(model):
> >   pass
> > class Article(model):
> >   category = ManyToManyField(Category)
> >   status = CharField(max_length=10)
> >
> > Now I want all categories with articles that have status different than
> > "archived".
> >
> > I cannot do this with django's ORM!
> >
> > Category.objects.filter(~Q(article_status="archived"))
>
> What precisely is wrong with:
>
> Category.objects.exclude(article_status='archived')
>
It excludes all categories that have at least one archived article.

And I want categories that have at least one NOT archived article.

Example: I have one category: politics. I have two articles in this
category: "Vote Obama!" which archived and "U.S wars" which is not archived.
Category.objects.exclude(article_status='archived')
will show no categories, while I want my only category to show, because
there is one not archived article, "U.S. wars".


>
> >
> > will result in a query like this (simplified for readibility):
> > SELECT * FROM
> > category LEFT OUTER JOIN articlecategory ON category.id =
> > articlecategory.category_id
> > WHERE NOT
> > "category"."id" IN (
> >   SELECT U1."category_id"
> >   FROM "articlecategory" U1 INNER JOIN "article" U2 ON (U1."article_id" =
> > U2."id")
> >   WHERE
> >   (
> >   U2."status" = 'Archived'
> >   AND U1."category_id" IS NOT NULL
> >)
> > )
> >
> > The key problem here is that the ~Q() part negates whole big part of SQL
> > query, and instead of getting all categories with at least one not
> archived
> > article, I get all categories that have no archived articles! You must
> > agree, that it is not very unlikely that someone wants to query for sth
> like
> > this. I cannot use Q(__lt)|Q(__gt) becouse this is not integer. If status
> > was enumerated, I could select all values that are different than
> > "archived". But in this case I cannot do anything (except custom sql
> which
> > seems like overkill to such simple need).
> >
> > Adding not equal operator (say __ne) would allow to do this really
> simply:
> > Category.objects.filter(article_status__ne="archived")
> >
> > potentially resulting with query like this:
> > SELECT * FROM
> > category LEFT OUTER JOIN articlecategory ON category.id =
> > articlecategory.category_id
> > WHERE
> > "category"."id" IN (
> >   SELECT U1."category_id"
> >   FROM "articlecategory" U1 INNER JOIN "article" U2 ON (U1."article_id" =
> > U2."id")
> >   WHERE
> >   (
> >   U2."status" != 'Archived'
> >   AND U1."category_id" IS NOT NULL
> >)
> > )
> >
> > My question is why deny user such obvious usage of ORM?
> >
> > And btw, "not_in" would be really usefull too, argument the same, but I
> want
> > to exclude three statuses ("archived", "deleted" and "draft").
>
> Category.objects.exclude(article_status__in=[...])
>
>
> Cheers
>
> Tom
>
> --
> 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.
>
>


-- 
pozdrawiam,
Marek Brzóska

brzoskama...@gmail.com

-- 
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: Yet another __ne not equal discussion

[Tom Evans]

On Fri, Nov 30, 2012 at 1:29 PM, Marek Brzóska  wrote:
> Has the matter been completely put away?
>
> I would like to bring it up again.
>
> I have Articles and Categories. An Article belongs to Categories:
>
> class Category(model):
>   pass
> class Article(model):
>   category = ManyToManyField(Category)
>   status = CharField(max_length=10)
>
> Now I want all categories with articles that have status different than
> "archived".
>
> I cannot do this with django's ORM!
>
> Category.objects.filter(~Q(article_status="archived"))

What precisely is wrong with:

Category.objects.exclude(article_status='archived')

>
> will result in a query like this (simplified for readibility):
> SELECT * FROM
> category LEFT OUTER JOIN articlecategory ON category.id =
> articlecategory.category_id
> WHERE NOT
> "category"."id" IN (
>   SELECT U1."category_id"
>   FROM "articlecategory" U1 INNER JOIN "article" U2 ON (U1."article_id" =
> U2."id")
>   WHERE
>   (
>   U2."status" = 'Archived'
>   AND U1."category_id" IS NOT NULL
>)
> )
>
> The key problem here is that the ~Q() part negates whole big part of SQL
> query, and instead of getting all categories with at least one not archived
> article, I get all categories that have no archived articles! You must
> agree, that it is not very unlikely that someone wants to query for sth like
> this. I cannot use Q(__lt)|Q(__gt) becouse this is not integer. If status
> was enumerated, I could select all values that are different than
> "archived". But in this case I cannot do anything (except custom sql which
> seems like overkill to such simple need).
>
> Adding not equal operator (say __ne) would allow to do this really simply:
> Category.objects.filter(article_status__ne="archived")
>
> potentially resulting with query like this:
> SELECT * FROM
> category LEFT OUTER JOIN articlecategory ON category.id =
> articlecategory.category_id
> WHERE
> "category"."id" IN (
>   SELECT U1."category_id"
>   FROM "articlecategory" U1 INNER JOIN "article" U2 ON (U1."article_id" =
> U2."id")
>   WHERE
>   (
>   U2."status" != 'Archived'
>   AND U1."category_id" IS NOT NULL
>)
> )
>
> My question is why deny user such obvious usage of ORM?
>
> And btw, "not_in" would be really usefull too, argument the same, but I want
> to exclude three statuses ("archived", "deleted" and "draft").

Category.objects.exclude(article_status__in=[...])


Cheers

Tom

-- 
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: Admin Javascript Roadmap/Brainstorming

[Travis Swicegood]

On Nov 30, 2012, at 7:42 AM, Florian Apolloner  wrote:

> Hi Tyler,
> 
> On Wednesday, November 28, 2012 6:24:57 PM UTC+1, Tyler Ball wrote:
> - jQuery: Inlines are written as a jQuery plugin, DateTime and i18n are 
> written without jQuery. The version of jQuery included is 1.4.2, which is ~3 
> years old. Do we want to have jQuery in this project? I think Django should 
> include it, as it helps solve a lot of browser inconsistencies and is 
> familiar to all JS devs. But if so, we should try to keep it up to date.
> 
> Django namespaces it's jquery under django.jquery, there should be no issue 
> including an up2date version for your projects. Django probably will never 
> keep up with jquery's release cycle.

I can vouch for this.  It would be nice to keep it more up-to-date, but it is 
namespaced in a way that keeps it from bother other parts of the code that 
require a more modern version of jQuery.  I'm currently using 1.7.x in my admin 
alongside Django's jQuery 1.4 version.


>  - Not extensible: Behaviour for the jQuery plugins are defined in template 
> blocks which are somewhat easy to customize, while DateTimeShortcuts uses 
> href="javascript:void" links generated dynamically, which are nearly 
> impossible to override. I'd like to rewrite the Admin JS to use a Backbone 
> like structure, where all the necessary JS is initialized as an instance from 
> one place by calling `new` and a .extend() function can be used where the 
> developer wants to customize behaviour. This change would be pretty radical 
> but I feel it would be for the better.

Agreed that this code is not a good as it could be.  Having created a custom 
admin on top of admin_tools[1], I've come across a lot of pain points and have 
slowly (more slowly than I'd like) been refactoring bits of the admin JS into 
something that's more extensible.[2]

As for your actual idea, I'd have to see it to fully understand what you're 
proposing here.  Could you mock up some pseudo code that shows what you're 
trying to accomplish?  It doesn't need to be complex, just something that shows 
the order of execution using comments and what would be called.

-T

[1]: https://github.com/tswicegood/pops
[2]: 
https://github.com/django/django/commit/4754f122dd9b41fc9b2dee3fa74e19fc384237ab

-- 
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: Yet another __ne not equal discussion

[Marek Brzóska]

Has the matter been completely put away?

I would like to bring it up again.

I have Articles and Categories. An Article belongs to Categories:

class Category(model):
  pass
class Article(model):
  category = ManyToManyField(Category)
  status = CharField(max_length=10)

Now I want all categories with articles that have status different than 
"archived".

I cannot do this with django's ORM!

Category.objects.filter(~Q(article_status="archived"))

will result in a query like this (simplified for readibility):
SELECT * FROM
category LEFT OUTER JOIN articlecategory ON category.id = 
articlecategory.category_id
WHERE NOT 
"category"."id" IN (
  SELECT U1."category_id" 
  FROM "articlecategory" U1 INNER JOIN "article" U2 ON (U1."article_id" = 
U2."id") 
  WHERE 
  (
  U2."status" = 'Archived'
  AND U1."category_id" IS NOT NULL
   )
) 

The key problem here is that the ~Q() part negates whole big part of SQL 
query, and instead of getting all categories with at least one not archived 
article, I get all categories that have no archived articles! You must 
agree, that it is not very unlikely that someone wants to query for sth 
like this. I cannot use Q(__lt)|Q(__gt) becouse this is not integer. If 
status was enumerated, I could select all values that are different than 
"archived". But in this case I cannot do anything (except custom sql which 
seems like overkill to such simple need).

Adding not equal operator (say __ne) would allow to do this really simply: 
Category.objects.filter(article_status__ne="archived")

potentially resulting with query like this:
SELECT * FROM
category LEFT OUTER JOIN articlecategory ON category.id = 
articlecategory.category_id
WHERE
"category"."id" IN (
  SELECT U1."category_id" 
  FROM "articlecategory" U1 INNER JOIN "article" U2 ON (U1."article_id" = 
U2."id") 
  WHERE 
  (
  U2."status" != 'Archived'
  AND U1."category_id" IS NOT NULL
   )
) 

My question is why deny user such obvious usage of ORM?

And btw, "not_in" would be really usefull too, argument the same, but I 
want to exclude three statuses ("archived", "deleted" and "draft").

-- 
Marek Brzóska

-- 
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/-/CE4o-iujriQJ.
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: Admin Javascript Roadmap/Brainstorming

[Florian Apolloner]

Hi Tyler,

On Wednesday, November 28, 2012 6:24:57 PM UTC+1, Tyler Ball wrote:
>
> - jQuery: Inlines are written as a jQuery plugin, DateTime and i18n are 
> written without jQuery. The version of jQuery included is 1.4.2, which is 
> ~3 years old. Do we want to have jQuery in this project? I think Django 
> should include it, as it helps solve a lot of browser inconsistencies and 
> is familiar to all JS devs. But if so, we should try to keep it up to date.


Django namespaces it's jquery under django.jquery, there should be no issue 
including an up2date version for your projects. Django probably will never 
keep up with jquery's release cycle.
 

> - Not extensible: Behaviour for the jQuery plugins are defined in template 
> blocks which are somewhat easy to customize, while DateTimeShortcuts uses 
> href="javascript:void" links generated dynamically, which are nearly 
> impossible to override.
>

Independent of extensibility I think we have to get rid of javascript: urls 
and onclick handlers (see 
http://www.html5rocks.com/en/tutorials/security/content-security-policy/ as 
reference).

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/-/e-P4AQonO7gJ.
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: I'd like to make a contribution to the wiki

[Harry Percival]

Hi Russell, thanks for getting back to us. Here's our info:

Host: PythonAnywhere -- https://www.pythonanywhere.com
Flavor: uWSGI
Notes: Free, one-click Django setup. PythonAnywhere is a full cloud-based 
development environment, so as well as hosting your Django app, you can 
edit your code, run scripts, schedule tasks and manage your database, all 
through our browser-based tools. No need to install anything locally. No 
need to edit Apache / Nginx config files.
Lowest yearly payment: $0.00

Now, if you're updating the page, and you fancied having a new section, 
near the top say, called "Free Django Hosting", we'd be very happy to be 
listed under that ;-)  Otherwise, I guess we belong in "Django-Friendly Web 
Hosts"


If you fancied tidying up a few broken links, here are some I've found:

* Django Web Host Statistics
Both links - ("top 20 Most Popular Django Web Hosts") and ("Django Powered 
Sites")
are broken/retired. 

* Django-specific Web hosts
Slicehost -- now redirects to rackspace. Not Django-specific. Should be in 
VPS section.
UnicHost VPS -- not Django-specific, should be in VPS section
ServQC hosting -- not Django-specific, should be in VPS section
Kutoken -- 404
djangohosting.com.ua -- 404
10for10.com (Empowering Media) -- link spam site
highspeedrails.com -- 404
modulix.com -- 500
pythonicity.co.uk -- 404
www.thinkhost.com -- times out
Nail Technician Kit -- is actually about Nailcare. I see what you mean 
about spam!
Hosting on Demand -- Dead
PerfoHost -- holding page, other link 404s

* Django-friendly VPS/dedicated hosts
Bodhost - second link - http://www.bodhost.co.uk/dedicated-hosting.shtml -- 
404
FrameworkCloud -- 404
Perfohost -- as above, not apparently django hosting
Server Evolution -- 404










On Thursday, November 29, 2012 11:29:29 PM UTC, Russell Keith-Magee wrote:
Hi Harry,


That particular page has been locked down due to problems we've had with 
spam. If you let us know what you want to add, I can add an entry to the 
list on your behalf.


Yours,
Russ Magee %-)


On Tue, Nov 27, 2012 at 10:57 PM, Harry Percival 
 
wrote:

It's for promotional purposes really - I want to add my employers, 
PythonAnywhere, to the list of Django-Friendly-Web-Hosts


https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts


But it's not entirely one-sided and evil-marketing-spammy. We do offer 
Django hosting as part of our Free plan, so it's a nice place for people to 
come and try out Django, for free, maybe host a prototype web app...

I'd be very happy help out more generally, by, say, cleaning up that page, 
fixing/removing broken links (I found a few), etc...

I'd need WIKI_ADMIN privileges on the trac instance. my username is hjwp.

rgds,
Harry



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

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