Questions about ticket #19431

2013-05-16 Thread Pablo Recio
Hi guys,

Some months ago I submitted a pull
request<https://github.com/django/django/pull/589> for
the ticket #19431 <https://code.djangoproject.com/ticket/19431>. Even it's
a really small thing, didn't get the time until now (DjangoCon, yay!) to go
through last of Florian's reviews.

How should I tackle that? My initial thought was to use `settings.
DATETIME_INPUT_FORMATS`
for picking wich format the admin should accept. And as far as I know, the
activated locale will put the local formats in the top of that list, so
they will be picked first.

Shall I maybe add more tests covering the locale thing? Or shall I use just
ISO-format strings?

Thanks,

-- 
Pablo Recio

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.




Making ".only()" a bit smarter

2013-07-19 Thread Pablo Recio
Hi devs,

I just came up with the following scenario:

class A(models.Model):
# some fields...
b = models.ForeignKey(B)

class B(models.Model):
# other fields

A simple FK relationship. Well, then I wanted to fetch objects from 'A'
model but just for retrieve the related 'B', so I tried something like:

A.objects.only('b').all()

I hoped it was going to be smart enough to check that I'm accessing to FK
and then do 'select_related' for that field behind the scenes, but it
doesn't, so I needed to chain the select_related myself.

Is there any reason for this behaviour? If not, would it be a good patch to
submit?

Thanks,

-- 
Pablo Recio

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




Re: Making ".only()" a bit smarter

2013-07-23 Thread Pablo Recio
Yeah, you might be right. It just feels weird that if I'm trying to fetch
*only* a FK, it needs to do a second lookup. But explicit is better than
implicit indeed.


On 19 July 2013 21:48, Michal Petrucha  wrote:

> On Fri, Jul 19, 2013 at 01:02:34PM +0100, Pablo Recio wrote:
> > Hi devs,
> >
> > I just came up with the following scenario:
> >
> > class A(models.Model):
> > # some fields...
> > b = models.ForeignKey(B)
> >
> > class B(models.Model):
> > # other fields
> >
> > A simple FK relationship. Well, then I wanted to fetch objects from 'A'
> > model but just for retrieve the related 'B', so I tried something like:
> >
> > A.objects.only('b').all()
> >
> > I hoped it was going to be smart enough to check that I'm accessing to FK
> > and then do 'select_related' for that field behind the scenes, but it
> > doesn't, so I needed to chain the select_related myself.
> >
> > Is there any reason for this behaviour? If not, would it be a good patch
> to
> > submit?
>
> Explicit is better than implicit. Also, special cases aren't special
> enough to break the rules.
>
> To me, what you propose seems too arbitrary. `only` would do what it
> says it does, that is, defer everything but the selected fields,
> except for the special case where you restrict the query to a single
> ForeignKey, in which case it would also do a `select_related` -- that
> sounds like a quite specific special case.
>
> Also, what would you propose to happen in case you do `defer` on all
> fields except one ForeignKey? Would that do the same thing as the
> equivalent `only` or not? Why?
>
> In other words, I don't think it is worth complicating the API in this
> way just to save a single method call on a QuerySet.
>
> Michal
>



-- 
Pablo Recio Quijano

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




New `pre_handler()` method on Class-Based Views

2016-04-03 Thread Pablo Recio
Hey there,

Wanted to share an idea I had during some discussions in DjangoCon EU. When 
using CBV, sometimes we have to replicate behaviour between different 
handlers. For instance setting up certain objects, extra user checks... 
Normally the way to achieve this is to override the `dispatch()`, but it's 
a bit error-prone and doesn't feel too clean sometimes.

So I wrote a little piece of code that adds a `pre_handler()` method that 
gets called before the handler method, whatever that is. Here is the 
code: https://github.com/pablorecio/django/tree/pre-handler-view-method, if 
it's something that would get merged I'll happily submit a PR.

Thanks!
Pablo Recio


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/df0c7703-b496-4bfa-ad31-68b35be482fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Ticket 19237

2013-02-04 Thread Pablo Recio Quijano
Hi,

Trying out Django 1.5 with one of my projects, I ran out with a bug dealing 
with this ticket, so I reopened 
it: https://code.djangoproject.com/ticket/19237#comment:14

I think that bug should be blocker, because in a normal case can remove a 
lot of information when executing a strip_tags method.

Cheers,

On Saturday, 17 November 2012 09:01:33 UTC, Chris Khoo wrote:
>
> Hi
>
> I was wondering if one of the core developers could have a look at ticket 
> #19237 and progress it forward - 
> https://code.djangoproject.com/ticket/19237
>
> It basically makes django.utils.html.strip_tags a little smarter.
>
> Thanks
>
> Chris
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.