Mihail's initial version doesn't have any data in each model. So
presumably he's just tracking primary keys. In which case a
PositiveIntegerField would work.
And some of the use cases look awfully like 'choices=...' would be the
best bet. Others would be fine if you queried the current set of
values and put them in a drop down on the form:
options = set(MyModel.objects.values_list('opt', flat=True))
But I have had the odd occassion where I've wanted a set of options (a
la choices) but that were editable from the admin. Because of the need
to edit them, however, they have to be top level manually created
models, otherwise I can't specify their admin interface and edit them.
Ian.
On Jan 18, 3:35 am, Yuri Baburov <burc...@gmail.com> wrote:
> Hi Łukasz, Mikhail,
>
> You can go further and create DictionaryField.
>
> But I see the problems you will get with it:
> 1) You won't be able to refer to the model afterwards, since it's not
> defined in models.py as global.
> 2) I prefer to make DictionaryModel key the primary_key when
> appropriate, you'll need that option.
> 3) Additional fields or methods can appear at any time later, making
> such "economy" almost useless.
>
> So, my only wish is better builtin autocomplete widget for admin and
> regular usage.
> Current default one (for raw_id_fields) looks overcomplicated.
> Unfortunately, The Right autocomplete widget for django admin doesn't exist
> yet.
>
> 2010/1/18 Łukasz Rekucki <lreku...@gmail.com>:
>
>
>
> > 2010/1/17 Simon Meers <drme...@gmail.com>:
> >> I had considered designing something like this last week. It does seem to
> >> be
> >> a common requirement -- any situation where a simple field would be almost
> >> suitable but for the fact you'd like to avoid duplicates and allow fast
> >> selection of existing values. A Field shortcut could be commonly used to
> >> avoid the creation of separate models. Another example:
>
> >> class Suburb(models.Model):
> >> name = models.CharField(max_length=64, unique=True)
>
> >> class Meta:
> >> ordering = ['name']
>
> >> def __unicode__(self):
> >> return u'%s' % self.name
>
> >> class School(models.Model):
> >> name = models.CharField(max_length=64, unique=True)
>
> >> class Meta:
> >> ordering = ['name']
>
> >> def __unicode__(self):
> >> return u'%s' % self.name
>
> >> class Student(models.Model):
> >> school = models.ForeignKey(School)
> >> suburb = models.ForeignKey(Suburb)
> >> # ...
>
> >> could be replaced with simply:
>
> >> class Student(models.Model):
> >> school = models.DictionaryField(max_length=64)
> >> suburb = models.DictionaryField(max_length=64)
> >> # ...
>
> >> I'm not 100% sold on the name, but I think it is on the right track. I'm
> >> also wondering whether it could be worth catering for types other than
> >> CharField as well. For example:
>
> >> team_number = models.DictionaryField(type=models.IntegerField)
>
> >> This makes me wonder whether perhaps this could be generically applied to
> >> all fields via a Field.__init__ kwarg instead:
>
> >> class Student(models.Model):
> >> school = models.CharField(max_length=64, lookup=True)
> >> suburb = models.CharField(max_length=64, lookup=True)
> >> team_number = models.IntegerField(lookup=True)
>
> >> Either way, these fields could then be stored in separate tables
> >> appname_modelname_fieldname, with a single field of the appropriate type
> >> (named 'value' or similar). It would be nice to also provide external
> >> access
> >> to these auto-generated models via something like Student.school.objects.
> >> Currently Student.school would be a ReverseSingleRelatedObjectDescriptor,
> >> and objects can be accessed via
> >> Student.school.field.related.parent_model.objects.all(), but a shortcut
> >> would be nice.
>
> >> The auto-generated models could provide ordering by value, a unique
> >> constraint on the field, and a simple __unicode__ method like the examples
> >> above.
>
> > This seems like a lot of work and tweeks, just so you can save that 2
> > lines to define a class.
>
> > class DictModel(models.Model):
> > class Meta:
> > abstract = True
> > ordering = ['value']
> > unique_together = ('value',)
>
> > def __unicode__(self):
> > return unicode(self.value)
>
> > # just 2 lines per dictionary and you have all the flexibility you'll ever
> > need
> > class School(DictModel):
> > value = models.CharField(max_length=64)
>
> > class Suburb(DictModel):
> > value = models.IntegerField()
>
> > Also, by giving your dictionaries an explicit name, they can be easily
> > reused. I would probably also make the "value" field a primary_key, so
> > that you won't have to make all those joins just to print out
> > student's info.
>
> >> Simon
>
> >> 2010/1/17 Михаил Лукин <mihail.lu...@googlemail.com>
>
> >>> Well, the simplest way is making DictionaryField more like CharField,
> >>> except that it's values will be stored in separate table. For example
> >>> (application name is "hardware", engine is sqlite3), if I define
>
> >>> class HDD(models.Model):
> >>> form_factor = DictionaryField(max_length=10)
> >>> capacity = models.FloatField()
>
> >>> there will be 2 tables generated:
>
> >>> CREATE TABLE "hardware_hdd_form_factor_dict" (
> >>> "id" integer NOT NULL PRIMARY KEY,
> >>> "form_factor" varchar(10) NOT NULL UNIQUE
> >>> )
> >>> CREATE TABLE "hardware_hdd" (
> >>> "id" integer NOT NULL PRIMARY KEY,
> >>> "form_factor_id" integer NOT NULL REFERENCES
> >>> "hardware_hdd_form_factor_dict" ("id"),
> >>> "capacity" real NOT NULL
> >>> )
>
> >>> I guess, field constructor should not accept "unique" argument as it make
> >>> no sense.
> >>> I see 2 ways of rendering such field on a form:
> >>> 1) usual <input> with autocompletion;
> >>> 2) <select> + <input> + (maybe) radio buttons
> >>> as it should be allowed to choose from existing and to create new
> >>> dictionary item.
>
> --
> 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.
