Anatoly Scherbakov

Если правильно понимаю, каждая строка отвечает одному `ProfileUser`, а каждый столбец одной `Section`. Причём не всем, а только тем `Section`, которые принадлежат текущему проекту. Каждая ячейка, следовательно, есть число всех объектов типа `ProfileUserSection`, отвечающих соответствующим `ProfileUser` и `Section`. Правильно я понимаю?

Адресация в шаблоне невозможна, это умышленное ограничение. Поэтому вам придётся передать в шаблон уже готовую матрицу ячеек. Ну например следующим образом - не ручаюсь за оптимальность, впрочем.

sections = list(Section.objects.filter(project=project, ...))
users = list(ProfileUser.objects.filter(...))

cells = [[user] + [
    ProfileUserSection.objects.filter(user=user, section=section).count() for section in sections
] for user in users]

context = {
    'sections': sections,
    'rows': cells
}

Шаблон:

{% for row in rows %}
<tr>
    {% for cell in row %}
        <td>{{ cell }}</td>
    {% endfor %}
</tr>

import calendar

year = 2015
print [
    list(range(1, calendar.monthrange(year, month)[1] + 1))
    for month in range(1, 13)
]

https://docs.python.org/2/library/calendar.html#ca...

Азимов, "Последний вопрос": www.lib.ru/FOUNDATION/question.txt

Возможно, имелось в виду использование семантической сети в качестве движка для хранения данных вашего сайта. В таком случае вы будете хранить данные в виде маркированного графа в формате RDF, поверх коего, возможно, построите онтологию на языке OWL. Чтобы получать из хранилища ту или иную информацию, будете использовать язык запросов SPARQL.

На ум приходит одно мейнстримное решение - монструозный OpenLink Virtuoso, но существует множество других библиотек и инструментов для разных языков и СУБД, их можно поискать.

Познакомиться с технологиями Semantic Web полезно и интересно. Но использование семантического хранилища вместо реляционной или, на крайний случай, нереляционной базы данных в большинстве случаев представляется не очень рациональным. В первую очередь потому, что медленно это. И потом, большая часть данных в реальной жизни имеет табличный характер и прекрасно ложится на реляционную базу; а начав возиться с triplestore, немедленно начинаешь страдать от отсутствия привычных уже реляционных плюшек.

Плюсом семантического хранилища является его гибкость и "разумность", если можно так сказать. Положим, вы строите структуру генеалогического дерева и хотите показывать на сайте, сколько у вас дедушек и бабушек. Тогда вы создаёте в своём графе узлы для себя, своих родителей, родителей их родителей, соединяя их дугами вида "родитель-ребёнок". Сделав это, вы можете написать средствами OWL правило: если C мужского пола и является ребёнком B, а B является ребёнком A, то C - внук А. И так далее.

Теперь вы просто пишете SPARQL-запрос, который возвращает все такие узлы Y, что Y является внуком X. Остальное за вас посчитает движок семантической сети.

Возможно, именно это от вас требовалось - я делал курсовую когда-то на эту тему.

Моё личное мнение состоит в том, что за технологиями Semantic Web будущее, но языки SW являются скорее прослойкой между системами, чем реальными языками для описания и хранения данных. Глупо в RDF-графе хранить большие объёмы хорошо структурированных данных, таблицы для этого подойдут гораздо лучше. А вот связывать разные системы меж собой посредством RDF и обращаться к ним через SPARQL - это интересно.

Второй подобный вопрос за сегодня. :) Посмотрите на stupeflix.com, у него есть API. Можно применять разнообразные красивые эффекты. Описание видео делается на XML.

Такой сервис уже существует, используйте API. stupeflix.com и developer.stupeflix.com

Для этого используются классы InlineAdmin - TabularInline и StackedInline. djbook.ru/rel1.7/ref/contrib/admin/index.html

А просматривать-то эти модели можно?

class MyAdmin(admin.ModelAdmin):
    fields = ['name', 'slug', 'date']
    readonly_fields = ['date']

    def has_add_permission(self):
        # Убрать право добавлять новые элементы
        return False

     def get_readonly_fields(self, request, obj=None):
          if obj and obj.pk:
               return self.fields
          else:
               return self.readonly_fields

Если объект сохранён, то все поля, заданные в fields, будут объявлены только для чтения. В обратном случае - только те, что заданы в readonly_fields. Не сработает, если у вас определены не fields, а fieldsets - тогда задайте поля вручную или рассмотрите объект obj._meta.fields (если не ошибаюсь).