Re: django-values -> django-policy?

[Michael Radziej]

On Wed, May 30, Nicola Larosa wrote:

> 
> > Jacob Kaplan-Moss (bikeshed BDFL) wrote:
> >> I'm going to make a dictatorial call to paint the bikeshed MY color.
> 
> Jason Davies wrote:
> > +1.
> 
> What part of "dictatorial" is not clear? ;-)

Publically cheering to dictatorial decisions is a good tradition all over
the world ;-)

Michael

-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
 
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - 
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: django-values -> django-policy?

[Jacob Kaplan-Moss]

On 5/31/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Publically cheering to dictatorial decisions is a good tradition all over
> the world ;-)

When do I get to rename months after my family?

[http://en.wikipedia.org/wiki/Saparmurat_Niyazov#New_Names_for_Months_and_Days]

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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: django-values -> django-policy?

[Nicola Larosa]

> Michael Radziej wrote:
>> Publically cheering to dictatorial decisions is a good tradition all over
>> the world ;-)

Jacob Kaplan-Moss wrote:
> When do I get to rename months after my family?
> 
> [http://en.wikipedia.org/wiki/Saparmurat_Niyazov#New_Names_for_Months_and_Days]

Don't know about months, but there's already a Physical Modeling Sound
Synthesizer Board under your name:

http://www.korg.com/gear/info.asp?A_PROD_NO=EXBMOSS


-- 
Nicola Larosa - http://www.tekNico.net/

Anyone who says their ambition is "to be famous" is a fragile ego desperate
for external recognition and for these people the Big Brother show can be a
devastating experience, not least with the constant fear of public "reject-
ion". Being voted out means "they don't love me" when the real problem is
that the celebs don't love themselves. -- David Icke, January 2007



--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Optgroups from nested choices in newforms (discussion of patch on #4412)

[Honza Král]

Has anything changed since Adrian ruled optgroups as unwanted?

see
http://code.djangoproject.com/ticket/3262
and
http://groups.google.com/group/django-developers/browse_frm/thread/b27f19d932c84316/37a4fa049dc63733?lnk=gst&q=optgroup


On 5/31/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 5/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > (Cleaning up some flagged items I've been meaning to respond to...)
> >
> > On Tue, 2007-05-29 at 03:56 -0500, James Bennett wrote:
> > > I noticed a patch sitting on #4412 tonight which seems interesting but
> > > definitely needs a decision; the idea is that, rather than
> > > implementing a separate widget or set of widgets to handle grouping of
> > > options (via the HTML "optgroup" element), the Select and
> > > SelectMultiple widgets should look at the structure of 'choices -- if
> > > it has a nested structure of grouped choices, those should translate
> > > into optgroups in the rendered widget.
> > >
> > > Personally, I kind of like the simplicity of the approach and the fact
> > > that it handles this use case without needlessly multiplying widgets,
> > > so I'd give it a tentative +1.
>
> Put me down as a +1 as well.
>
> > My only minor concern is that we are letting ourselves in for a large
> > number of queries asking why it doesn't work with models. I think it's a
> > *good* thing model fields still expect a sequence of pairs -- putting
> > presentation into the data representation is uncool -- but that won't
> > stop people trying to extrapolate. That feature should be documented so
> > that it can be properly ignored.
>
> I'm not sure I entirely agree on this.
>
> From a purist  perspective, I can see the appeal of keeping the model
> _absolutely_ data based. However, I can think of two practical reasons
> why this isn't necessarily a great idea:
>
> 1) Having to double-define your choice lists - once for the model
> (without groups), and once for the field (with groups) - would get
> tiresome _really_ fast, and would be prone to introducing errors
> (modify one list, forget to update the other). There are ways you
> could avoid double definitions, but this starts to make the right
> harder than the obvious/easy way, which is just inviting difficulty on
> the users lists.
>
> 2) form_for_model can't invent groupings, so it would be impossible to
> autogenerate a form with choice groupings without falling back on a
> field callback.
>
> Given that the groups can be safely ignored on the model, I'm not sure
> I see the practical harm in allowing them in a model definition.
>
> Russ %-)
>
> >
>


-- 
Honza Kr�l
E-Mail: [EMAIL PROTECTED]
ICQ#:   107471613
Phone:  +420 606 678585

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Optgroups from nested choices in newforms (discussion of patch on #4412)

[Russell Keith-Magee]

On 5/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> (Cleaning up some flagged items I've been meaning to respond to...)
>
> On Tue, 2007-05-29 at 03:56 -0500, James Bennett wrote:
> > I noticed a patch sitting on #4412 tonight which seems interesting but
> > definitely needs a decision; the idea is that, rather than
> > implementing a separate widget or set of widgets to handle grouping of
> > options (via the HTML "optgroup" element), the Select and
> > SelectMultiple widgets should look at the structure of 'choices -- if
> > it has a nested structure of grouped choices, those should translate
> > into optgroups in the rendered widget.
> >
> > Personally, I kind of like the simplicity of the approach and the fact
> > that it handles this use case without needlessly multiplying widgets,
> > so I'd give it a tentative +1.

Put me down as a +1 as well.

> My only minor concern is that we are letting ourselves in for a large
> number of queries asking why it doesn't work with models. I think it's a
> *good* thing model fields still expect a sequence of pairs -- putting
> presentation into the data representation is uncool -- but that won't
> stop people trying to extrapolate. That feature should be documented so
> that it can be properly ignored.

I'm not sure I entirely agree on this.

>From a purist  perspective, I can see the appeal of keeping the model
_absolutely_ data based. However, I can think of two practical reasons
why this isn't necessarily a great idea:

1) Having to double-define your choice lists - once for the model
(without groups), and once for the field (with groups) - would get
tiresome _really_ fast, and would be prone to introducing errors
(modify one list, forget to update the other). There are ways you
could avoid double definitions, but this starts to make the right
harder than the obvious/easy way, which is just inviting difficulty on
the users lists.

2) form_for_model can't invent groupings, so it would be impossible to
autogenerate a form with choice groupings without falling back on a
field callback.

Given that the groups can be safely ignored on the model, I'm not sure
I see the practical harm in allowing them in a model definition.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Checking group permissions in template code

[vida]

After reading the docs and looking for posts relating this problem
here and in .users, I found no "standard" way of checking for a
user's group permissions in the templates.

So what I did is to add the following method to auth.models.User
(yeah, yeah, it *should* be in appname.models.UserProfile):

def group_permissions(self):
class GroupPermissions:
def __init__(self, permissions):
for perm in permissions:
setattr(self, perm, True)

def __str__(self):
return 'The user belongs to the following groups: %s' % \
', '.join([k for k, v in self.__dict__.iteritems()])

return GroupPermissions(self.get_group_permissions())

which lets me write something like the following in my templates:
{% if user.group_permissions.permission_name %} draw custom menues for
this particular group here {% endif %}

So, is there already a way to do this and I missed it? If not, given
that it is apparently not advisable (is it?) to extend the
auth.models.User class, how about we add it?

-Facundo.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Optgroups from nested choices in newforms (discussion of patch on #4412)

[Waylan Limberg]

On 5/31/07, Honza Král <[EMAIL PROTECTED]> wrote:
> Has anything changed since Adrian ruled optgroups as unwanted?
>
> see
> http://code.djangoproject.com/ticket/3262
> and

Well, his comment there indicates that the lack of need would not
justify an additional widget. As James mentions, #4412 does not
introduce an additional widget.

> http://groups.google.com/group/django-developers/browse_frm/thread/b27f19d932c84316/37a4fa049dc63733?lnk=gst&q=optgroup

And unless I'm missing something, Adrian's comment in that thread
seems to indicate the having optgroups would be a welcome addition. I
take that to be a yes to optgroups as long as they don't require an
additional widget, but I could be wrong.


>
> On 5/31/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> >
> > On 5/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > >
> > > (Cleaning up some flagged items I've been meaning to respond to...)
> > >
> > > On Tue, 2007-05-29 at 03:56 -0500, James Bennett wrote:
> > > > I noticed a patch sitting on #4412 tonight which seems interesting but
> > > > definitely needs a decision; the idea is that, rather than
> > > > implementing a separate widget or set of widgets to handle grouping of
> > > > options (via the HTML "optgroup" element), the Select and
> > > > SelectMultiple widgets should look at the structure of 'choices -- if
> > > > it has a nested structure of grouped choices, those should translate
> > > > into optgroups in the rendered widget.
> > > >
> > > > Personally, I kind of like the simplicity of the approach and the fact
> > > > that it handles this use case without needlessly multiplying widgets,
> > > > so I'd give it a tentative +1.
> >
> > Put me down as a +1 as well.
> >
> > > My only minor concern is that we are letting ourselves in for a large
> > > number of queries asking why it doesn't work with models. I think it's a
> > > *good* thing model fields still expect a sequence of pairs -- putting
> > > presentation into the data representation is uncool -- but that won't
> > > stop people trying to extrapolate. That feature should be documented so
> > > that it can be properly ignored.
> >
> > I'm not sure I entirely agree on this.
> >
> > From a purist  perspective, I can see the appeal of keeping the model
> > _absolutely_ data based. However, I can think of two practical reasons
> > why this isn't necessarily a great idea:
> >
> > 1) Having to double-define your choice lists - once for the model
> > (without groups), and once for the field (with groups) - would get
> > tiresome _really_ fast, and would be prone to introducing errors
> > (modify one list, forget to update the other). There are ways you
> > could avoid double definitions, but this starts to make the right
> > harder than the obvious/easy way, which is just inviting difficulty on
> > the users lists.
> >
> > 2) form_for_model can't invent groupings, so it would be impossible to
> > autogenerate a form with choice groupings without falling back on a
> > field callback.
> >
> > Given that the groups can be safely ignored on the model, I'm not sure
> > I see the practical harm in allowing them in a model definition.
> >
> > Russ %-)
> >
> > >
> >
>
>
> --
> Honza Kr�l
> E-Mail: [EMAIL PROTECTED]
> ICQ#:   107471613
> Phone:  +420 606 678585
>
> >
>


-- 

Waylan Limberg
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: django-values -> django-policy?

[Michael Radziej]

On Thu, May 31, Jacob Kaplan-Moss wrote:

> On 5/31/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> > Publically cheering to dictatorial decisions is a good tradition all over
> > the world ;-)
> 
> When do I get to rename months after my family?

Ah, no problem at all in case your family members have the right names, like
"June", for example ... Dictatorship can be so easy: Simply remember to
order what everybody wants, and everybody will follow at once ;-)   [*]

Michael




[*] The difficult part is to make everybody want the "right" thing. There's 
the one strategie that defines "right" as "good for the citizens", 
and there's the other one that defines "right" as "good for the
citizens' health" ...  enough now :-)

 
-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
 
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - 
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Attn: creator of AjaxWidgetComboBox

[Darya]

you have mail.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Many-to-many relationships with additional columns

[Marty Alchin]

I've been giving a bit of thought into many-to-many relationships
lately, and I (once again) ran across the task of creating a
relationship that contained additional information. I know this has
been bounced around before, but I can't seem to find any substantial
discussions on the topic, so I wrote up a wiki article[1] with some of
my thoughts.

I'll be putting up the code I've got working so far that demonstrates
that parts of what I wrote up are indeed possible. The rest should be
as well, but it will probably take some extra discussion and possibly
some patches to how related managers work. I'll deal with that once I
figure out what all would be necessary.

My main reason for bringing it here, however, is to ask if there are
indeed some previous discussions that I should consider before I go to
far in my experiments on this subject. Or if I'm just completely off
my rocker.

-Gul

[1] http://code.djangoproject.com/wiki/ManyToManyManager

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Many-to-many relationships with additional columns

[Jacob Kaplan-Moss]

On 5/31/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> [1] http://code.djangoproject.com/wiki/ManyToManyManager

+1.

No, wait, + a whole lot more than that! I've been wanting explicit M2M
join objects for quite some time; this is a pretty neat way to
accomplish it.

Just for shits and giggles, here's another possible syntax I'd been
considering::

class Role(models.Model):
role = models.CharField(maxlength=255)

class Film(models.Model):
title = models.CharField(maxlength=255)

class Actor(models.Model):
name = models.CharField(maxlength=255)
films = models.ManyToManyField(Film, through=Role,
related_name="actors")

(i.e. Actor relates to File "through" Role.)

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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Checking group permissions in template code

[Russell Keith-Magee]

On 5/31/07, vida <[EMAIL PROTECTED]> wrote:
>
> After reading the docs and looking for posts relating this problem
> here and in .users, I found no "standard" way of checking for a
> user's group permissions in the templates.

Double posting to two groups like this is _really_ bad form. On top of
this, the django-developers group is intended for discussion of the
internals of Django itself.

If you're asking a "How do I do this" questions, django-users is the
place to do it.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Many-to-many relationships with additional columns

[oggie rob]

Yeah! This is much cleaner. I need to add ordering to some model
relations (i.e. represent all related values as an ordered list, where
relations can be shifted up & down) to the M2M field, it looks like it
would fit much easier using a manager & concrete Model subclass than
being restricted to a field.

I don't vote often, but +lots.

 -rob

On May 31, 1:32 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> I've been giving a bit of thought into many-to-many relationships
> lately, and I (once again) ran across the task of creating a
> relationship that contained additional information. I know this has
> been bounced around before, but I can't seem to find any substantial
> discussions on the topic, so I wrote up a wiki article[1] with some of
> my thoughts.
>
> I'll be putting up the code I've got working so far that demonstrates
> that parts of what I wrote up are indeed possible. The rest should be
> as well, but it will probably take some extra discussion and possibly
> some patches to how related managers work. I'll deal with that once I
> figure out what all would be necessary.
>
> My main reason for bringing it here, however, is to ask if there are
> indeed some previous discussions that I should consider before I go to
> far in my experiments on this subject. Or if I'm just completely off
> my rocker.
>
> -Gul
>
> [1]http://code.djangoproject.com/wiki/ManyToManyManager


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Checking group permissions in template code

[vida]

On May 31, 6:18 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 5/31/07, vida <[EMAIL PROTECTED]> wrote:
>
>
>
> > After reading the docs and looking for posts relating this problem
> > here and in .users, I found no "standard" way of checking for a
> > user's group permissions in the templates.
>
> Double posting to two groups like this is _really_ bad form. On top of
> this, the django-developers group is intended for discussion of the
> internals of Django itself.
>
> If you're asking a "How do I do this" questions, django-users is the
> place to do it.
>
> Yours
> Russ Magee %-)

I meant to CC this group when I posted to users.

It's both a *how do I do this?*, and a *if there isn't a way already,
how about we do it this one?* thingy, so I thought it'd be appropriate
for the two groups. I think that much is apparent.

Thanks for the netiquette lesson thou :)

-Facundo.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

<<< FLASH GAME MAKER DOWNLOAD >>>

[Rania Desai]

 Flash Game Maker Download

http://flash-game-maker.50webs.com/

flash game maker download Here 

For more help about Flash please reply me

RANIA

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

<<< Uk Universities List for Students >>>

[REKHA]

Hello Friends,
*Here are Top 10 UK Universities
admission open in some universities and some universities give you visa
assistance.
http://students.awepedia.info
/top-10-uk-universities/

if you needs more information about universities please reply me and
if you have any use full information about admission  in abrade
universities please share us.

Thanks
Sarah Singh
*

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Checking group permissions in template code

[Russell Keith-Magee]

On 6/1/07, vida <[EMAIL PROTECTED]> wrote:
>
> On May 31, 6:18 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> > If you're asking a "How do I do this" questions, django-users is the
> > place to do it.
>
> I meant to CC this group when I posted to users.
>
> It's both a *how do I do this?*, and a *if there isn't a way already,
> how about we do it this one?* thingy, so I thought it'd be appropriate
> for the two groups. I think that much is apparent.

It's not. If you don't know how to do something, ask on django-users.
Proposing a solution for a problem is exceedingly premature when you
have already admitted that you don't know if a solution already
exists.

CC'ing the dev list is no better - your message is sent regardless of
how it is sent, and the group archive doesn't distinguish between To
and CC.

If, as a result of asking your original question, a design issue
arises, and needs internal discussion, _then_ start the second thread.
In many cases, the second thread won't even be required - all the
django-developers read django-users too, so quite often raising the
issue in the users list will get the problem addressed.

Sorry if this seems like I'm coming down hard on you personally - it's
not intended as a personal attack. We (the developers) need to keep a
hard line on issues like this or the value in having a low-volume
developer-only list evaporates.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

((==Unbelievable Mega machines==))

[REKHA]

 *Friends Here are New 7 Wonders (Unbelievable Mega machine)*

http://information.100stuff.com/unbelievable-megamachine/

if you know about any unbelievable thing please us
Thanks
bye

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Many-to-many relationships with additional columns

[Russell Keith-Magee]

On 6/1/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> My main reason for bringing it here, however, is to ask if there are
> indeed some previous discussions that I should consider before I go to
> far in my experiments on this subject. Or if I'm just completely off
> my rocker.

You may well be completely off your rocker. I can't claim expertise in
that domain. Mostly because _I'm_ completely off my rocker, most of
the time :-).

However, you're not the first to propose this. In fact, I would doubt
that you are even the tenth. This is a pretty common request.

This is the first time that I've seen a viable mechanism for
distinguishing between queries over properties of the related object
and properties of the relation. Previously, the suggestion has been to
pseudo-add the fields of the relation model to the related classes:

Actor.objects.filter(films__title='Fight Club')
Actor.objects.filter(films__role='Tyler Durden')

Your suggestion seems to be more on the lines of pseudo-adding the
entire relation _model_ to the related classes:

Actor.objects.filter(films__title='Fight Club')
Actor.objects.filter(roles__role='Tyler Durden')

This are still some namespace clash problems, but they're much smaller
than previous suggestions, and the semantic ambiguity (i.e., the
implication of attributes on the related model that aren't actually
there) isn't as pronounced.

To add to your proposal, I would say that the pseudo-attribute should
derive its name from the relation name:

Actor.objects.filter(film_roles__role='Tyler Durden')
Film.objects.filter(actor_roles__role='Tyler Durden')

Specifically, this is avoid problems when you have two m2m relations
with a relation model (not a problem for this scenario, but certainly
conceivable). It also has the advantage of reducing the semantic
ambiguity a little further.

Regarding syntax; Jacob's suggestion is the usual suggested syntax for
proposals in this direction, and I'd have to say I prefer that syntax
to your M2MManager idea. To boot, Jacob's syntax should actually fit
into the existing contribute_to_model framework without too much
difficulty.

So, put me down as a +1, but with Jacob's syntax (or a variation therof).

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---