Comments 58
> pre_save.connect(post_save_handler, sender=FlatPicture)
> pre_save.connect(pre_delete_handler, sender=FlatPicture)
Может быть
post_save.connect
pre_delete.connect
?
> pre_save.connect(pre_delete_handler, sender=FlatPicture)
Может быть
post_save.connect
pre_delete.connect
?
спасибо, исправил.
в реальном приложении использовал декораторы для сигналов из django-annoying, опечатался пока исправлял на традиционные.
в реальном приложении использовал декораторы для сигналов из django-annoying, опечатался пока исправлял на традиционные.
Спасибо Вам за эти пять копеек, мне стало понятно как использовать сигналы.
Жду продолжения.
Жду продолжения.
Cтоит отметить также sorl — классическое джанго-приложение. Для расширения админки есть, например, ImrpovedImageWithThumbnailsField — там и привьюшки, и галка «удалить» и пр.
круто!)
возможностей кастомизирования, правильней, как я полагаю =возможностей кастомизации
«Выберите картинка для изменения»
Тут pymorphy не поможет?
Тут pymorphy не поможет?
Вы знаете, как прикрутить pymorphy к админке? Поделитесь, пожалуйста. Автор сей библиотеки пока не занимался подобным.
Пока конкретных идей нету, но это было бы довольно логично и правильно. Как появятся, будем писать.
Как раз сейчас этим занимаюсь, с утра. Там есть несколько вопросов, которые требуется решить:
а) на первый взгляд, не все строки формируются в шаблонах (некоторые напрямую в ModelAdmin),
б) у модели «лошадь Пржевальского» не нужно склонять слово «Пржевальского»
в) желательно сделать так, чтобы не поломалась i18n и в языках кроме русского изменений никаких не было.
а) на первый взгляд, не все строки формируются в шаблонах (некоторые напрямую в ModelAdmin),
б) у модели «лошадь Пржевальского» не нужно склонять слово «Пржевальского»
в) желательно сделать так, чтобы не поломалась i18n и в языках кроме русского изменений никаких не было.
UFO just landed and posted this here
Для генерации тамбнейлов в любой цмске существует удобная библиотека phpThumb
Куча настроек, высокая скорость работы, кеширование, а главное — гибкость. Сам юзаю около года и настоятельно рекомендую другим! :)
Куча настроек, высокая скорость работы, кеширование, а главное — гибкость. Сам юзаю около года и настоятельно рекомендую другим! :)
Очень недальновидно манипулировать файлами через os.path.
Куда грамотней использовать джанговский file storage, ведь вместо стандартного FileSystemStorage может быть что-нибудь другое, например, S3Storage или FTPStorage.
Куда грамотней использовать джанговский file storage, ведь вместо стандартного FileSystemStorage может быть что-нибудь другое, например, S3Storage или FTPStorage.
UFO just landed and posted this here
UFO just landed and posted this here
Для таких целей мы используем django-filebrowser, к TinyMCE он легко прикручивается.
А зачем выносить функции в отдельный файл, почему бы не указать в самой новой модели? Зачем указывать size в каждой функции, не лучше было бы назначить его глобальной переменной ака константой? Да и опять же os.path…
всем спасибо за предложенные варианты готовых существующих решений. согласен возможно стоило упомянуть 1000 и одну готовую реализацию thumbnails, только не об этом была статья.
хотелось показать что кастомизировать джангу под себя и под свой собственный уникальный случай совсем не сложно — немного яваскрипта, мозга, фантазии и готово. и совсем не обязательно копипастить с djangosnippets или опускать руки если вдруг не нашли подходящий плагин.
порой написание виджета или переопределение классов формы в админке для людей, только что пришедших в джанго, может оказаться задачей из разряда тех на которые проще забить и пойти наговнокодить на «другом языке», чем разбираться. после чего написать в блоге/рассказать друзьям, что админку Django сложно кастомизировать.
хотелось показать что кастомизировать джангу под себя и под свой собственный уникальный случай совсем не сложно — немного яваскрипта, мозга, фантазии и готово. и совсем не обязательно копипастить с djangosnippets или опускать руки если вдруг не нашли подходящий плагин.
порой написание виджета или переопределение классов формы в админке для людей, только что пришедших в джанго, может оказаться задачей из разряда тех на которые проще забить и пойти наговнокодить на «другом языке», чем разбираться. после чего написать в блоге/рассказать друзьям, что админку Django сложно кастомизировать.
PIL — стандартно, но не всегда качественно, к сожалению. Профессиональные фотографы на глаз отличают картинки, созданные PIL'ом :(
Ваше безапеляционное заявление о том, что возможность подключения кастомного js/css снимает любые ограничения на кастомизацию джанговской админки мягко говоря не соответствует истине, приведу пару простых примеров:
— нет способа нормально реализовать взаимодейстие между встроенным поиском и фильтрами по полям модели
— данные из фильтров списка не передаются в форму создания/редактирования объекта
для того чтобы исправить эти моменты приходится лезть вглубь contrib.admin копипастить из ModelAdmin и AdminSite и менять методы, так что возможность использования этой админки в продакшене под очень большим вопросом, если вы пишите проект сложностью выше среднего
— нет способа нормально реализовать взаимодейстие между встроенным поиском и фильтрами по полям модели
— данные из фильтров списка не передаются в форму создания/редактирования объекта
для того чтобы исправить эти моменты приходится лезть вглубь contrib.admin копипастить из ModelAdmin и AdminSite и менять методы, так что возможность использования этой админки в продакшене под очень большим вопросом, если вы пишите проект сложностью выше среднего
Использую решение отсюда: code.djangoproject.com/ticket/3777, оно простое, без копипасты и тд, более-менее работает.
Я бы не назвал данное решение работающим — что делать когда пользователю надо работать в двух вкладках с разными типами документов? опять же это частичное решение только одной проблемы, а таких проблем еще немало — к примеру невозможно с помощью пермишенов ограничить доступ к заданным полям модели. Можно придумать хак, который позволит решить и эту проблему, но тут мы уже должны подойти к логичному выводу
я повторю свою основную мысль — contrib.admin прокатывает если Вы делаете домашнюю страницу Васи Пупкина или простенький каталог или что-то столь же примитивное. когда речь заходит о более сложном проекте — стандартная админка не состоятельна
я повторю свою основную мысль — contrib.admin прокатывает если Вы делаете домашнюю страницу Васи Пупкина или простенький каталог или что-то столь же примитивное. когда речь заходит о более сложном проекте — стандартная админка не состоятельна
Да ну неправильная же основная мысль все-таки)
Доступ ограничить можно — завести отдельный AdminSite для таких пользователей, и это не хак, а описанный в документации подход. Но вообще, раз вопрос такой возник, скорее всего, админка немного не по назначению используется.
Дело вовсе не в том, сложный проект или нет. Сложность-то разная бывает. Если подразумевается какое-то продвинутое в плане интерфейса взаимодействие с клиентом, рисуется интерфейс, он верстается, все прикручивается, и вопрос о несостоятельности админки в этом случае вообще не встает, т.к. никому и в голову не приходит для этого использовать админку. Админка — это не универсальное средство CRUD, на котором можно строить публичный интерфейс. Публичные интерфейсы делаются на формах и вьюхах. Админка — для управления сайтом. Ей пользуется администратор (или несколько администраторов). Т.к. их не много, то некоторые шероховатости интерфейса не так важны. По-моему так это именно небольшие шероховатости, к которым можно привыкнуть и которые не сильно влияют на юзабилити — в примере с несохранением фильтров просто берем и открываем что нужно в новых вкладках, да и все. Мне тоже некоторые вещи не нравятся, кстати, персональная хотелка — возможность фильтрации «ИЛИ», а не только «И».
Пусть зашла речь о супер-сложном проекте. Для внешних пользователей делается отдельный интерфейс, админка продолжает прекрасно использоваться для внутреннего управления сайтом — и все счастливы. Какой смысл отказываться от того, что уже готово, достается без усилий и отлично работает?
Доступ ограничить можно — завести отдельный AdminSite для таких пользователей, и это не хак, а описанный в документации подход. Но вообще, раз вопрос такой возник, скорее всего, админка немного не по назначению используется.
Дело вовсе не в том, сложный проект или нет. Сложность-то разная бывает. Если подразумевается какое-то продвинутое в плане интерфейса взаимодействие с клиентом, рисуется интерфейс, он верстается, все прикручивается, и вопрос о несостоятельности админки в этом случае вообще не встает, т.к. никому и в голову не приходит для этого использовать админку. Админка — это не универсальное средство CRUD, на котором можно строить публичный интерфейс. Публичные интерфейсы делаются на формах и вьюхах. Админка — для управления сайтом. Ей пользуется администратор (или несколько администраторов). Т.к. их не много, то некоторые шероховатости интерфейса не так важны. По-моему так это именно небольшие шероховатости, к которым можно привыкнуть и которые не сильно влияют на юзабилити — в примере с несохранением фильтров просто берем и открываем что нужно в новых вкладках, да и все. Мне тоже некоторые вещи не нравятся, кстати, персональная хотелка — возможность фильтрации «ИЛИ», а не только «И».
Пусть зашла речь о супер-сложном проекте. Для внешних пользователей делается отдельный интерфейс, админка продолжает прекрасно использоваться для внутреннего управления сайтом — и все счастливы. Какой смысл отказываться от того, что уже готово, достается без усилий и отлично работает?
не подменяйте понятия — откуда Вы взяли про публичный интерфейс? это все и было в управлении сайтом. Редакторы и контент-менеджеры — это не тупые обезьянки, которые увидели компьютер второй раз в жизни. То, что Вы называете «некоторые шероховатости интерфейса» там превращалось в ОЧЕНЬ серьезную проблему и сильно усложняло и замедляло их работу, так что эти проблемы нужно было решать.
насчет «возможность фильтрации «ИЛИ», а не только «И».» — это там тоже было и это я тогда тоже сделал. Так что опыт в кастомизации админки у меня есть и немалый и именно исходя из этого опыта я могу сказать — contrib.admin не пригоден как основа редакторского/модераторского интерфейса на сложном проекте.
насчет «возможность фильтрации «ИЛИ», а не только «И».» — это там тоже было и это я тогда тоже сделал. Так что опыт в кастомизации админки у меня есть и немалый и именно исходя из этого опыта я могу сказать — contrib.admin не пригоден как основа редакторского/модераторского интерфейса на сложном проекте.
ну оба примера неплохо решаются кастомным яваскриптом :) если не хватает каких-то данных — дописываем вью метод в пару строчек возвращающий аяксом нужный JSON. в том то и дело, что с таким подходом не придётся лезть в код джанги — стандартные вещи декорируются яваскриптом настолько сильно насколько это нужно.
и это не хаки, а понятный код, в котором другой человек может разобраться и поддерживать.
в любом случае, имхо лучше дописать пару скриптов, писать целую админку с нуля.
что касается column-level пермишенов — как это нету? кастомные пермишены есть. сделайте по пермишену на каждую колонку и переопределите методы моделей. решается без всяких хаков джанги — в любом случае лучше чем целую админку писать. на данный момент в транке и row-level auth практически сделан.
и это не хаки, а понятный код, в котором другой человек может разобраться и поддерживать.
в любом случае, имхо лучше дописать пару скриптов, писать целую админку с нуля.
что касается column-level пермишенов — как это нету? кастомные пермишены есть. сделайте по пермишену на каждую колонку и переопределите методы моделей. решается без всяких хаков джанги — в любом случае лучше чем целую админку писать. на данный момент в транке и row-level auth практически сделан.
покажите как с помощью кастомного js вы решите проблему передачи параметров из фильтра списка в форму создания объекта.
пока не покажут, не поверите? :)
если я правильно понял задачу, то кнопка «создать...» будет не просто переходить на страницу создания формы, а ещё и доклеет к query-string выбранные фильтры.
соответственно на странице формы другой яваскрипт будет автоматически заполнять нужные поля значениями, взятыми из query-string.
а можно красивее — ничего не доклеивать, а получить информацию о выбранных фильтрах из URL referer'а формы.
если я правильно понял задачу, то кнопка «создать...» будет не просто переходить на страницу создания формы, а ещё и доклеет к query-string выбранные фильтры.
соответственно на странице формы другой яваскрипт будет автоматически заполнять нужные поля значениями, взятыми из query-string.
а можно красивее — ничего не доклеивать, а получить информацию о выбранных фильтрах из URL referer'а формы.
нет, задачу вы поняли не правильно, задача получить эти данные на серверной стороне и на их основании заполнить данные в форме — в частности создать связи с другими обектами(при этом убедившись в сществовании таких объектов). Перестаньте пытаться выдать желаемое за действительное апелируя к простейшим случаям. Я уже говорил — для простого ресурса — джанговская админка вполне пригодна, при реализации сложной логики затраты на «кастомизацию» становятся равны затратам на создание отдельного интерфейса.
ну как вы спросили, так я и ответил :) надо «создать/убедиться» — можно сделать это аяксом — покажите пальцем где огромные затраты/сложности. или это просто пример неудачный? — я же не против, просто то, что вы говорите, противоречит моему опыту.
я приводил пример того, что в админке далеко не все возможно — в частности нет возможности нормально обработать даные из фильтров при создании/изменении объекта. нет общего решения — понимаете? для двух-трех фильтров в паре моделей ваш вариант с аяксовой вьюшкой вполне приемлем и действительно тогда затраты на создание отдельной админки будут выше чем на кастомизацию.
Но что делать когда у модели полтора десятка фильтров и таких моделей с десяток? писать отдельную аяксовую вьюшку для каждого фильтра? это уже треть работ по созданию отдельной админки и в чем тогда профит использования контриба?
Опять же мы сейчас говорим только о части работ, а ведь есть еще немалое количество задач — кастомизация внешнего вида и способа работы самих фильтров — например создание связанных фильтров. Это возможно, но это тоже отнюдь не так просто, как кажется на первый взгляд.
Но что делать когда у модели полтора десятка фильтров и таких моделей с десяток? писать отдельную аяксовую вьюшку для каждого фильтра? это уже треть работ по созданию отдельной админки и в чем тогда профит использования контриба?
Опять же мы сейчас говорим только о части работ, а ведь есть еще немалое количество задач — кастомизация внешнего вида и способа работы самих фильтров — например создание связанных фильтров. Это возможно, но это тоже отнюдь не так просто, как кажется на первый взгляд.
а насчет сделать доп. пермишены на колонку — вы всерьез полагаете, что это приемлимое решение при 50+ моделях по 10-15 полей в каждой? и кто потом будет разгребать эту кучу хлама?
конечно же не следует брать и дописывать одну и ту же логику в каждую модель. XXI век на дворе — поэтому у нас есть сигналы, наследование и метаклассы.
сигналы и мета классы тут абсолютно не причем.
вставлять один и тот же код в каждую модель конечно не стоит и вот тут мы возвращаемся к началу нашей дискуссии — чтобы реализовать требующиеся фичи нужно изменить поведение ModelAdmin и AdminSite — мы от них наследуемся, и исправляем нужные нам куски, но поскольку нужные нам куски кода находятся в середине родительских методов, так что традиционный способ с вызом родительского метода и изменением возвращенного им результата тут не работает, так что приходится копипастить код из родителя и менять его в потомке. о чем я говорил в самом начале.
вставлять один и тот же код в каждую модель конечно не стоит и вот тут мы возвращаемся к началу нашей дискуссии — чтобы реализовать требующиеся фичи нужно изменить поведение ModelAdmin и AdminSite — мы от них наследуемся, и исправляем нужные нам куски, но поскольку нужные нам куски кода находятся в середине родительских методов, так что традиционный способ с вызом родительского метода и изменением возвращенного им результата тут не работает, так что приходится копипастить код из родителя и менять его в потомке. о чем я говорил в самом начале.
вам достаточно отнаследоваться и переопределить save() ваших моделей, что. сигнал можно повесить на автосоздание пермишенов для колонок при syncdb/migrate/… если очень хочется. вместо наследования можно разрулить с пом. метакласса. надеюсь пояснил что для чего.
зачем вам вобще нужно наследовать классы админки не понял.
но это всё детали — главное, что ваша очень специфичная проблема решается, причём довольно просто. так почему же её не использовать?
зачем вам вобще нужно наследовать классы админки не понял.
но это всё детали — главное, что ваша очень специфичная проблема решается, причём довольно просто. так почему же её не использовать?
не катит, поскольку у юзера может не быть разрешения даже на просмотр определенных полей
в том то и дело что мои задачи НЕ решаются без большого количества копипастинга и изменения существующего кода стандартной админки. объем этого копипастинга и последующих изменений был настолько велик, что написать свою админку заняло бы столько же времени.
Скажите, зачем Вы пытаетесь доказать, что contrib.admin это лучший инструмент из всех, хотя это далеко не так?
Скажите, зачем Вы пытаетесь доказать, что contrib.admin это лучший инструмент из всех, хотя это далеко не так?
> объем этого копипастинга и последующих изменений был настолько велик, что написать свою админку заняло бы столько же времени.
«заняло бы» — т.е. вы не пробовали?
> Скажите, зачем Вы пытаетесь доказать, что contrib.admin это лучший инструмент из всех, хотя это далеко не так?
я пытаюсь доказать, что забить гвоздь молотком проще чем рукой.
«заняло бы» — т.е. вы не пробовали?
> Скажите, зачем Вы пытаетесь доказать, что contrib.admin это лучший инструмент из всех, хотя это далеко не так?
я пытаюсь доказать, что забить гвоздь молотком проще чем рукой.
я не просто «пробовал» — я сделал отдельную админку для того проекта — время на создание отдельной админки оказалось примерно равно времени, которое я перед этим потратил на «кастомизацию». Но справедливости ради стоит отметить, что начать писать свою админку сразу и сделать все как надо врядли получилось бы — апетит к заказчику приходил в процессе, сначала их вполне устраивал стандарнтный набор функций, потом появился один кастомный кусок, затем другой, третий и т.д.
насчет вот этого — «вам достаточно отнаследоваться и переопределить save() ваших моделей, что. сигнал можно повесить на автосоздание пермишенов для колонок при syncdb/migrate/… если очень хочется. вместо наследования можно разрулить с пом. метакласса. надеюсь пояснил что для чего.»
Причем тут save() модели и метаклассы для них? мало просто создать пермишен при создании/изменении модели. Надо еще организовать его обработку — а обработка как раз находится в ModelAdmin. Опять же, нельзя забывать о пользовательской части, я надеюсь вы понимаете, что тот способ, которым назначаются стандартные пермишены тут неприемлим. Значит придется писать еще и интерфейс для управления правами, а это тоже затраты сил и времени.
Причем тут save() модели и метаклассы для них? мало просто создать пермишен при создании/изменении модели. Надо еще организовать его обработку — а обработка как раз находится в ModelAdmin. Опять же, нельзя забывать о пользовательской части, я надеюсь вы понимаете, что тот способ, которым назначаются стандартные пермишены тут неприемлим. Значит придется писать еще и интерфейс для управления правами, а это тоже затраты сил и времени.
UFO just landed and posted this here
Вас заминусовали очевидно потому, что вы не правы. Автор топика решает вопрос ручками (это тоже бывает интересно и познавательно), но для Django есть большое количество готовых решений, которые представляют не только инструменты для загрузки изображений и создания миниатюр, но и полноценный набор фильтров, инструментов редактирования, управления галереями и т.д. Например, django-photologue.
UFO just landed and posted this here
у меня вопрос.
<script type=«text/javascript» src="/media/js/admin/base.js"></script>
разве там не должен быть
<script type=«text/javascript» src="/media/js/admin/display_thumbs.js"></script>
ведь именно этот файл мы создали и поместили в media/js/admin
или я что то недопонимаю, просто в
django/contrib/admin/media/js/afmin его тоже нет!!!
<script type=«text/javascript» src="/media/js/admin/base.js"></script>
разве там не должен быть
<script type=«text/javascript» src="/media/js/admin/display_thumbs.js"></script>
ведь именно этот файл мы создали и поместили в media/js/admin
или я что то недопонимаю, просто в
django/contrib/admin/media/js/afmin его тоже нет!!!
Sign up to leave a comment.
Допиливаем админку бензопилой. Часть I — Thumbnails