Re: Model inheritance API
Jacob Kaplan-Moss wrote: > On Jul 22, 2006, at 9:37 PM, Malcolm Tredinnick wrote: > > Rather than watch the "inherit from User" thread go round and round, > > maybe I should give people something more concrete to think about. First of all, +1 on this proposal. I've been approaching this problem from different ways for the past couple of weeks, and had settled on a very similar one to implement myself. I was suffering from a lack of examples of how to use the content type app though. > > (2) Any strong reason not to include this case? It's only for > > "advanced > > use", since there are a few ways to shoot yourself in the foot (e.g. > > declare a class abstract, create the tables, remove the abstract > > declaration, watch code explode). However, it will be useful in some > > cases. [I have some scripts to help with converting non-abstract > > inheritance to abstract and vice-versa at the database level, too.] > > I think abstract base classes are *key*, actually -- nearly every use > I'm thinking of includes 'em. . . . > So I'd get back an iterator that yields Things, Animals, and Toys? > That's what I'd expect, and want. I also think keeping the abstract class as a way of aggregating all the subclasses is key. An iterator is exactly what I would like to see as well. Please post any examples / code as they come! David Blewett --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Google Sitemaps
On 8/30/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: My only quibble is the recommendation in the docs to call``ping_google()`` from the ``save()`` method. I think the idea ofsetting off a HTTP request from within a ``save()`` method isn't sucha grand idea; network latency could cause the save to take too long, or the request could raise an exception causing the object not to getsaved... I'm not sure about what would be better, but it does rub methe wrong way.What about using signals? The ping_google() call could be activated by hooking in to the post_save() signal. David Blewett --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Branch Merges?
I would like to suggest that the branches that are felt to be complete sans testing be merged into a single branch. I am anxiously awaiting several different branch merges to core but do not have time to check each individual one out to test them. Maybe it's time to begin a larger effort, similar to magic-removal, at merging all these branches? David Blewett --~--~-~--~~~---~--~~ 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: Branch Merges?
James Bennett wrote: > So let me reiterate the call for anyone who wants to bang on a branch > to step up; we'll set you up with access to commit code and let you > bang away on it to your heart's content :) Sounds good to me. What do we need to do here? I'd like to help out with the FullHistory branch. It looks like it hasn't had trunk merged to it in a while. David Blewett --~--~-~--~~~---~--~~ 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: psyucopg2 status
Gary Doades wrote: > Yeah, I've been using it for a couple of months now with no problems. I > also use it on another project via SQLAlchemy. > > I only really pointed it out when I saw the beta chapters (chapter 2) > for the book. If it still recommends psycopg1 when it comes out it may > look out of date. > Just wanted to jump on the band wagon. I've been using psycopg2 for ~6 months now and haven't had an issue with it. I think this is a really valid point. We all know things are out of date as soon as they're printed, but this would be a real shame to be in the book. David --~--~-~--~~~---~--~~ 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: Fwd: how are you handling i18n and m10l content?
> > Actually this could be integrated into the core.
> > When you create a model, you could add translatable=True to fields
> > that have to be in the language-specific table.
> > When you make selections, you would need to set the language name in
> > the following or a similar way:
> > MyModel.objects.by_language("EN").all()
> > MyModel.objects.by_language("EN").order_by('title')
> > which would form queries like:
> > SELECT * FROM myapp_mymodel INNER JOIN myapp_mymodel_translatable ON
> > myapp_mymodel.id = myapp_mymodel_translatable.id ORDER BY title
>
> > Regards,
> > Aidas Bendoraitis [aka Archatas]
What about using generic relations for this? You could have something
like this:
class I18NText(models.Model):
language = models.ForeignKey(Language)
field = models.CharField(maxlength=25)
translated_text = models.TextField()
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
translated_object = models.GenericForeignKey()
def __str__(self):
return self.translated_text
class ModelNeedingTranslation(models.Model):
foo = models.IntegerField()
bar = models.TextField()
translations = models.GenericRelation(I18NText)
Then you can add translations of field(s) by doing:
a = ModelNeedingTranslation(1, 'nothing')
a.translations.create(field='bar', translated_text='nada',
language=Language('Spanish'))
You can get the text for a specific translation like this:
a.translations.filter(field='bar', language=Language('Spanish'))
David Blewett
--~--~-~--~~~---~--~~
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: Fwd: how are you handling i18n and m10l content?
On Nov 9, 8:14 am, "David Blewett" <[EMAIL PROTECTED]> wrote:
> What about using generic relations for this? You could have something
> like this:
>
> class I18NText(models.Model):
> language = models.ForeignKey(Language)
> field = models.CharField(maxlength=25)
> translated_text = models.TextField()
>
> content_type = models.ForeignKey(ContentType)
> object_id = models.PositiveIntegerField()
> translated_object = models.GenericForeignKey()
>
> def __str__(self):
> return self.translated_text
>
> class ModelNeedingTranslation(models.Model):
> foo = models.IntegerField()
> bar = models.TextField()
>
> translations = models.GenericRelation(I18NText)
>
> Then you can add translations of field(s) by doing:
> a = ModelNeedingTranslation(1, 'nothing')
> a.translations.create(field='bar', translated_text='nada',
> language=Language('Spanish'))
>
> You can get the text for a specific translation like this:
> a.translations.filter(field='bar', language=Language('Spanish'))
>
> David Blewett
Here's some links about generic relations:
http://feh.holsman.net/articles/2006/06/19/django-generic-relations
http://www.djangoproject.com/documentation/models/generic_relations/
David Blewett
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
