cjl,
Essentially you need metatables that can describe the attributes
relatable to your main models. I built a proof of concept db backend
last year for a 'Database Application for the Management of
Information related to all Things' , (codenamed: DAMIT) but decided
that while possible, it was not very practical. I did it somewhat
like this (code abbreviated), if my memory serves me:
AttributeType(models.Model):
datatypelist = [('string','string'),('int','int'),('float','float')]
name = CharField()
datatype = CharField(choices=datatypelist)
Attribute(models.Model):
type = FK(AttributeType)
string_data = CharField()
int_data= IntField
float_data=...
AttributeOrder(models.Model):
attributetype=FK(AttributeType)
attributeorder=IntegerField()
AssetType(models.Model):
name=CharField()
attributeorder=M2M(AttributeOrder)
Asset(models.Model):
name = CharField()
assettypes = FK(AssetType)
attributes = M2M(Attribute)
Anyway, I think this is how I did it, as you can probably make out
from this, you cannot realistically hope to use the admin interface,
it is essentially unusable, but you can put together a custom
interface to deal with this. The attributeorder and attributetype are
used to build the forms that are presented to a user, the forms being
nothing more than a collection of attribute.data_X fields that are
presented in the order specified. It was not pretty.
The Generic Relations will make this easier, but my advice to you:
start building what you know you need, and leave yourself some
flexibility to integrate additional fields through meta-tables only if
absolutely required. That is what I am doing with my much scaled down
'Database Application for the Management of Of Very Specific Types of
IT Related Information' , although as of yet, I have not needed any
metatable fields. I am hoping to keep it that way.
HTH,
-richard
On Apr 17, 2008, at 3:22 PM, cjl wrote:
>
> DU:
>
> Don't ask me why, but I got the idea today to create a contact manager
> with Django, mostly as a learning exercise.
>
> Instead of doing it the 'easy' way, I had the dumb idea to make it
> 'dynamic'. What does that mean? I'm glad you asked. Here's how I see
> the database tables (I've omitted primary keys):
>
> contacts -- firstname, lastname
>
> field_definitions -- name, description, valid_regexp
>
> fields -- value, contact, field_definition
>
> Each contact could have as many or as few bits of information
> associated with it.
> I could create a default set of field definitions, ie. "Street
> Address", "Phone Number", etc.
> Field definitions could later be added dynamically, because maybe I
> want to start tracking Birthdays, or URLs, or other things I don't
> know yet.
>
> How dumb is this idea? It's not really an M2M relationship, more like
> an M2M with intermediary data.
>
> I found this:
> http://code.djangoproject.com/ticket/6095
> But this patch is not merged yet. Is there some other way to approach
> this problem?
> Am I wasting my time?
>
> Also, let's say I actually figure out how to do this...and when I look
> at a contact's information I retrieve all of the values that link to
> that contact...how could I intelligently order those values? Let's say
> some of the field definitions are "Street Address", "City", "State",
> and "Zip code", I would want them displayed in a certain
> order...hmmmm....not sure how to handle that.
>
> -cjl
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
