Re: Papal module configuration in SATCHMO module

[Russell Keith-Magee]

On Fri, Oct 29, 2010 at 1:47 PM, Tariq Mahmood  wrote:
> Assalam O Alaikum
>
> when i click for purchase item from my store following error appears.
> please tell me what is the problem. is it any problem with satchmo
> paypal module configuration

Django-developers is for discussing the development of Django itself.

If you're having a problem with Django, please ask on Django-users. In
your case, you may also want to see out the support forums for Satchmo
itself.

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

Papal module configuration in SATCHMO module

[Tariq Mahmood]

Assalam O Alaikum

when i click for purchase item from my store following error appears.
please tell me what is the problem. is it any problem with satchmo
paypal module configuration

ERROR AT PAYPAL SAND BOX SITE

We cannot process this transaction because there is a problem with the
PayPal email address supplied by the seller. Please contact the seller
to resolve the problem. If this payment is for an eBay listing, you
can contact the seller via the "Ask Seller a Question" link on the
listing page. When you have the correct email address, payment can be
made at www.paypal.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-develop...@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: Gentle Proposal: add 'render' shortcut in 1.3

[Russell Keith-Magee]

2010/10/29 Mikhail Korobov :
> Hi Russel,
>
> Thank you for your reviews and moving things on!
>
> On 29 окт, 07:35, Russell Keith-Magee  wrote:
>>
>> I like this idea -- it's is an elegant solution to the problem, and
>> avoids all the backwards compatibility issues I can think of.
>>
>> I have two comments:
>>
>> Firstly, there needs to be a shortcut for non-template responses. If
>> your response isn't a template response, there's no point putting it
>> through Template Reponse Middleware.
>>
>
> Ivan's code doesn't put non-template responses through template
> response middleware. Whenever the response is a template response is
> determined by the presence of 'force_bake' method.

Ah - I wasn't aware there was a working implementation of this idea --
did I miss a link somewhere?

>> Secondly, it seems to me like there may be some need for baking
>> protection here. If any template-response-middleware were to bake the
>> response, subsequent template-reposnse-middlewares could potentially
>> have problems, as any changes they make to context etc will be
>> ignored. Wouldn't it make sense to put a flag on the TemplateResponse
>> that prohibits accidental baking? That way the force_bake() that
>> happens between the template-response-middleware and the normal
>> response-middleware would be the guaranteed point at which the
>> template is writ large as content.
>>
>
> As I can see, users shouldn't bake responses not only in middlewares.
> They shouldn't bake responses anywhere in their code.
>
> The original TemplateResponse idea was not the same.

Agreed. This is a change from the original completely-lazy-evaluated
TemplateResponse idea, but I think it makes sense in terms of being
explicit and avoiding a wealth of potential bugs in implicit
evaluation.

> So maybe it will be better not to make bake/force_bake public so that
> users won't be able to shoot themselves in the foot? And maybe it'll
> be better even not to bake response magically on first content
> access?

That's essentially what I was suggesting -- that if a middleware or
decorator accidental accessed response.content before the end of
template-context-processor handling (when the explicit baking occurs),
it should raise an exception rather than implicitly baking the
response.

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-develop...@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: contrib.staticfiles and runserver

[Carl Meyer]

On Oct 28, 9:45 pm, SmileyChris  wrote:
> My suggestion is that StaticFilesHandler only does its magic if
> 'django.contrib.staticfiles' is found in INSTALLED_APPS. Does that
> sound acceptable?

That seems like a very reasonable opt-in approach that solves the
backwards-compatibility problem. +1

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: contrib.staticfiles app concerns

[Carl Meyer]

Hi Waldemar,

Thanks for putting so much thought into this issue, and outlining
these options in detail. However, I am not convinced that this
something Django core should be concerned with. I think we need to
maintain a clearer conceptual separation between the various layers of
functionality here.

As I read it, your option 4 means putting URLs into CSS files that
will not resolve correctly if static files are served directly,
unmodified, from their source locations (after being collected from
apps) under STATICFILES_URL (because the URLs you give don't begin
with a slash, so they will be interpreted as relative to the current
location; and if they did begin with a slash, that would break anytime
STATICFILES_URL is not a path-less domain). In other words, you are
proposing to write CSS files that _depend_ on being run through some
kind of combiner/compressor/filter that will intelligently rewrite all
their URLs relative to STATICFILES_URL. As a proposal for a
"standard," this is a non-starter for several reasons:

1. Not all projects want or need to combine/compress their media at
all, and there is no reason they should have to run their CSS through
a URL-rewriting filter.
2. Even in projects that do combine/compress media, there are good
reasons to want to serve the individual files directly in development
(to aid in front-end debugging), and only do the combining/compressing
step on deployment to staging/production.
3. Designers and front-end developers working on Django projects
should not have to learn some odd way of linking in their CSS, that
appears to be wrong according to everything they know about how things
usually work. The links they write should make sense to them, not just
to some Python developer who invented a new "standard" for them.
4. Django does not provide any built-in tools to combine, compress, or
rewrite links in media, so it is certainly not going to adopt a
"standard" that requires the use of such a tool.

In other words, the only reason a "standard" would even be needed here
is because you want to establish a new standard which makes the source
CSS files unusable in the absence of a filter which implements the
standard!

I think the problem here is a desire to conflate multiple issues which
are clearer when considered separately. To wit:

1. Links in static files should be written in such a way they work as-
is, without knowing what root URL they will be served under (this
means relative internal links).
2. Any third-party tool that combines/compresses CSS should be able to
take working input files and generate working output files, handling
whatever internal links it finds correctly.

Both of these seem almost so obvious that they shouldn't require
stating at all; you'll also note that they keep the question of
internal linkage neatly separated from the presence or absence of a
hypothetical compressor/combiner.

The only argument you present against this approach is that it's
problematic for Sass; considering all of my projects use Sass, I
disagree.  It simply requires the Sass author to understand the tool
they are using and know how imports and paths work (or use a Sass
framework such as Compass, which already handles the problem neatly).
This is the nature of Sass, is second-nature to any experienced Sass
author, and is in no way specific to Django; there's no reason for
Django to be providing a solution for it.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: More efficient negative lookups

[Russell Keith-Magee]

On Thu, Oct 28, 2010 at 6:59 AM, George Vilches  wrote:
>
>
> On Oct 27, 5:55 pm, Jacob Kaplan-Moss  wrote:
>> On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty  wrote:
>> > I'm inclined to say we do the former -- restore the "ne" lookup type
>> > -- because it's a quick fix, and ask somebody to write up a patch for
>> > the latter. Does anybody have strong opinions against this? If not, I
>> > can restore the "ne" lookup type.
>>
>> Sounds like a good plan to me (especially making simple excludes faster).
>>
>> However, just for the record I think the reason we decided to remove
>> __ne is the first place was that its existence introduces a weird
>> inconsistency with regard to other lookup types. That is, if there's a
>> "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down
>> that path lies madness so I'm +0 on bringing back "ne" with the
>> proviso that we agree it's not the first step down a slippery slope
>> towards "nistartswith" and friends.
>
> I know it's been a little while since I've made any major ORM
> contributions, but I'd say -0 on __ne, and +1 on making exclude
> generate better code.  Django's worked far too hard on making things
> consistent as possible to let like this slip by just because we don't
> want to muddy our hands with a little harder work in the exclude()
> code.

I agree. We should certainly fix the behavior of exclude(), but
reintroducing __ne feels like the start of a slippery slope to me.
Conceptually, I'm -1 on reintroducing __ne.

In the interests of practicality, I'd be willing to reconsider if it
turns out that fixing exclude() is prohibitively complex. However, it
seems premature to reintroduce __ne as a stop-gap measure before
anyone has taken a serious look at what is involved with fixing
exclude(). We still have almost 3 months until the freeze for 1.3;
that should be plenty of time to investigate exactly how much work
would be involved in fixing this bug properly.

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-develop...@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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Hi Russel,

Thank you for your reviews and moving things on!

On 29 окт, 07:35, Russell Keith-Magee  wrote:
>
> I like this idea -- it's is an elegant solution to the problem, and
> avoids all the backwards compatibility issues I can think of.
>
> I have two comments:
>
> Firstly, there needs to be a shortcut for non-template responses. If
> your response isn't a template response, there's no point putting it
> through Template Reponse Middleware.
>

Ivan's code doesn't put non-template responses through template
response middleware. Whenever the response is a template response is
determined by the presence of 'force_bake' method.

> Secondly, it seems to me like there may be some need for baking
> protection here. If any template-response-middleware were to bake the
> response, subsequent template-reposnse-middlewares could potentially
> have problems, as any changes they make to context etc will be
> ignored. Wouldn't it make sense to put a flag on the TemplateResponse
> that prohibits accidental baking? That way the force_bake() that
> happens between the template-response-middleware and the normal
> response-middleware would be the guaranteed point at which the
> template is writ large as content.
>

As I can see, users shouldn't bake responses not only in middlewares.
They shouldn't bake responses anywhere in their code.

The original TemplateResponse idea was not the same.

Original TemplateResponse was baked on first content access. Now
TemplateResponse should be baked exactly in one place: right after
template response middlewares. Other baking points seems to be error-
prone with this solution.

So maybe it will be better not to make bake/force_bake public so that
users won't be able to shoot themselves in the foot? And maybe it'll
be better even not to bake response magically on first content
access?

> Regarding #9886 and #14523 -- they're both RFC, and they're on my todo
> list of things to commit in the near future. I just need to find a few
> spare moments to give the patches a final review and commit.
>
> Yours,
> Russ Magee %-)

That's great!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: contrib.staticfiles and runserver

[Russell Keith-Magee]

On Fri, Oct 29, 2010 at 9:45 AM, SmileyChris  wrote:
> It's cool that runserver takes away the hassle of needing to add in
> your static url (is this documented? I didn't find it in my skim) but
> doing it by default seems pretty backwards incompatible, even if we
> are just talking about the dev server.
>
> My suggestion is that StaticFilesHandler only does its magic if
> 'django.contrib.staticfiles' is found in INSTALLED_APPS. Does that
> sound acceptable?

A related ticket: http://code.djangoproject.com/ticket/14582

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-develop...@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: contrib.staticfiles and runserver

[SmileyChris]

On Oct 29, 2:45 pm, SmileyChris  wrote:
> doing it by default seems pretty backwards incompatible, even if we

I was a bit terse, let me expand.
STATICFILES_URL defaults to '/static/'. The StaticFilesHandler (which
is now what is used by runserver) swallows requests to this url.

Yeah, that's about it. Easy to solve for my case (since I was just
using django-staticfiles anyway, I just needed to set
STATICFILES_DIRS) but still was a few minutes of head-scratching as to
what was going wrong.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: It is real to add ticket #8054 to 1.3 milestone?

[Russell Keith-Magee]

On Thu, Oct 28, 2010 at 3:04 PM, Alex Kamedov  wrote:
> Hi All. Big thanks to response!
>>
>> > Am I correct and the goal is only to change list_display syntax?
>> Yes, I don't see any other goal either, so I have controversial
>> feelings about the issue.
>> It has only syntax sugar, but that sugar is very sweet.
>
> Hm. Yes, it provide only syntax sugar. But very often it'll be more easiest
> way to customize admin (Eg.: apply template tags to model fields and
> existing model methods).

... which is something you can already do with a callable column::

class MyModelAdmin(ModelAdmin):
   def formatted_foobar(self, obj):
   return slugify(truncatewords(obj.foobar, 2))

list_display = ('formatted_foobar', 'name', 'age')

with the added benefit that you can do a lot more that just applying a
template filter -- to pick a trivial example, you could conditionally
apply *different* template filters, depending on the value of the
attribute.

Honestly, I can't see the benefit in what you're proposing here.
Before you spend a whole lot more time updating the patch to try and
make and keep it trunk ready, you need to convince me (or another
member of the core team) that the idea you're proposing is worth
adding to trunk. Otherwise you're just going to be spending a lot of
time maintaining a patch that won't ever get committed.

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

contrib.staticfiles and runserver

[SmileyChris]

It's cool that runserver takes away the hassle of needing to add in
your static url (is this documented? I didn't find it in my skim) but
doing it by default seems pretty backwards incompatible, even if we
are just talking about the dev server.

My suggestion is that StaticFilesHandler only does its magic if
'django.contrib.staticfiles' is found in INSTALLED_APPS. Does that
sound acceptable?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Gentle Proposal: add 'render' shortcut in 1.3

[Russell Keith-Magee]

On Thu, Oct 28, 2010 at 2:55 PM, Ivan Sagalaev
 wrote:
> On 10/27/2010 04:55 PM, Mikhail Korobov wrote:
>>
>> 1. 'Border' middleware is a backwards-compatible change, the
>> requirement to bake response in middleware isn't.
>>
>> The
>> difference is only that you propose to execute 'bake' in the end of
>> response cycle and I propose to execute it at the beginning of the
>> response cycle but to make this customizable (by changing the position
>> of the BakingMiddleware).
>
> I understand your points now, thanks. Two things bother me about 'border'
> middleware:
>
> - its semantics is a bit different than that of others middleware in the
> list in settings and this difference is not explicitly clear when looking at
> the list
>
> - it's bad to have a boilerplate code that people just have to put somewhere
>
> I've spent a night with a thought and now I think I can propose even better
> solution.
>
> We can introduce a new kind of middleware — "template response middleware"
> for lack of a better name. A user who wants to do something with a template
> response *before* it is baked has to write a middleware like this:
>
>    class ContextInjectionMiddleware:
>        def process_template_response(self, request, response):
>            # do something with response
>
> Request handling code would look like this then:
>
>    response = get_response(...)
>
>    if hastattr(response, 'force_bake'):
>        # apply template response middleware
>        response.force_bake()
>
>    # apply normal response middleware
>
> This way we:
>
> - are getting rid of force_bake in HttpResponse where it's a noop
> - maintain backward compatibility since response is baked before all
> currently written middleware
> - require explicitly named method to deal with a new concept
>
> What's not to like? :-)

I like this idea -- it's is an elegant solution to the problem, and
avoids all the backwards compatibility issues I can think of.

I have two comments:

Firstly, there needs to be a shortcut for non-template responses. If
your response isn't a template response, there's no point putting it
through Template Reponse Middleware.

Secondly, it seems to me like there may be some need for baking
protection here. If any template-response-middleware were to bake the
response, subsequent template-reposnse-middlewares could potentially
have problems, as any changes they make to context etc will be
ignored. Wouldn't it make sense to put a flag on the TemplateResponse
that prohibits accidental baking? That way the force_bake() that
happens between the template-response-middleware and the normal
response-middleware would be the guaranteed point at which the
template is writ large as content.

Regarding #9886 and #14523 -- they're both RFC, and they're on my todo
list of things to commit in the near future. I just need to find a few
spare moments to give the patches a final review and commit.

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-develop...@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: Ticket #7817: Extending "with" and "include" tags.

[Russell Keith-Magee]

On Wed, Oct 27, 2010 at 3:46 PM, SmileyChris  wrote:
> On Oct 27, 5:35 am, Łukasz Rekucki  wrote:
>> I would like to bring this up again, because this is something that
>> would really improve readability of my templates. I'm mainly
>> interested in ticket #7817 (the include tag changes), but extending
>> "with" tag (ticket 9456) would keep things consistent.
>
> Here's a link to the ticket for the lazier ones among us:
> http://code.djangoproject.com/ticket/7817
>
> The main decision which needs to be made is one of syntax.
>
> The current proposal uses:
> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
> but this introduces an inconsistency with the {% with %} tag.
>
> Consistency would be nice, but I think this starts to look a bit
> confusing, static tokens outnumbering actual functional ones:
> {% include "name_snippet.html" with name as "Joe" and greeting as
> "Hello" %}
>
> My proposal is that the current {% with name as "Joe" %} format
> becomes the legacy format, and that the new format becomes (also
> allowing for multiple arguments):
> {% with name="Joe" greeting="Hello" %}
>
> Other tags which currently use the "as" token are: cycle, regroup and
> url. These all introduce a new variable into the current context,
> which does differ slightly from how {% with %} alters a variable in a
> contained scope. So my secondary (perhaps somewhat feeble) argument is
> that this actually helps to keep the "as" token's behaviour more
> consistent. :)
>
> Thoughts?

Repeating what I said to Chris in IRC for the benefit of posterity:

I don't have any strong preference either way, but whatever style we
pick, we need to be consistent.

I can certainly appreciate the clarity and terseness of the "foo=bar
pork=ham" syntax. My only concern would be whether it is too
"programmery" for the intended audience of the template language. We
have existing uses of the 'x=y' syntax -- such as in the {% url %}
tag, so I don't think this should be a major concern.

As David points out, the fact that {% blocktrans %} already does 'with
X as Y and A as B' would seem to set a precedent for the verbose
syntax. This verbose syntax is also syntactically consistent with what
the {% with %} tag already does, so there's no need to introduce a
'legacy' format.

I could swing either way on this. If we were starting with a clean
slate, I'd prefer the terse syntax, and I think Chris provides a
reasonable argument for how the usage of 'as' can be explained
conceptually. However, the legacy issue and the precendent set by {%
blocktrans %} provides a compelling argument to use the more verbose
syntax.

If we can introduce the terse syntax while maintaining the old syntax
(including the analogous change in  blocktrans), I think it would be a
worthwhile change. However, I certainly won't complain if public
opinion sways the other way.

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-develop...@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: New localflavor: Turkey

[Russell Keith-Magee]

On Thu, Oct 28, 2010 at 8:35 PM, Ekrem SEREN  wrote:
> 2010/10/28 Serkan Kenar 
>>> Thirdly, the patch needs verification by a third party, preferably
>> I think we have to wait for somebody to raise his/her hand here. I don't 
>> know anybody else in the community who is familiar with Turkish.
>
> I believe I can test this. I just need a little help about the patch.
>
> What's the proper way to apply and test the patch?

In the root of your django source directory, run:

patch -p0 < /path/to/the/patch/file.diff

This will apply the patch to your Django checkout; you can then run
the Django system tests; in the tests directory, run:

python runtests.py --settings=test_sqlite forms

See [1] for more details on running the test suite.

[1] 
http://docs.djangoproject.com/en/dev/internals/contributing/#running-the-unit-tests

This will validate that the tests run without error; however, we need
more than this as part of a review. What we really need is someone
with Turkish knowledge to validate that the code and tests are doing
the right thing. So, in the case of this patch:

 1) Is the list of provinces complete and correct?
 2) Is the use of integers the best key for this list? i.e., is there
a better natural key, like US state abbreviations?
 3) Does the postal code field accurately capture all possible Turkish
postal codes?
 4) Does the phone number field accurately capture all possible
Turkish phone numbers?
 5) Does the id number field accurately capture and validate all
possible Turkish ID numbers?
 6) Do the provided tests contain enough examples to validate that 3-6
are correct?

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-develop...@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: Custum permission bug

[Russell Keith-Magee]

On Thu, Oct 28, 2010 at 8:12 PM, Narciso Oceguera  wrote:
> Hi, everyone.
>
> As documentation said, I just added the lines:
>
> class USCitizen(models.Model):
>   # ...
>
>   class Meta:
>       permissions = (
>           ("can_drive", "Can drive"),
>           ("can_vote", "Can vote in elections"),
>           ("can_drink", "Can drink alcohol"),
>       )
>
> But after executing:          manage.py syncdb
> I can't get my custom permission added in the permission table. I think this
> is a bug because the permissions was not found in
> model._meta.permission attribute ( opts.permissions ) as the signals
> (syncdb) expect. These
> permission were added to the model object itself.

I can't reproduce your problem. The model you provided synchronizes
fine for me, and permissions are added as expected.

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-develop...@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: Feature request: ForeignKey through parameter

[Adrian Holovaty]

On Thu, Oct 28, 2010 at 2:54 AM, Roald de Vries  wrote:
> I quite often reference foreign keys of foreign keys of foreign keys...
> Wouldn't it be nice to have a 'through'-parameter for ForeignKey's?
>
>    class A(Model):
>        b = ForeignKey('B')
>        c = ForeignKey('C', through='B', related_name='a_set')
>
>    class B(Model):
>        c = ForeignKey('C')
>
>
> The advantages of a field A.c wrt a property A.c:
> - it creates a reverse relation, so C.a_set becomes available
> - c becomes queryable: A.objects.filter(c=x)

Hi Roald,

Thanks for suggesting this. I don't think it's worth implementing,
though, because you can already query across multiple foreign-key
relationships like this:

A.objects.filter(b__c__exact=x)

As for making C.a_set available, I'd suggest just doing
A.objects.filter(b__c__exact=c_instance) in your view, and that'll get
the job done.

Adrian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Feature request: ForeignKey through parameter

[Javier Guerra Giraldez]

On Thu, Oct 28, 2010 at 9:15 AM, Roald de Vries  wrote:
> On first sight, I think I agree with you that the syntax is cleaner like
> this, but I would choose for the through-parameter because it's more
> consistent with the use of the through-parameter for ManyToManyField.

but what if B has more than one ForeignKey('C') fields?

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Google Code-in: any volunteers?

[Alex Gaynor]

Hey all,

After speaking with Jacob I've put together our application.  One of
the components of which is having a list of tasks for students.  The
application is due tomorrow, so there isn't a ton of time, but I've
started a wikipage where people can suggest ideas, so if you have
anything that you think fits please feel free to add it:
http://code.djangoproject.com/wiki/GoogleCodeIn2010.

Thanks,
Alex

On Thu, Oct 7, 2010 at 5:44 PM, Steven Elliott Jr
 wrote:
> I'd be interested in helping out as well In any way I can. I'm a technical 
> writer/editor by day so if there is a need for someone to oversee or assist 
> with documentation I'd be delighted. Of course I'm willing to help out on 
> anything.
>
> Best,
> Steve
>
> Sent from my iPhone
>
> On Oct 7, 2010, at 4:15 PM, Marco Chomut  wrote:
>
>> I'd definitely be up for helping out with this.
>>
>> - Marco
>>
>> On Oct 7, 3:36 pm, Shawn Davis  wrote:
>>> I can participate if it's "several someones", but I'm afraid my schedule is 
>>> too full to do it solo.
>>>
>>> thanks,
>>> Shawn
>>>
>>> On Oct 7, 2010, at 5:30 PM, Jacob Kaplan-Moss wrote:
>>>
>>>
>>>
 Hi folks --
>>>
 Google's open source team is putting together a new program, called
 "Google Code-in". It's a program to get 13-18 years old students
 involved in open source by giving them sets of small, distinct tasks
 to work on. They did a similar program last year, called GHOP; Django
 didn't participate, but Python did.
>>>
 This might be a good way for us to get more younger developers
 involved, and we might be able to get some good work done --
 especially in the areas of documentation and testing.
>>>
 Though we didn't participate last year, Python did, and from what I
 hear it was successful, though a good deal of work. I don't have time
 myself to administer something like this this year, but I would love
 to see Django participate. Does anyone -- or several someones -- here
 think this sounds interesting enough to want to administer it from our
 end? I would be happy to help out in a supporting role, but there'd
 need to be someone else who's driving it.
>>>
 If you want to know more:
>>>
 http://google-opensource.blogspot.com/2010/10/google-code-in-schools-...
 http://code.google.com/opensource/gci/2010-11/faqs.html
>>>
 Thanks!
>>>
 Jacob
>>>
 --
 You received this message because you are subscribed to the Google Groups 
 "Django developers" group.
 To post to this group, send email to django-develop...@googlegroups.com.
 To unsubscribe from this group, send email to 
 django-developers+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://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-develop...@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-develop...@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.
>
>



-- 
"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-develop...@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: Gentle Proposal: add 'render' shortcut in 1.3

[Ivan Sagalaev]

On 10/28/2010 12:24 PM, Mikhail Korobov wrote:

The request handling code have to be put into WSGIHandler and into
ModPythonHandler so I'll wait until the patch for 
http://code.djangoproject.com/ticket/9886
will be landed.


I'd say it's even worth to wait for 
http://code.djangoproject.com/ticket/14523 that moves response 
middleware application into the base code.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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: contrib.staticfiles app concerns

[Waldemar Kornewald]

On Thu, Oct 28, 2010 at 4:41 PM, Waldemar Kornewald
 wrote:
> What's the problem with all of this? Code written for (1) is
> incompatible with code written for (2) which is incompatible with code
> written for (4). The asset managers listed on djangopackages use any
> of those three methods. There is no agreement and none of those
> methods seems to be preferred:
> * django-compressor: (2)
> * django-mediasync: (1)
> * django-compress: (1)
> * django-mediagenerator: (4)
> * django-static: (4)
> * django-static-media-manager: (1)
> * django-assets: (2)

BTW, if the combined output CSS file is always placed into the root
folder (static_root/main.css) then code written for method (1) is
compatible with method (4).

Bye,
Waldemar

-- 
Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
http://www.allbuttonspressed.com/blog/django

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: contrib.staticfiles app concerns

[Waldemar Kornewald]

Hi Yuri,

On Thu, Oct 28, 2010 at 3:18 PM, burc...@gmail.com  wrote:
> Hi Waldemar,
>
> it seems I just don't get what does "relative to" mean in your (1)-(4).
> Could you please explain better, what do you mean by that?
> Starting with what path does your "css/main.css" have?
> I think you've missed some important bits in your explanations, or
> just not covering every possible choice.
> I presumed that with making css/main.css you're just copying that
> image over to your new location like staticfiles does (or symlinking
> images folder).

The image is just copied over. That's not the problem. The problem is
when you combine/concat CSS files. Indeed, staticfiles doesn't support
this, but it's still a real problem in practice because many people
use an asset manager that does combine files.

The source files might be
* app_a/static/app_a/css/style.css
* app_a/static/app_a/img/icon.png
* app_b/static/app_b/style.css
* app_b/static/app_b/icon.png
* ...

The combined CSS file might be written to "static_root/css/main.css",
so you'd have this result after generating your assets:
* static_root/css/main.css
* static_root/app_a/img/icon.png
* static_root/app_b/icon.png

Imagine that the input CSS files reference images via url() (e.g.:
"background-image: url()"). The big question is: What happens to
those url() paths when the files are combined?

Imagine you have this in app_a/css/style.css:

# app_a/static/app_a/css/style.css
div.app_a_icon {
  background-image: url(../img/icon.png);
}

What will this snippet look like in main.css after the files are combined?

With solution (1) we'd have no change:
# static_root/css/main.css
div.app_a_icon {
  background-image: url(../img/icon.png);
}

However, this won't work from main.css's location. The correct path
would be url(../app_a/img/icon.png). This means that everyone who uses
an asset manager based on method (1) needs to use a different path in
style.css:

# app_a/static/app_a/css/style.css
div.app_a_icon {
  background-image: url(../app_a/img/icon.png);
}

Now imagine that someone else uses an asset manager with method (2).
In his case URLs are rewritten relative to the source file. This means
he has to write:
url(../img/icon.png) in app_a/css/style.css

That's because the source folder is "static_root/app_a/css/" and if
you chdir into that folder then "../img/icon.png" refers to the file
"static_root/app_a/img/icon.png". That's what I mean with "relative
to" the source file.

With method (4) the same file would be referenced via
url(app_a/img/icon.png) in app_a/css/style.css

That's because here all paths are relative to the root media folder.
If you chdir into the "static_root" folder then "app_a/img/icon.png"
refers to "static_root/app_a/img/icon.png".

What's the problem with all of this? Code written for (1) is
incompatible with code written for (2) which is incompatible with code
written for (4). The asset managers listed on djangopackages use any
of those three methods. There is no agreement and none of those
methods seems to be preferred:
* django-compressor: (2)
* django-mediasync: (1)
* django-compress: (1)
* django-mediagenerator: (4)
* django-static: (4)
* django-static-media-manager: (1)
* django-assets: (2)

Solution (1) is useless when writing reusable code because (as you've
seen above) the source files would have to know the location of the
combined output file. This leaves (2) and (4) as possible options.

The problem with (2) is that it won't work well with Sass and other
CSS compilers. In Sass when you use @import the imported file is
copied into the master. If you have

# app_a/static/app_a/x.sass
@import subfolder/y

# app_a/static/app_a/subfolder/y.sass
... url(... what comes here? ...)

You want to refer to "static_root/app_a/img/icon.png" from y.sass.
Should the URL be "../img/icon.png" or "img/icon.png" or
"app_a/img/icon.png"? With solution (2) only the second URL works
because y.sass gets copied literally into x.sass by the Sass
executable. This means that y.sass would have to know the location of
x.sass. This problem is similar to solution (1) and makes writing
reusable code too difficult or even impossible.

What would this look like with (4)?

# app_a/static/app_a/subfolder/y.sass
... url(app_a/img/icon.png)

And what would the URL look like in app_a/css/style.css, again?

# app_a/static/app_a/css/style.css
... url(app_a/img/icon.png);

Look closely. It's *exactly* the same. It absolutely doesn't matter
where the source file is placed and it also doesn't matter where the
combined file is placed. You always use the same URL to refer to an
image. It's never ambiguous. BTW, method (4) has the same behavior as
Django's templates: {% extends %} and {% include %} are relative to
the root template folder, not the source file.

The only advantage of (2) is that it works more like what most
developers are used to when working without any asset manager. Since
(4) allows for much more consistent URLs I'd say method (4) 

Re: Feature request: ForeignKey through parameter

[Roald de Vries]

On Oct 28, 2010, at 4:02 PM, Javier Guerra Giraldez wrote:
On Thu, Oct 28, 2010 at 2:54 AM, Roald de Vries   
wrote:
I quite often reference foreign keys of foreign keys of foreign  
keys...

Wouldn't it be nice to have a 'through'-parameter for ForeignKey's?


   class A(Model):
   b = ForeignKey('B')
   c = ForeignKey('C', through='B', related_name='a_set')

   class B(Model):
   c = ForeignKey('C')


i'd love such a feature too, but i think a better syntax could be
something like:

  class A(Model):
  b = ForeignKey('B')
  c = ForeignKey('B__c', related_name='a_set')

  class B(Model):
  c = ForeignKey('C')

where the second part of the reference is the name of the field ('c'
in this example), not the model class ('C')


On first sight, I think I agree with you that the syntax is cleaner  
like this, but I would choose for the through-parameter because it's  
more consistent with the use of the through-parameter for  
ManyToManyField.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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: Feature request: ForeignKey through parameter

[Javier Guerra Giraldez]

On Thu, Oct 28, 2010 at 2:54 AM, Roald de Vries  wrote:
> I quite often reference foreign keys of foreign keys of foreign keys...
> Wouldn't it be nice to have a 'through'-parameter for ForeignKey's?
>
>
>    class A(Model):
>        b = ForeignKey('B')
>        c = ForeignKey('C', through='B', related_name='a_set')
>
>    class B(Model):
>        c = ForeignKey('C')

i'd love such a feature too, but i think a better syntax could be
something like:

   class A(Model):
   b = ForeignKey('B')
   c = ForeignKey('B__c', related_name='a_set')

   class B(Model):
   c = ForeignKey('C')

where the second part of the reference is the name of the field ('c'
in this example), not the model class ('C')

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: New localflavor: Turkey

[Ekrem SEREN]

2010/10/28 Serkan Kenar 
>> Thirdly, the patch needs verification by a third party, preferably
> I think we have to wait for somebody to raise his/her hand here. I don't know 
> anybody else in the community who is familiar with Turkish.

I believe I can test this. I just need a little help about the patch.

What's the proper way to apply and test the patch?

Regards,
--
Ekrem SEREN

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Custum permission bug

[Narciso Oceguera]

Hi, everyone.

As documentation said, I just added the lines:

class USCitizen(models.Model):
   # ...

   class Meta:
   permissions = (
   ("can_drive", "Can drive"),
   ("can_vote", "Can vote in elections"),
   ("can_drink", "Can drink alcohol"),
   )

But after executing:   
   manage.py syncdb
I can't get my custom permission added in the permission table. I think 
this is a bug because the permissions was not found in
model._meta.permission attribute ( opts.permissions ) as the signals 
(syncdb) expect. These

permission were added to the model object itself.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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: More efficient negative lookups

[George Vilches]

On Oct 27, 2010, at 5:55 PM, Jacob Kaplan-Moss wrote:

> On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty  wrote:
>> I'm inclined to say we do the former -- restore the "ne" lookup type
>> -- because it's a quick fix, and ask somebody to write up a patch for
>> the latter. Does anybody have strong opinions against this? If not, I
>> can restore the "ne" lookup type.
> 
> Sounds like a good plan to me (especially making simple excludes faster).
> 
> However, just for the record I think the reason we decided to remove
> __ne is the first place was that its existence introduces a weird
> inconsistency with regard to other lookup types. That is, if there's a
> "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down
> that path lies madness so I'm +0 on bringing back "ne" with the
> proviso that we agree it's not the first step down a slippery slope
> towards "nistartswith" and friends.

I know it's been a little while since I've made any major ORM contributions, 
but I'd say -0 on __ne, and +1 on making exclude generate better code.  
Django's worked far too hard on making things consistent as possible to let 
like this slip by just because we don't want to muddy our hands with a little 
harder work in the exclude() code.  So many other tickets have been stuck in 
DDN/Accepted forever because the area of code is harder to review, it's not 
like it's an unknown state in the project. :)

I'd even be willing to throw my hat in the ring to contribute towards an 
.exclude()-based solution if someone else doesn't step forward, but I know I 
won't be touching it until a few days pass.

George

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: contrib.staticfiles app concerns

[burc...@gmail.com]

Hi Waldemar,

it seems I just don't get what does "relative to" mean in your (1)-(4).
Could you please explain better, what do you mean by that?
Starting with what path does your "css/main.css" have?
I think you've missed some important bits in your explanations, or
just not covering every possible choice.
I presumed that with making css/main.css you're just copying that
image over to your new location like staticfiles does (or symlinking
images folder).

On Thu, Oct 28, 2010 at 1:29 PM, Waldemar Kornewald
 wrote:
> Hi Yuri,
>
> On Thu, Oct 28, 2010 at 6:19 AM, burc...@gmail.com  wrote:
>> Hi Waldemar,
>>
>> On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald
>>  wrote:
>>> 2010/10/27 Mikhail Korobov :
 Why isn't it fine to have different URL rewriting schemes for
 different assets bundlers?
>>>
>>> OK, sorry for not having explained it well. What I mean is this:
>>> Imagine this code snippet in a reusable app's CSS file:
>>>
>>> /* myapp/style.css */
>>> div.icon {
>>>  background-image: url(img/icon.png);
>>> }
>>>
>>> Now this file gets combined into "css/main.css". Depending on which
>>> asset manager and URL rewriting scheme you use the URL can be:
>>> 1. unmodified: "img/icon.png"
>>> 2. relative to the current file: "/static/myapp/img/icon.png"
>>> 3. relative to the combined file: "/static/css/img/icon.png"
>>> 4. relative to STATICFILES_URL "/static/img/icon.png"
>
> Which conflict do you mean? If you want to refer to some app's image
> from "app/css/style.css" you'd use "app/img/icon.png" with (4) and
> "../img/icon.png" with (2). Each path with (4) maps to exactly one
> path with (2) and the other way around, so any conflict that applies
> to (4) also applies to (2).
>
>>> (1), (2), and (3) would already be compatible with the current
>>> staticfiles implementation. (4) would require a little modification.
>>> I've seen (1), (2), and (4) used in practice when combining CSS files.
>>>
>>> Which behavior should be the standard for all asset managers?
>>
>> I think, in a compressor, you shouldn't rely on STATICFILES_URL but on your 
>> own
>> DJANGO_MEDIAGENERATOR_FILES_URL and DJANGO_MEDIAGENERATOR_FILES_ROOT,
>> which can be set up to implement necessary strategy from (1)-(4).
>
> Whether URLs are rewritten with STATICFILES_URL or
> DJANGO_MEDIAGENERATOR_FILES_URL doesn't make a real difference for
> this discussion. I'm fine with either setting, but let's first focus
> on the general URL rewriting solution, please.
>
> Bye,
> Waldemar
>
> --
> Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
> http://www.allbuttonspressed.com/blog/django
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>



-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.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-develop...@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: New localflavor: Turkey

[Serkan Kenar]

Hi Russel,

On Tue, Oct 26, 2010 at 7:15 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> It's certainly possible. However, the patch still needs a little work.
>

Thank you for the review. I have completed the following requests, but only
missing a third party confirmation. You can find the latest patch here:
http://code.djangoproject.com/attachment/ticket/14563/tr-localflavor.diff .

>
> Firstly, the patch doesn't contain any tests for the new
> functionality. Localflavors have historically been light on testing,
>

I have added tests for all fields. I am not so sure about how to test the
province select widget, since it only gives an output. I've seen some people
comparing the output of this with a text but I think that kind of testing is
unnecessary.

Secondly, all the work should be submitted in a single patch, not
>

I have attached a single patch for all code, tests and documentation. (
tr-localflavor.diff)

Thirdly, the patch needs verification by a third party, preferably
>

I think we have to wait for somebody to raise his/her hand here. I don't
know anybody else in the community who is familiar with Turkish.

Best regards,

-- 
Serkan Kenar

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

On 28 окт, 12:55, Ivan Sagalaev  wrote:
> On 10/27/2010 04:55 PM, Mikhail Korobov wrote:
>
> > 1. 'Border' middleware is a backwards-compatible change, the
> > requirement to bake response in middleware isn't.
>
> > The
> > difference is only that you propose to execute 'bake' in the end of
> > response cycle and I propose to execute it at the beginning of the
> > response cycle but to make this customizable (by changing the position
> > of the BakingMiddleware).
>
> I understand your points now, thanks. Two things bother me about
> 'border' middleware:
>
> - its semantics is a bit different than that of others middleware in the
> list in settings and this difference is not explicitly clear when
> looking at the list
>
> - it's bad to have a boilerplate code that people just have to put somewhere
>
> I've spent a night with a thought and now I think I can propose even
> better solution.
>
> We can introduce a new kind of middleware -- "template response
> middleware" for lack of a better name. A user who wants to do something
> with a template response *before* it is baked has to write a middleware
> like this:
>
>  class ContextInjectionMiddleware:
>  def process_template_response(self, request, response):
>  # do something with response
>
> Request handling code would look like this then:
>
>  response = get_response(...)
>
>  if hastattr(response, 'force_bake'):
>  # apply template response middleware
>  response.force_bake()
>
>  # apply normal response middleware
>
> This way we:
>
> - are getting rid of force_bake in HttpResponse where it's a noop
> - maintain backward compatibility since response is baked before all
> currently written middleware
> - require explicitly named method to deal with a new concept
>
> What's not to like? :-)

I like your solution.

The request handling code have to be put into WSGIHandler and into
ModPythonHandler so I'll wait until the patch for 
http://code.djangoproject.com/ticket/9886
will be landed.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Feature request: ForeignKey through parameter

[Roald de Vries]

Dear all,


I quite often reference foreign keys of foreign keys of foreign  
keys... Wouldn't it be nice to have a 'through'-parameter for  
ForeignKey's?



class A(Model):
b = ForeignKey('B')
c = ForeignKey('C', through='B', related_name='a_set')

class B(Model):
c = ForeignKey('C')


The advantages of a field A.c wrt a property A.c:
- it creates a reverse relation, so C.a_set becomes available
- c becomes queryable: A.objects.filter(c=x)


For 'through'-ing one more class you could use:

class Z(Model):
a = ForeignKey('A')
c = ForeignKey('C', through='A') # works because A.c exists

or:

class Z(Model):
a = ForeignKey('A')
c = ForeignKey('C', through='A__B')  # works regardless of  
whether A.c exists



I'm curious if other people would be interested in such a feature, or  
maybe if something alike or better already exists, and whether there  
are downsides that I miss.


Cheers, Roald

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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: It is real to add ticket #8054 to 1.3 milestone?

[Alex Kamedov]

Hi All. Big thanks to response!

> Am I correct and the goal is only to change list_display syntax?
> Yes, I don't see any other goal either, so I have controversial
> feelings about the issue.
> It has only syntax sugar, but that sugar is very sweet.

Hm. Yes, it provide only syntax sugar. But very often it'll be more easiest
way to customize admin (Eg.: apply template tags to model fields and
existing model methods).

Patch and wiki page were updated according to Yuri Baburov (buriy)
recomendations.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Gentle Proposal: add 'render' shortcut in 1.3

[Ivan Sagalaev]

On 10/27/2010 04:55 PM, Mikhail Korobov wrote:

1. 'Border' middleware is a backwards-compatible change, the
requirement to bake response in middleware isn't.

The
difference is only that you propose to execute 'bake' in the end of
response cycle and I propose to execute it at the beginning of the
response cycle but to make this customizable (by changing the position
of the BakingMiddleware).


I understand your points now, thanks. Two things bother me about 
'border' middleware:


- its semantics is a bit different than that of others middleware in the 
list in settings and this difference is not explicitly clear when 
looking at the list


- it's bad to have a boilerplate code that people just have to put somewhere

I've spent a night with a thought and now I think I can propose even 
better solution.


We can introduce a new kind of middleware — "template response 
middleware" for lack of a better name. A user who wants to do something 
with a template response *before* it is baked has to write a middleware 
like this:


class ContextInjectionMiddleware:
def process_template_response(self, request, response):
# do something with response

Request handling code would look like this then:

response = get_response(...)

if hastattr(response, 'force_bake'):
# apply template response middleware
response.force_bake()

# apply normal response middleware

This way we:

- are getting rid of force_bake in HttpResponse where it's a noop
- maintain backward compatibility since response is baked before all 
currently written middleware

- require explicitly named method to deal with a new concept

What's not to like? :-)

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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: contrib.staticfiles app concerns

[Waldemar Kornewald]

Hi Yuri,

On Thu, Oct 28, 2010 at 6:19 AM, burc...@gmail.com  wrote:
> Hi Waldemar,
>
> On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald
>  wrote:
>> 2010/10/27 Mikhail Korobov :
>>> Why isn't it fine to have different URL rewriting schemes for
>>> different assets bundlers?
>>
>> OK, sorry for not having explained it well. What I mean is this:
>> Imagine this code snippet in a reusable app's CSS file:
>>
>> /* myapp/style.css */
>> div.icon {
>>  background-image: url(img/icon.png);
>> }
>>
>> Now this file gets combined into "css/main.css". Depending on which
>> asset manager and URL rewriting scheme you use the URL can be:
>> 1. unmodified: "img/icon.png"
>> 2. relative to the current file: "/static/myapp/img/icon.png"
>> 3. relative to the combined file: "/static/css/img/icon.png"
>> 4. relative to STATICFILES_URL "/static/img/icon.png"
>>
>> If one developer who uses an asset manager based on (2) publishes a
>> reusable app and another developer who uses an asset manager based on
>> (4) publishes a reusable app there is no way to put both apps into
>> your project and have both work correctly with the same asset manager.
>>
>> Note, in practice, (1) and (3) have pretty much the same result.
>> Anyway, (1) and (3) would be very bad ideas if you want to support
>> combined files, so let's leave them out of this discussion.
>>
>> (2) is what everyone is used to, but it's inconsistent if you use Sass
>> or other CSS compilers because they allow importing other files which
>> might also contain URLs and there's no way for the asset manager to
>> rewrite URLs relative to the imported file's path (the asset manager
>> only gets one big result file which already contains all imported
>> files). This inconsistency is annoying e.g. when you develop both with
>> CSS and Sass.
>>
>> (4) is fully consistent and easy to understand, but obviously behaves
>> differently from what most people are used to when developing .
>> However, this way all URLs look the same, no matter if you use Sass or
>> CSS or both.
> (4) is no good because you might have file name conflicts when used
> with multiple reusable applications.
> Why haven't you mentioned this problem?

Which conflict do you mean? If you want to refer to some app's image
from "app/css/style.css" you'd use "app/img/icon.png" with (4) and
"../img/icon.png" with (2). Each path with (4) maps to exactly one
path with (2) and the other way around, so any conflict that applies
to (4) also applies to (2).

>> (1), (2), and (3) would already be compatible with the current
>> staticfiles implementation. (4) would require a little modification.
>> I've seen (1), (2), and (4) used in practice when combining CSS files.
>>
>> Which behavior should be the standard for all asset managers?
>
> I think, in a compressor, you shouldn't rely on STATICFILES_URL but on your 
> own
> DJANGO_MEDIAGENERATOR_FILES_URL and DJANGO_MEDIAGENERATOR_FILES_ROOT,
> which can be set up to implement necessary strategy from (1)-(4).

Whether URLs are rewritten with STATICFILES_URL or
DJANGO_MEDIAGENERATOR_FILES_URL doesn't make a real difference for
this discussion. I'm fine with either setting, but let's first focus
on the general URL rewriting solution, please.

Bye,
Waldemar

-- 
Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
http://www.allbuttonspressed.com/blog/django

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.