On Sat, 2009-03-14 at 22:17 -0700, Michael Strickland wrote: > I'm building an app to serve the main pages for each category of a > news site. For this, I need to have several different ways to display > article teasers. For example, in one part of a page I might want to > display the teasers for five specific articles; in another part of the > page, I'd want to show the teasers for the last X-number of stories in > a specific category. Ideally, the user would be able to select the > display option as a drop down list in the model that describes that > part of the page: > > class PageBlock(models.Model): > name = models.PositiveSmallIntegerField() > cont = SeparatedValuesField(max_length=300) > page = models.ForeignKey(Page) > #disp = models.CharField(choices=DISPLAY_CHOICES)
[...] > Is there a way for fields to share their data with each other before > they are saved to the database? Or am I going about this a terrible > way? No, normal fields do not even know which models they are attached to (the model class, that is). That keeps all the dependencies generally pointing the same direction (models know about fields, but not vice-versa). The abstraction is stronger than that, too, as Fields are intended to operate independently like this. There's no way for a standard Field subclass to know about the "instance" of the model it is saving (you could save a reference to the model class as part of the contribute_to_class() method on a custom Field, but you wouldn't know about the instance). If you really want to do this, you could write a class that uses Python's descriptor protocol to assign an object to the model attribute so that you have complete control over setting and getting values for that attribute (including being given a reference to the instance containing the object). You could, for example, construct your field to update the values each time the attribute is accessed. It would only have to do work if the values had changed since last time. One example of doing this is Django's own ForeignKey and other related fields, although the code in model/fields/related.py is fairly tricky, for a bunch of good (and bad, sometimes) reasons. A simpler solution, which trades-away mega-intelligence in the field (complexity) at the cost of requiring an extra manual function call is to write a method that knows how to populate your summary field and call that method from your save() method each time. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
