Re: Model icons
Hello!
Really useful idea, I think! 2 points about it:
1. Syntax
I would also remove the html from the models, but probably in this way:
class Hammer(models.Model):
...
Meta:
icon = ModelIcon("🔨")
There would be something like
ModelIcon.as_html(self, model_name:str) -> str:
"""returns whatever html should be used in the admin"""
or a ModelIcon.set_text(self, text: str) and we'd use a simple
str(model_icon) in the templates.
That way, it could be extended easily in a
FontAwesomeModelIcon("fa-hammer") and a BootstrapModelIcon("bi-hammer")
for example, and maybe get whatever extra arguments they may need, like
FontAwesomeModelIcon("fa-hammer", thickness="solid").
2. Make it more widely useful
I like the fact that it's in the model itself and not in the modeladmin,
as it allows to use it elsewhere, like in the __str__ to quickly add
this visual indication of the class. Boostrap and co would have to
provide a non-html version of the icon or return an empty string though.
Le 21/02/2023 à 01:31, Marty a écrit :
I really like the idea to add just a simple 'icon' attribute. That's
quite elegant solution. Thanks, Mark! 🙂
On Monday, February 20, 2023 at 2:33:43 PM UTC+1 Jacob Rief wrote:
I agree with Adam Johnson that adding HTML to the model class is a
bit too coupled.
But I like the idea of Mark Niehues to add them to the ModelAdmin
class, although I would allow a HTML/SVG snippet rather than a CSS
class.
* How would we then handle 3rd party apps providing their own
SVG file to be used as icon?
* Shouldn't that icon definition be part of the ModelAdmin's
Media subclass?
– Jacob
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/45c143cc-2716-430a-93cf-7c2a938640ccn%40googlegroups.com
.
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/890a79aa-578f-0b06-95cb-33f660baecd2%40brice.xyz.
keepdb with flush option
Hi everyone, Right now, when testing, we have the choice to either : * create a new empty database to launch the tests with * reuse an existing database with all its data (--keepdb) I think we're missing a third option, here : * reuse an existing database, but flush its contents before (or after, or both) launching the tests (--flushdb? --keepdb --flush?) The reason for that is that we don't always want to/may give django's db user the ability to create and delete database, but we may still want to start with a fresh one (otherwise, we wouldn't need --keepdb, it would be the normal behaviour). As there's already a management command to flush the db, I don't expect this to be a huge work, but I might be missing something. If there's already a way to do that without creating a custom test runner, thanks for pointing me at it and sorry for your time! Any thoughts ? -Brice -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1cce7310-792c-7693-fbd4-ccba9d463f38%40brice.xyz. For more options, visit https://groups.google.com/d/optout.
Re: Feedback wanted for API to support for multi file upload
Hi Joe,
Just an idea:
Why not just use another keyword argument, like "files_number", "count",
"max_files" (along maybe with a "min_files"), or something like, with a
default of 1 (to match current behaviour with a single file), and an
allowed value of 0 for infinite?
If you allow multiple files upload at once, chances are that there will
be many use cases for limiting the number of uploads to a specific
range/value.
Not sure about the form's implementation, though.
- Brice
Le 25/08/2018 à 21:05, Johannes Hoppe a écrit :
Hi there!
I do need some feedback on the best public API to implement multi file
support to Django forms.
Context:
Up until now Django forms do not support multi file upload. You will
need to write your own view to handle the files as described here:
https://docs.djangoproject.com/en/2.1/topics/http/file-uploads/#uploading-multiple-files
Of course it is not too hard to implement actual multi file support as
I have been showcasing here:
https://github.com/django/django/pull/9011/files
The question is now to best add support for multiple file uploads
without wrecking backwards compatibility?
As Tim wisely mentioned, it might be confusing to add a `multiple`
argument to the FileField while also having the
|
attrs={'multiple':True}
|
still in the mix.
My suggestion would be to add the new keyword argument which enable
the new behavior and keep the attr-thing as is.
I could add a warning if someone uses the "old" style. It is a bit
suggestive though.
What do you think, mabe look at the documentation changes in the PR
for more context.
Best
-Joe
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com
.
To post to this group, send email to
django-developers@googlegroups.com
.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/e71675d3-be96-4189-b0c1-038774626284%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/73de1c91-dc5c-9b72-10fc-af37e36c50a2%40brice.xyz.
For more options, visit https://groups.google.com/d/optout.
Re: Proposal to format Django using black
Le 17/4/19 à 2:33, Dan Davis a écrit : +1 isort -1 black I think that codestyle checkers are better, because you teach yourself proper style for python. I'm in a team in which we've enforced Black a bit more than a year ago, and I can tell you that now, everyone code in a blackish style from start. Black is still always executed, but doesn't make any change most of the time. It's just there to enforce the style, for newcomers and if we sometimes make some style mistakes. A big win here. [snip] -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/23ba5efe-f290-c3d7-e24f-8e109d61efb9%40brice.xyz. For more options, visit https://groups.google.com/d/optout.
