Hello Collin, The problem with the second approach is that it's ugly, i prefer the first one instead. However, i've got to figure out how to prevent South from creating the migration in the "django.contrib.site" directory in my virtualenv.
Thanks, Rakan On Friday, October 3, 2014 5:14:34 PM UTC+3, Collin Anderson wrote: > > 1) Create a model that extends Site model: this would result in South >> adding the migration into django itself rather than the app extending the >> Site model. I haven't got any further with this option as i hit this road >> block. I think i understand that given the Site model is not abstract, >> extending that module is a wrong approach. >> > Subclassing Site should work. The tricky thing is creating a subclassed > site object from a site object. If you always create subclassed site > objects, you should be fine. Not a bad way to go, IMHO. > > 2) Create a model that has a one-to-one relation with the Site module, >> unregister the Site from admin and add it back again with my own >> "StackedInline" blog model added to the SiteAdmin that is to handle the >> admin interface for the Site model itself. However, the downside of this >> approach is that it the stackedinline would add *multiple* "Blog" inline >> forms to the site's admin page making the one-to-one relation like a >> foreign key relation. >> > I believe there are ways to limit the inline enough to make this work: > extra=0, max_num=1, can_delete=False, etc. > > >> Other approaches would be to add a non-model admin page with a >> configurations table that holds a single record for these configurations or >> extending the Site model as explained above. >> > That should also work. > > If it were me, I would start doing _each_ of the first two and pick the > one that seems to be looking the most promising. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c88a7e33-44b9-48bf-8e93-5fb2ff90a925%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
