Site specific additional configuration - extending Django Sites model

[Rakan Alhneiti]

Hello all,

I am currently trying to develop a blog engine which uses the sites framework provided by Django in order to add blog-specific settings. Such preferences could be something like blog_description, the user's twitter handle, pagination settings, widgets .. etc.

Looking at the sites framework, that only way you would use it is in one of the following options:

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.

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.

The task is simple, blog specific configurations. 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.

What do you think the best way to go about this?

Thanks,

Rakan

[Collin Anderson]

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.

[Rakan Alhneiti]

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

[Rakan Alhneiti]

It seems like the issue was with my app naming ("site") with south actually creating the migration into Django's site package directory.

Table inheritance seems the way to go. 

Thanks again,

Rakan

Best Regards,

Rakan AlHneiti

Find me on the internet:

Online Blog: http://rakan.me

 Rakan Alhneiti |  @rakanalh |  Rakan Alhneiti |   alhneiti

----- Mobile: +962-798-910 990

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/kjFDIyjA2SY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@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.