Re: Strange behaviour with exclude / filter and a nullable FK

[Russell Keith-Magee]

On Wed, Sep 16, 2009 at 3:19 AM, Marcob  wrote:
>
> On Sep 15, 8:05 pm, Alex Gaynor  wrote:
>
>> This has already been filed as a bug in Django's ticket 
>> tracker:http://code.djangoproject.com/ticket/10790.  In the future please try
>> searching the tracker before filing a bug.
>
> Thanks Alex, but:
> 1) I searched the trac
> 2) I didn't find the bug
> 3) So before filing a dupe I wrote here
>
> Was I wrong?

Checking on the dev list before opening a ticket is the right thing to
do when you can't find a matching ticket on Trac and you're not sure
if you've actually found a bug.

However, it's usually a good idea to add a comment to your original
message that says "I've searched on Trac but can't find anything that
matches". This tells us that you have tried to do the right thing, so
it's a simple matter of an unsuccessful search, rather than someone
who has ignored the FAQ, etc.

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: Strange behaviour with exclude / filter and a nullable FK

[Marcob]

On Sep 15, 8:05 pm, Alex Gaynor  wrote:

> This has already been filed as a bug in Django's ticket 
> tracker:http://code.djangoproject.com/ticket/10790.  In the future please try
> searching the tracker before filing a bug.

Thanks Alex, but:
1) I searched the trac
2) I didn't find the bug
3) So before filing a dupe I wrote here

Was I wrong?

Ciao.
Marco.

--~--~-~--~~~---~--~~
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: Strange behaviour with exclude / filter and a nullable FK

[Alex Gaynor]

On Tue, Sep 15, 2009 at 1:58 PM, Marcob  wrote:
>
> On 15 Set, 19:32, Marcob  wrote:
>
>>     LEFT OUTER JOIN "auth_user" ON ("ticket_ticket"."assigned_id" =
>
> I translated from italian, obviously assigned_id should be
> assigned_to_id.
>
> Sorry.
>
> Ciao.
> Marco.
>
> >
>

This has already been filed as a bug in Django's ticket tracker:
http://code.djangoproject.com/ticket/10790.  In the future please try
searching the tracker before filing a bug.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~-~--~~~---~--~~
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: Strange behaviour with exclude / filter and a nullable FK

[Marcob]

On 15 Set, 19:32, Marcob  wrote:

>     LEFT OUTER JOIN "auth_user" ON ("ticket_ticket"."assigned_id" =

I translated from italian, obviously assigned_id should be
assigned_to_id.

Sorry.

Ciao.
Marco.

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

Can't use partial date format in settings.py

[Marcob]

Reading the following documentation I deduced that partial date
settings (used in date_hierarchy filter) could be set in settings.py:
http://docs.djangoproject.com/en/dev/ref/settings/#year-month-format
http://docs.djangoproject.com/en/dev/ref/settings/#month-day-format

Unfortunately the localization comes before settings as you can see
 :

from django.conf import settings
year_month_format = ugettext('YEAR_MONTH_FORMAT')
month_day_format = ugettext('MONTH_DAY_FORMAT')
if year_month_format == 'YEAR_MONTH_FORMAT':
year_month_format = settings.YEAR_MONTH_FORMAT
if month_day_format == 'MONTH_DAY_FORMAT':
month_day_format = settings.MONTH_DAY_FORMAT
return year_month_format, month_day_format

I solved with an ugly monkeypatching in one of my admin.py:
from django.utils import translation
from django.utils.translation import trans_null
translation.get_date_formats = trans_null.get_date_formats
translation.get_partial_date_formats =
trans_null.get_partial_date_formats

I think the documentation should state this clearly. Or at least a
special setting could tell Django if settings.py date formats has to
be used with priority.

Ciao.
Marco.

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

Strange behaviour with exclude / filter and a nullable FK

[Marcob]

I have a model with a FK on User table:
from django.contrib.auth.models import User

class Ticket(models.Model):
assigned_to = models.ForeignKey(User, null=True, blank=True)
...

Then I have these two querysets:
>>> q1 = Ticket.objects.filter(assigned_to__isnull=True)
>>> q2 = Ticket.objects.exclude(assigned_to__isnull=False)

I thought they shoud generate the same SQL query as they are
conceptually the same thing.

But if I print their query I got:
>>> print q1.query
SELECT ...
FROM "ticket_ticket"
LEFT OUTER JOIN "auth_user" ON ("ticket_ticket"."assigned_id" =
"auth_user"."id")
WHERE "auth_user"."id" IS NULL

>>> print q2.query
SELECT ...
FROM "ticket_ticket"
WHERE NOT ("ticket_ticket"."assigned_id" IS NOT NULL)

The exclude version is much more efficient.

Is this by design?

Ciao.
Marco.

--~--~-~--~~~---~--~~
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.contrib.markup and ReST

[Brett Parker]

On 15 Sep 02:26, Exe wrote:
> 
> Hello!
> 
> I tried "restructuredtext" filters. At first look it seems to work
> fine, but I found that section headers doesn't work.
> 
> After a while me constructed this patch. Please review and say if it
> possible to push it into upstream. Thank you for your attention.
> 
> $ svn diff
> Index: markup.py
> ===
> --- markup.py   (revision 11479)
> +++ markup.py   (working copy)
> @@ -86,7 +86,7 @@
>  else:
>  docutils_settings = getattr(settings,
> "RESTRUCTUREDTEXT_FILTER_SETTINGS", {})
>  parts = publish_parts(source=smart_str(value),
> writer_name="html4css1", settings_overrides=docutils_settings)
> -return mark_safe(force_unicode(parts["fragment"]))
> +return mark_safe(force_unicode(parts["html_body"]))
>  restructuredtext.is_safe = True
> 
>  register.filter(textile)

What isn't working with section headers? They seem to be working fine in
the cases that I use them...

Can you give an ReST example that is failing to render correctly?

Thanks,
-- 
Brett Parker

--~--~-~--~~~---~--~~
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: CSRF proposal and patch ready for review

[Luke Plant]

On Tuesday 15 September 2009 12:28:51 Russell Keith-Magee wrote:

> The CSRF tag approach you have implemented didn't win a lot of fans
> whenever I described it, and for pretty much the same reasons I have
> expressed previously - too many moving parts, and a little too much
> manual intervention required.
> 
> The discussions I had with Simon and Andrew revolved around trying to
> improve the interface to SafeForm, and I think we may have a workable
> solution. I've only just arrived home, so I'm fairly jet lagged at the
> moment; I'll try to put the result of our discussions into the form of
> a formal proposal over the next day or so.

OK, I'll wait and see. 

To clear things up, the template tag approach really has just two 'moving 
parts':
 - use RequestContext in your view (often you will be covered already e.g. 
   generic views, and lots of people already using RequestContext everywhere)
 - use the csrf tag in the template.

Everything else is global settings i.e. a one time change, which you will be 
prompted about *once* if you forget them, and then you can forget them.

I'd be very surprised if SafeForm was a better result - it has major flaws 
that can't be addressed by API changes, AFAIC:

 * it requires using Django's form system.  I've got plenty of views that 
don't (e.g. anything with a dynamic number of controls).  People not using 
django.Forms are left out in the cold, or having to learn another way to do 
things.

 * it's off by default.  Turning it on by default will require making 
django.forms.Form subclass SafeForm, which will almost certainly require a 
huge and immediate upgrade effort, because SafeForm cannot have the same API 
as Form.  If it's off by default, I see no point at all in this entire 
exercise.  If we don't arrive at a point where the POST form created in the 
tutorial is safe from CSRF, I think we've failed.

And it will still require changes to templates, just like the template tag, 
and it will also require changes to views, only significantly more complex   
than simply using RequestContext.  It's got at least as many and at least as 
intrusive 'moving parts' AFAICS.

It also has the disadvantage that it is much more intrusive - you can't just 
switch out the implementation of your CSRF protection mechanism like you can 
with the template tag and middleware.

But I'll wait 'til I see your proposal.

Luke

-- 
"My capacity for happiness you could fit into a matchbox without 
taking out the matches first." (Marvin the paranoid android)

Luke Plant || http://lukeplant.me.uk/

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

django.contrib.markup and ReST

[Exe]

Hello!

I tried "restructuredtext" filters. At first look it seems to work
fine, but I found that section headers doesn't work.

After a while me constructed this patch. Please review and say if it
possible to push it into upstream. Thank you for your attention.

$ svn diff
Index: markup.py
===
--- markup.py   (revision 11479)
+++ markup.py   (working copy)
@@ -86,7 +86,7 @@
 else:
 docutils_settings = getattr(settings,
"RESTRUCTUREDTEXT_FILTER_SETTINGS", {})
 parts = publish_parts(source=smart_str(value),
writer_name="html4css1", settings_overrides=docutils_settings)
-return mark_safe(force_unicode(parts["fragment"]))
+return mark_safe(force_unicode(parts["html_body"]))
 restructuredtext.is_safe = True

 register.filter(textile)

--~--~-~--~~~---~--~~
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: CSRF proposal and patch ready for review

[Russell Keith-Magee]

On Mon, Sep 14, 2009 at 9:05 PM, Luke Plant  wrote:
>
> On Monday 31 August 2009 15:26:42 Russell Keith-Magee wrote:
>
>>  3. CSRF is currently a contrib app. Why? CSRF control is the very
>> model of a feature that shouldn't be decoupled from the base
>> framework. If we're aiming to make CSRF support like XSS support,
>> surely it should be baked into the core, not kept isolated as a
>> contrib app. Is there anything else that gets easier if we sink this
>> into the core? At the very least, the tag loading issues go away - are
>> there other possible benefits?
>
> For the sake of recording my thoughts, one advantage of keeping it as a
> contrib app is that developers can completely replace the CSRF mechanism if
> they don't like the bundled one.  Simply by doing
> s/django.contrib.csrf/thirdparty.csrf/ to their INSTALLED_APPS,
> MIDDLEWARE_CLASSES and TEMPLATE_CONTEXT_PROCESSROS settings,
> they would replace the CSRF mechanism (including the templatetag library) with
> their own.  Their own {% csrf_token %} might return an empty string (e.g. if
> they were just using Referer checking or Origin checking or something), but
> that's fine.  The admin and all other apps would then seamlessly use the
> different CSRF mechanism.
>
> So keeping it as contrib and not in core might be an advantage if some
> websites have special requirements, or the bundled CSRF mechanism becomes
> outdated.

FYI, Simon, Andrew Godwin and myself had a chance to chat about CSRF
during the DjangoCon sprints. I also discussed the issue with a few
other people over the conference.

The CSRF tag approach you have implemented didn't win a lot of fans
whenever I described it, and for pretty much the same reasons I have
expressed previously - too many moving parts, and a little too much
manual intervention required.

The discussions I had with Simon and Andrew revolved around trying to
improve the interface to SafeForm, and I think we may have a workable
solution. I've only just arrived home, so I'm fairly jet lagged at the
moment; I'll try to put the result of our discussions into the form of
a formal proposal over the next day or so.

Yours,
Russ %-)

--~--~-~--~~~---~--~~
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: Replacing get_absolute_url, I am against it

[Ivan Sagalaev]

James Bennett wrote:
> Except I can't help thinking this is an awfully arbitrary distinction
> to draw. In effect you're saying that nearly every question about an
> object should be answerable by interrogating it directly, *except* for
> "what's a URL I can use for you?"

May be I can explain this distinction with an example.

We once had two different web sites about "events". They both had a 
"core" set of models but each one had their own set of views & urls. So 
for a core Event model a question "what's your URL" just didn't make 
sense. It had two different URLs depending on the project it was 
imported in.

That said, I do see a value in having a default URL (and a default 
__unicode__ for that matter) simply because it's useful in many (or even 
majority?) of real-world cases.

So Yuri, Patrick, this method is optional so there's not technical need 
to deprecate it. This discussion really is about how it should be done, 
not if.

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