Thanks a lot - I didn't know about generic relations, and will definitely look at them - right now :).
The minimal subset - and that's where I'm trying to follow DRY - boils down to a Title, a slug, Content HTML of the entry, maybe a couple more things - all are very much like what you would expect to have in a blog entry. It of course will also have comments, tags, category etc. - these should all be standard. But then, I want to be able add little things like event dates to it. And I'm trying to avoid having to create a whole new template just because I want to have one (or a few) extra <div>-s on the page which will display the event's dates. But this is the thing - event dates are not the only one thing I want to display. In another case I want it to be the same thing but have a rating... Maybe you're right and all of those things should come as generic addons, since ratings, comments etc are applicable to anything. I'm really scared of your last point - redesigning relationships. This seems to be the ugliest part if one happens to have to do this. I have over 12 years of Web experience... and still looking for the holy grail of OOD :) Hence are all the concerns. I'd be happy to see references to any more examples, guides etc... I'm sure there are some, but they're somehow difficult to find.. Additionally, I want to have one way of displaying it within HTML so I don't need On Jan 11, 5:21 pm, Ethan Jucovy <ethan.juc...@gmail.com> wrote: > 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-... > [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.
