Pull to refresh

Comments 42

Спасибо, интересно! Я так понял, django-whatever — это что-то вроде FactoryGirl для джанго?
Судя по описанию, да, только factory_girl более навороченная.
Лучше бы Inline формы в админке без модели сделали бы и с возможностью не валидировать эти формы полностью.
Есть люди, которые заказали CMS у одной конторы. Контора все сделала, но админка там очень неудобная. Потом я начала переделывать все это, добавляя функции вроде гугль календаря, очистки кэшей через админку итд.

Через инлайны сделаны табы для материалов, в одном из инлайнов прикручена загрузка изображений. Для html5 dnd аплоада картинок нужно отключить там валидацию input'ов. Как отключить валидацию целой модели я не нашел, просто сделал вывод пустой формы, которая не позволяет изменять загруженные ранее объекты.

Сейчас вся админка состоит из костылей. Часть кода в этой CMS, которая идет отдельным пакетом, часть кода в самом джанго приложении. Плюс куча наследованных класов с переопределением методов. Я уже подумываю переписать админку с использованием Pyramid, а затем и морду перенести на Pyramid.
Проблема же не в Django, а в руках, должны понимать. Зачем отключать валидацию и что эта валидация у вас валидирует мне тоже не до конца понятно. Если форма это ModelForm, то валидацию можно определить/переопределить соответствующими методами.
class AAdmin(ModelAdmin):

fieldsets = (
(None, {
'fields': ('title', 'img', 'author', 'description', 'recommended')
}),
)
list_display = ('title',)
inlines = [PhotoInline]
tabs = True

def save_model(self, request, obj, form, change):
#Здесь сохрание

def get_urls(self):

from django.conf.urls.defaults import patterns, url
from django.utils.functional import update_wrapper

def wrap(view):
def wrapper(*args, **kwargs):
return self.admin_site.admin_view(view)(*args, **kwargs)
return update_wrapper(wrapper, view)

info = self.model._meta.app_label, self.model._meta.module_name

urlpatterns = patterns('',
url(r'^(.+)/save_sort/$',
wrap(self.save_sort),
name='%s_%s_save_sort' % info),
)
return urlpatterns + super(AAdmin, self).get_urls()

@csrf_exempt
def save_sort(self, request, object_id, extra_context=None):
def __POST(request):
#Парсинг json и запись в БД

if request.POST:
__POST(request)

response = HttpResponse(«OK»)
response.status_code = 200
return response

class PhotoInline(StackedInline):

model = Photo
ordering = ('order',)
template = 'admin/stacked.html'

Получаем редактирование материала и отдельный таб с загрузкой изображений. В шаблоне stacked.html идет вывод формы для загрузки изображений. Нужно отключить вывод формы, т.к. она не нужна, все делается через допметоды save_sort etc через передачу JSON. Если убрать форму, то валидация не проходит. Буду рад, если покажете как отключить валидацию PhotoInline.
Python без отступов — крууто :)

PS Пользуйтесь тегом <source> и предпросмотром.
UFO just landed and posted this here
всё равно не понятно зачем отключать валидацию, ложные срабатывания?
Что за контора и что за CMS на Django?
Противные джанго-программисты, не хотят за вас писать код :)
Отлично, спасибо за новую пачку батареек, парочку новых нашел.

Может кто подскажет ищу батарейку для решения такой задачи:
Многие из написанных мною приложений имеют собственные настройки, которые должны быть изменяемы из админки. Пример из головы (не самый удачный) — есть приложение отвечающее за аватары, есть ограничение на размер аватара. Хочется дать клиенту возможность управлять этим ограничением из админки. Идеально привязать настройки прямо к модели, чтобы была иконка «настройки» рядом с иконками «добавить» и «изменить». В тоже время чтобы в коде доступ к настройкам был прозрачный. Например такого рода: settings.app_name.model_name.setting

Пробовал всякие django-appsettings, django-dbsettings и другие но они тупые до невозможности неюзабельны. Где-то интеграция в админку скудная, где-то нет задания дефолтных значений вне БД, отчего нельзя читать настройки при инициализации других приложений.

Если нет такого приложения то я уж готов сам сесть писать…
Вот коллега рекоммендует django-livesettings, возможно вам подойдёт.

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

С миксином не понял. Как он поможет в данной ситуации. Поля из миксина окажутся в каждом объекте мдели, а нужно чтоб эти поля были едины для всех моделей. Ну и опять же, пока нет базы, нам не прочитать такие значения (хотя помощи сеттеров/геттеров можно чудеса творить).
Используем django-compressor, но смущает такой момент — почти каждая страница имеет уникальный набор css/js (пихать всё в одну кучу выйдет очень большой итоговый css и js), что приводит к тому что почти на каждую страницу есть уникальный же склеенный и сжатый файл, что для пользователя проявляется следующим образом — когда открывается новая страница скачивается новый минифицированный css/js, и пока он не скачается страница будет и без стилей и без js. И так для почти для каждой страницы.

Сталкивались ли вы с этим? Как одно из решений проблемы я вижу делать пару минифицированныйх файлов — в одном будут общие для всего сайта css/js, в другом — только уникальные для страницы. Но django-compressor вроде так не умеет.
Ужас какой.
Сколько ж у вас весит несжатый css, если в него со всех страниц стили добавить?
250 кб :) На самых тяжёлых страницах js ещё в полтора-два раза больше. В сумме после gzip будет 100-300 кб.
Этот «очень большой» итоговый css и js пользователь скачает ровно один раз и закеширует, так что я не вижу в этом проблемы.

PS Давно 250 кб стало «очень много» для единоразовой загрузки?
250 kb css плюс, посчитал, около 600 kb js. При этом основной размер дают большие библиотеки на js которые используются всего на паре страниц. По-моему 850 кб css/js это перебор, ещё ведь есть картинки и сама страница. Кроме размера файлов, это же всё нужно выполнить браузеру.

Может я придираюсь и экономлю на спичках, но мне кажется чем меньше страница тем лучше, а некоторым страницам у нас нужна всего пара килобайт css/js, зачем же пол мегабайта тащить? Особенно это чувствительно для landing pages, когда страница с одним абзацем и одной кнопкой будет весть пол мегабайта… не правильно это :)
Ну так не делайте таких страниц, вот и всё :)
Извините, не делать страниц в пару килобайт потому что есть страницы в пол-мегабайта? :) Или не делать страниц в пол мегабайта? Но тут к сожалению никак, используемые библиотеки и минифицированы с склеены и gzip но занимают много.
«При этом основной размер дают большие библиотеки на js которые используются всего на паре страниц.»

Так сделайте один общий набор, характерный для большинства страниц, а на этих нескольких уникальных страницах дополнительно подгружайте эти большие библиотеки (необязательно же всё запихнуть в 1 js файл)
Да, тоже вариант. Если не получится делать два сжатых файла средствами django-compressor, можно так и поступить. Спасибо.
Можно сделать несколько минифицированных файлов, django-compressor это позволяет. Вообще, это самое правильное решение, когда есть универсальная сборка, общаяя для всех страниц + уникальные минисборки для отдельных.
Подскажите как, не нашёл этого в доках.
Можно просто несколько тегов создать и всё:
{% compress css %}
    <link rel="stylesheet" href="{{STATIC_URL}}/layout.css" type="text/css">
    <link rel="stylesheet" href="{{STATIC_URL}}/main.css" type="text/css">
{% endcompress %}

{% compress css %}
    <link rel="stylesheet" href="{{STATIC_URL}}/pag1e.css" type="text/css">
    <link rel="stylesheet" href="{{STATIC_URL}}/page1_etc.css" type="text/css">
{% endcompress %}
Так просто и очевидно, спасибо!
django-pipeline это форк django-compress'а и работает точно также, получая список css/js из конфигруационных файлов. Поправьте, если я ошибаюсь.
Нам это кажется достаточно неудобным, поэтому от django-compress'а мы отказались.
Мы для переводов полей в моделях используем code.google.com/p/django-modeltranslation/
Глобальное отличие от hvad — поля, подлежащие переводу, указываются в отдельном файле translations.py (всё в одном файле, но при желании, конечно, можно разнести) и переводы хранятся в одной таблице с остальными полями.

translations.py выглядит примерно так:
from modeltranslation.translator import translator, TranslationOptions

from shop.models import Section, Category


class SectionTranslationOptions(TranslationOptions):
    fields = ('name', 'seo_keywords', 'seo_description', )


class CategoryTranslationOptions(TranslationOptions):
    fields = ('name', 'dative_name', 'instrumentative_name', 'all_plural_name', )


translator.register(Section, SectionTranslationOptions)
translator.register(Category, CategoryTranslationOptions)


А в админке это выглядит вот так:
А вкладки/переключатель языков в админке каким-то образом завязаны на modeltranslation? Чем сделаны?
Это понятно, приложением так и пользовался. Заинтересовал именно формат группировки доп. полей в админке на скриншоте — в виде вкладок.
Спасибо. Жутко торможу. (Вспомнил почему не применял: эти табы не работали с особенностями модифицированной админки конкретного проекта.)
По поводу сфинкса: очень рекомендую питоновскую апишку идущую в коробке. О ней почему-то часто забывают, а ведь она очень простая и приятная в использовании. Серьезно:
s = SphinxClient()
s.SetFilter('active', [1])
s.SetFilter('blog', [1111])
s.SetGroupBy('tags', SPH_GROUPBY_ATTR, "@count desc" )
s.AddQuery('', index=HABR_INDEX)
s.ResetGroupBy()

s.SetGroupBy('starred', SPH_GROUPBY_ATTR, "@count desc" )
s.AddQuery('', index=HABR_INDEX)

tags_facets, starred_facets = s.RunQueries()

Вот так вот просто две фасетки: тегов и тех у кого статья в избранных — причем в один мультизапрос, — это и быстрее и кода меньше, особенно когда нужно фасеток 5-10 собрать сразу, тогда можно просто for f in ['tags', 'followers', …].
В общем, я когда старый джанго-сфинкс смотрел так и не понял в чем его бонусы — апишка прозрачная, хорошо документированная (комменты).
Преимущество как минимум в том, что конфиг не надо генерить руками.
я так понимаю guardian вы заюзали после auhority? в последнем все никак даже админку непочинят, а патч в 1 строку. судя по всему пакеты очень похожи, стоит ли переходить на первый если в проекте уже используется последний?
Sign up to leave a comment.

Articles