My instinct is that you may be trying to be too generic. Without knowing more details, a "generic Entry" sounds a lot like .. a database record. :) Django's model.Model base class already does a great job at being easily extensible.
Is there a specific minimal-but-interesting set of database fields that you want shared among all your models? If so, you might want to use an abstract base class that all your real models inherit from.[1] Is there a specific set of functionalities that you want several types of persistent objects to support? For this, unless you have very specific pluggability requirements, I would probably just define the functionality in a standalone function and informally adapt or handle each type as needed. Generic foreign keys[2] might also be helpful, if your requirements sound anything like "I have a Tag model, and I want to be able to attach Tags to any kind of object" or "I have a Comment model, and I want to be able to attach Comments to any kind of object." There are plenty of other approaches you could use too, of course, depending on your particular requirements. When in doubt keep it simple and keep it in Python -- it's a pain to refactor complex model relationships if you change your mind later on; far less so to replace ad-hoc Python functions with complex model relationships when you realize you actually need them. :) -Ethan [1] http://docs.djangoproject.com/en/dev/topics/db/models/#abstract-base-classes [2] http://www.djangoproject.com/documentation/models/generic_relations/ On Mon, Jan 11, 2010 at 9:24 AM, Igor <igor.rubinov...@gmail.com> wrote: > Hi all, > > This is a general question for whoever is good with best practices for > Django design (software design that is). > > I'd like to implement (well, kinda have implemented), a generic Entry > object that would be good for several uses. For example, an Event > (such as, say, a website presentation) is just an Entry with one or > more start/end dates attached. A business listing in a catalogue is > basically an Entry with some other properties such as business rating > or whatever else. There's more to it but I think you get the idea - I > want the Entry to be EASILY extensible with more features. This > includes easily extending the templates if possible. > > Am I trying to be too generic? Or, if not, what's a good approach to > take - I can use model inheritance, or an Event model could have an > Entry as a Foreign Key (which is what it does now). Or maybe there's a > whole other approach that I've missed but everyone else does? In any > case, how difficult would it be to access, say, all events that have a > post, or the other way around? > > I'm sorry if I'm not precise or if this sounds stupid. I have a great > trust in Django, but so far I've been advancing a bit slowly. It would > be great to hear your opinions. > > Thanks, > Igor > > > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > > >--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-us...@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.
