Опять про модели или как хранить данные?

Как вообше в реальных проектах решаются подобные задачи?

Делается кастомная вьюха для админки. Другое дело, что редко когда везет и приходиться полностью копипастить шаблон и его править — джанга же.

Но я все-таки не понимаю, вот например есть какая-то страница выводящая информацию о компании (адреса, телефоны, описание деятельности), компания только одна, следовательно модели использовать не очень удобно (на мой взгляд)

Для страницы, наверное, можно придумать что-то получше, а вот для общих настроек (информация в хедере, количество объектов на странице, всякие там контактные емейлы и т.д.) вполне можно применять модель.

Вот как делаю я (решение для django 1.3, на 1.4 пока не перешли):

Код, от которого наследуюсь.

#/path/to/my/special/module/mixins.py
class UniqueAdminMixin(object):
    '''Unique item admin mixin.

    This admin class removes changelist page and permits
    to edit only one model insyance.
    initial_fields - dict of required at instance creation fields.
    Example: initial_fields = {"header" : self.model.__name__}
    '''
    initial_fields = {}
    change_form_template = "admin/unique/change_form.html"
    
    def changelist_view(self, request, extra_context=None):
        '''Get or create instance and return change view.'''
        try:
            obj = self.model.objects.all()[0]
        except IndexError:
            obj = self.model(**self.initial_fields) # Initial required fields
            obj.save()
        result = super(UniqueAdminMixin, self).change_view(request, 
                                                           str(obj.id), 
                                                           extra_context=None)
        if request.POST and request.POST.has_key('_save'):
            result['Location'] = "../../" # Update after save redirects
        return result
                                                                                                    
    def get_urls(self):
        urls = super(UniqueAdminMixin, self).get_urls()
        my_urls = patterns('',
                           (r'^add/$', self.changelist_view)
                           )
        return my_urls + urls

«admin/unique/change_form.html» - шаблон, взятый из стандартной джанговской админки, в котором отрезаны кнопки «сохранить и добавить другое», а также подправлен breadcrumb. Сюда приводить не буду, т.к. слишком большой, и, при этом, сделать его просто.

Использование в коде:

#/path/to/project_app/admin.py
from my_module import UniqueAdminMixin

class SettingsAdmin(UniqueAdminMixin, admin.ModelAdmin):
    #обычный код для джанговской админки

Теперь, при заходе на страницу этих настроек в админке автоматом создаётся объект, если его ещё не существует. В описании класса можно указать дефолтные поля, там в комментарии к mixin-у написано (я, впрочем, редко использовал).

В самом проекте, не в админке, работаю так:

try:
    config = SettingsObject.objects.all()[0]
except IndexError:
    config = None

Хотя, обычно, для общих настроек сайта пишу middleware с этим кодом.

Да, решение кривовато, т.к. нет реального ограничение на количество объектов, и юзер, если захочет, таки создаст ещё один. Но рассчитано на применение только в админке, и только при «добром» администраторе (который не ломает) по-умолчанию. Кнопки «добавить» с главной страницы админки я убираю правами (т.е. пользователю не разрешается добавлять или удалять SettingsObject). Ну или можно ещё и шаблон индекса админки переделать.

Сама реализация не очень, но работает:)

flatpages. И нечего выдумывать, изобретать колесо.

«Сказать начальнику про json-файлик где-то там подковырять»

В друпале для этих целей используется таблица variable с полями name, value
наверное можно сделать модель с двумя полями и юзать для этого, нет?

Правда в друпе вся таблица считывается при каждом запросе, а потом переменные доступны глобально через функцию variable_get('var_name', 'default_value')

Правда это в 6,7 версиях. в 8 которая выйдет через год планируется так http://heyrocker.com/how-use-drupal-8-configuration-system

вот например есть какая-то страница выводящая информацию о компании (адреса, телефоны, описание деятельности)

Вот конкретно для этого случая flatpages самое то.

Не совсем, придется же все писать в одном поле content и все html теги там тоже расписывать и вдруг у меня все мудрено должно быть (телфоны в одном месте с одними свистелками, описание в другом...). По мне так этот подход не очень.

компания только одна, следовательно модели использовать не очень удобно (на мой взгляд)

Да прямо там, неудобно. Гораздо проще и эффективнее, нежели прочие велосипеды и т.д. мастерить. И админка прекрасно работать будет.

таблица variable с полями name, value

а для name сделать список выбора с перечислением возможных элементов, дабы ручного ввода названий параметров избежать.

не оно? http://pypi.python.org/pypi/dbconfig/0.1.8

есть какая-то страница выводящая информацию о компании (адреса, телефоны, описание деятельности), компания только одна

Слишком сложная это задача, сынок. Тут без Java EE, Oracle Database и пары хороших архитекторов с UML не обойтись.

OK

По мне так этот подход не очень.

Юноша, у Вас MVC головного мозга. Сон разума - aka бездумное применение паттернов- порождает монстров.

Вообще-то выше я писал что в данном случае не хочу применять MVC, но вариант с flatpages, мне тоже не нравится. Лучше бы что-то дельное предложили.

в данном случае не хочу применять MVC

да-да, я понял, налицо желание применить самопальный костыльный MVC «из говна и палок». Ъ!

Теперь вопрос: Как часто будут меняться контакты фирмы?

Не имеет значения как часто, главное что они будут меняться и небходим удобный механизм для их смены.

но вариант с flatpages, мне тоже не нравится

А flatpages почему не нравится?