Python Pyramid - request

лучше сделать так что бы не нужно было

почему?

много есть тому причин...

во вьюв ты всегда получаешь первой переменной request. Уточни что тебе именно нужно?

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

http://docs.pylonsproject.org/projects/pyramid/dev/narr/threadlocals.html

угу. вот только не могу понять как лучше сделать чтоб в шаблонах(jinja2) выводилось меню в зависимости от прав пользователя или вообще не выводилось если пользователь не авторизован? может вообще делать отдельные шаблоны?

дело в том что в приложении есть не только вьювы а ПРОБЛЕМА в том что если есть какой-то функционал которому НЕОБХОДИМ реквсест, он просто не может быть использован до того как реквест известен, тоесть цепочка вызовов фактически всегда «идет» через вьюв, но не всегда по этой цепочке передаются параметры. в общем случае всегда лучше провести рефакторинг чем городить огороды по асфальту.

что значит как лучше, как хочешь так и делай, про if'ы слыхал?

угу. вот только не могу понять как лучше сделать чтоб в шаблонах(jinja2) выводилось меню в зависимости от прав пользователя или вообще не выводилось если пользователь не авторизован? может вообще делать отдельные шаблоны?

честно говоря, я никогда не работал с jinja2. Ты можешь всегда передать в параметрах request или еще лучше обернуть view декоратором для проверки прав.

Т.е. те страницы, которые не видны простым смертным, обернуть декоратором, который будет делать редирект и писать, что страница недоступна. Не могу сказать как это сделать в Pyramid, т.к. давно им не пользовался, но это есть из коробки. Для меню ты можешь просто проверять в текущей сессии права и передавать параметр дополнительный вместе с тем, что выводится. Например, is_admin: object.is_admin и с той стороны в шаблоне проверять этот is_admin.

Если я не ошибаюсь Pyramid использует webob для разбора request переменных. А в webob получить request переменные просто , надо всего лишь передать переменную окружения

req = webob.Request(environ)

в принципе так и приходится делать. а что pyramid'ой перестали пользоватся?

а откуда импортировать эту переменную environ?

Если у вас приложение построено на архитектуре wsgi( а пирамида именно так и построена), то согласно спецификации переменная окружения передается сервером , который вызывает wsgi приложение

Я не работала с пирамидой, мне трудно сказать как там реализуется коннектор к wsgi приложению это нужно посмотреть по документации

http://docs.pylonsproject.org/projects/pyramid/1.2/narr/webob.html

Судя по документам функция реализующая приложение принимает обязательную переменную request, она скорее всего и содержит все request переменные

http://docs.pylonsproject.org/projects/pyramid/1.2/narr/firstapp.html#firstap...

в принципе так и приходится делать. а что pyramid'ой перестали пользоватся?

ну я пользовался Pylons, потом проект стал неактуален. А новый проект уже был до меня, поэтому сейчас вот доделаю на Django. Начну переписывать админку с i18n под два языка на Pyramid, т.к. будем делать английскую версию, а позже, когда будем делать субдомены, то все переведу на Pyramid.

ну и как личные впечатления django vs pylons?

ну и как личные впечатления django vs pylons?

Django - админка, во всем остальном она хуже. В Pylons ты можешь взять SQLAlchemy и mako и этого будет заглаза. mako я как-то и в cgi скриптах давно использовал, где не нужен mvc(там он просто избыточен). Сейчас вот с роутами в Django проблемы, они через какие-то костыли работают с субдоменами. А content object это ад и израиль :)

>А content object это ад и израиль :)

а в пирамиде как это реализовано?

а в пирамиде как это реализовано?

а в pyramid ты выбираешь сам ORM :)

Да прогнал.
Тогда по другому вопрос - чем тебе не понравился content object?

class ContentObject(models.Model):

    content_id = models.PositiveIntegerField()
    content_type = models.ForeignKey(ContentType, related_name='statistics_contentobject_set')
    content_object = generic.GenericForeignKey('content_type', 'content_id')
    count = models.PositiveIntegerField(default=0)

    objects = ContentObjectManager()

    class Meta:
        unique_together = ('content_id', 'content_type')


class Stat(models.Model):

    content_object = models.ForeignKey(ContentObject)
    date = models.DateField()
    count = models.PositiveIntegerField(default=0)

    class Meta:
        unique_together = ('content_object', 'date')

Ну и какая-нибудь моделька, для которой идет подсчет:

    
    title = models.CharField(_(u'title'), max_length=255)
    description = models.CharField(_(u'description'), max_length=255)

    rubric = models.ForeignKey(Rubric, verbose_name=_(u'rubric'))

    author = models.ForeignKey(User, null=True, verbose_name=_('author'), blank=True)
    enabled = models.BooleanField(
        _('enabled'), default=True, db_index=True,
        )
   
    objects = PublicationManager()
    
    class Meta(Publication.Meta):
        verbose_name = _(u'info')
        verbose_name_plural = _(u'info')
    
    def __unicode__(self):
        return self.title
    

А теперь отсортируй это по count из Stats все из последней модели, Rubric тоже модель и у нее есть id, вот по нему и сделай выборку, пусть он будет равен 8. А потом подумай как это сделать для 4х таких моделек как последняя и объединить их в один list :)

Ну так а зачем в данном случае content object?
Его вообще для сбора статистики крайне не эффективно использовать.
Учитывая, что тебе надо использование content object здесь не дает вообще ничего.

А потом подумай как это сделать для 4х таких моделек как последняя и объединить их в один list :)

Зачем тут вообще в list объединять эти 4-ре модельки, если тебя интересуют данные из Stats, которые уже сгрупированы?

content object для всяких тэгов, комментов очень удобно юзать.

Ну так а зачем в данном случае content object?

Зачем тут вообще в list объединять эти 4-ре модельки, если тебя интересуют данные из Stats, которые уже сгрупированы?

Эээ, не учи отца <шубу в трусы заправлять>. Ты мне напиши как сделать это :)

мне нужны именно записи отсортированные по Rubric.id = 8 и упорядоченные по Stats.count.

Ну с такими модельками я не знаю как это сделать средствами орм.

Нужно сначала сделать выборку по Rubric.id, потом отдельным запросом уже с сортировкой count сделать фильтр по тем данным, что были сделаны в первом запросе. Вот поэтому я не люблю Django :)

Ну а причем тут джанго?
Такую же структуру ты мог и в sqlalchemy сделать.

Ну а причем тут джанго?

Это сделали люди до меня. В SQLAlchemy есть обычный Join.

в джанго тоже можно юзать все что угодно, особенно для таких задач

в джанго тоже можно юзать все что угодно, особенно для таких задач

давай конкретно код, а не то, что можно.

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

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

объединить в одни list как два пальца об асфальт, а вот запрос сделать сложно. Разработчики Django сами говорят, что ORM только для легких запросов, для всего остального SQL.

Так код будет?

тебе не кажется что задача для ОРМ слишком специфична, и у джанги овермного способов решить ее без него?

да и вообще тут два варианта, либо ручками все выбирать-упорядочивать-строить и кешировать либо дизайн менять, может покажешь код как ты это на чем-то другом решаешь (на другом орм) с такой же структурой базы?

>В SQLAlchemy есть обычный Join.

А в джанге есть raw sql. И разницы между ним, и алхимийным джойном, практически нет. Он даже попроще, чем эти шаманства с eager loading и прочим.

ну и код напоследок https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models....