Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
Спасибо, интересно! Я так понял, django-whatever — это что-то вроде FactoryGirl для джанго?
Лучше бы Inline формы в админке без модели сделали бы и с возможностью не валидировать эти формы полностью.
а для чего это вам?
Есть люди, которые заказали CMS у одной конторы. Контора все сделала, но админка там очень неудобная. Потом я начала переделывать все это, добавляя функции вроде гугль календаря, очистки кэшей через админку итд.
Через инлайны сделаны табы для материалов, в одном из инлайнов прикручена загрузка изображений. Для html5 dnd аплоада картинок нужно отключить там валидацию input'ов. Как отключить валидацию целой модели я не нашел, просто сделал вывод пустой формы, которая не позволяет изменять загруженные ранее объекты.
Сейчас вся админка состоит из костылей. Часть кода в этой CMS, которая идет отдельным пакетом, часть кода в самом джанго приложении. Плюс куча наследованных класов с переопределением методов. Я уже подумываю переписать админку с использованием Pyramid, а затем и морду перенести на Pyramid.
Через инлайны сделаны табы для материалов, в одном из инлайнов прикручена загрузка изображений. Для 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.
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.
всё равно не понятно зачем отключать валидацию, ложные срабатывания?
Что за контора и что за CMS на Django?
Дак сделайте же!
Противные джанго-программисты, не хотят за вас писать код :)
Отлично, спасибо за новую пачку батареек, парочку новых нашел.
Может кто подскажет ищу батарейку для решения такой задачи:
Многие из написанных мною приложений имеют собственные настройки, которые должны быть изменяемы из админки. Пример из головы (не самый удачный) — есть приложение отвечающее за аватары, есть ограничение на размер аватара. Хочется дать клиенту возможность управлять этим ограничением из админки. Идеально привязать настройки прямо к модели, чтобы была иконка «настройки» рядом с иконками «добавить» и «изменить». В тоже время чтобы в коде доступ к настройкам был прозрачный. Например такого рода: settings.app_name.model_name.setting
Пробовал всякие django-appsettings, django-dbsettings и другие но онитупые до невозможности неюзабельны. Где-то интеграция в админку скудная, где-то нет задания дефолтных значений вне БД, отчего нельзя читать настройки при инициализации других приложений.
Если нет такого приложения то я уж готов сам сесть писать…
Может кто подскажет ищу батарейку для решения такой задачи:
Многие из написанных мною приложений имеют собственные настройки, которые должны быть изменяемы из админки. Пример из головы (не самый удачный) — есть приложение отвечающее за аватары, есть ограничение на размер аватара. Хочется дать клиенту возможность управлять этим ограничением из админки. Идеально привязать настройки прямо к модели, чтобы была иконка «настройки» рядом с иконками «добавить» и «изменить». В тоже время чтобы в коде доступ к настройкам был прозрачный. Например такого рода: 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/js, в другом — только уникальные для страницы. Но django-compressor вроде так не умеет.
Ужас какой.
Сколько ж у вас весит несжатый css, если в него со всех страниц стили добавить?
Сколько ж у вас весит несжатый css, если в него со всех страниц стили добавить?
250 кб :) На самых тяжёлых страницах js ещё в полтора-два раза больше. В сумме после gzip будет 100-300 кб.
Этот «очень большой» итоговый css и js пользователь скачает ровно один раз и закеширует, так что я не вижу в этом проблемы.
PS Давно 250 кб стало «очень много» для единоразовой загрузки?
PS Давно 250 кб стало «очень много» для единоразовой загрузки?
250 kb css плюс, посчитал, около 600 kb js. При этом основной размер дают большие библиотеки на js которые используются всего на паре страниц. По-моему 850 кб css/js это перебор, ещё ведь есть картинки и сама страница. Кроме размера файлов, это же всё нужно выполнить браузеру.
Может я придираюсь и экономлю на спичках, но мне кажется чем меньше страница тем лучше, а некоторым страницам у нас нужна всего пара килобайт css/js, зачем же пол мегабайта тащить? Особенно это чувствительно для landing pages, когда страница с одним абзацем и одной кнопкой будет весть пол мегабайта… не правильно это :)
Может я придираюсь и экономлю на спичках, но мне кажется чем меньше страница тем лучше, а некоторым страницам у нас нужна всего пара килобайт css/js, зачем же пол мегабайта тащить? Особенно это чувствительно для landing pages, когда страница с одним абзацем и одной кнопкой будет весть пол мегабайта… не правильно это :)
Ну так не делайте таких страниц, вот и всё :)
«При этом основной размер дают большие библиотеки на js которые используются всего на паре страниц.»
Так сделайте один общий набор, характерный для большинства страниц, а на этих нескольких уникальных страницах дополнительно подгружайте эти большие библиотеки (необязательно же всё запихнуть в 1 js файл)
Так сделайте один общий набор, характерный для большинства страниц, а на этих нескольких уникальных страницах дополнительно подгружайте эти большие библиотеки (необязательно же всё запихнуть в 1 js файл)
Можно сделать несколько минифицированных файлов, 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.readthedocs.org/en/latest/index.html
Мы для переводов полей в моделях используем code.google.com/p/django-modeltranslation/
Глобальное отличие от hvad — поля, подлежащие переводу, указываются в отдельном файле translations.py (всё в одном файле, но при желании, конечно, можно разнести) и переводы хранятся в одной таблице с остальными полями.
translations.py выглядит примерно так:
А в админке это выглядит вот так:
Глобальное отличие от 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? Чем сделаны?
В официальной доке django-modeltranslation всё написано.
from django.contrib import admin
from modeltranslation.admin import TranslationAdmin
class NewsAdmin(TranslationAdmin):
list_display = ('title',)
admin.site.register(News, NewsAdmin)
Это понятно, приложением так и пользовался. Заинтересовал именно формат группировки доп. полей в админке на скриншоте — в виде вкладок.
Значит просто не всю доку прочитал.
По поводу сфинкса: очень рекомендую питоновскую апишку идущую в коробке. О ней почему-то часто забывают, а ведь она очень простая и приятная в использовании. Серьезно:
Вот так вот просто две фасетки: тегов и тех у кого статья в избранных — причем в один мультизапрос, — это и быстрее и кода меньше, особенно когда нужно фасеток 5-10 собрать сразу, тогда можно просто for f in ['tags', 'followers', …].
В общем, я когда старый джанго-сфинкс смотрел так и не понял в чем его бонусы — апишка прозрачная, хорошо документированная (комменты).
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 строку. судя по всему пакеты очень похожи, стоит ли переходить на первый если в проекте уже используется последний?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ещё 10 батареек для джанго