Re: Cookies with Django

[Jacob Rief]

Hi Uri,
we are running a large Django site in Austria. As cookies we use 
session-ids, csrf-tokens and the preferred language. By our legal team, 
they all are considered as strictly necessary and hence we do not have to 
ask for consent from our users. This btw. only applies to assets served by 
our own servers. If you add IFrames, embed YouTube videos or even OSM 
tiles, you should ask for consent, because then you might expose your users 
to 3rd party cookies. 
– 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/412c505a-0304-4885-92e9-e3d182f3438dn%40googlegroups.com.

Re: Proposal on how add configuration options to Email Backends

[Jacob Rief]

There is a ticket for this feature request now:
https://code.djangoproject.com/ticket/35514#ticket

-- 
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/5440e193-2576-4413-8f4d-ebc79b43a449n%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

[Jacob Rief]

In such cases, you really do need Django's current CSRF protection. 
Personally I wouldn't mind it being off by default, since SameSite=Lax 
seems to be enough for most cases, but this could be a footgun for some 
people.


This could be handled by the configuration checker, which runs after 
reading the setup. Whenever CSRF_COOKIE_SAMESITE=None but 
'django.middleware.csrf.CsrfViewMiddleware' is missing in the MIDDLEWARE 
 
setting, a warning shall be issued.

– 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/4e9c5627-3f29-48aa-bf4d-65ec4df179e8n%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

[Jacob Rief]

On Monday, April 17, 2023 at 8:45:16 AM UTC+2 Curtis Maloney wrote:

Are you implying that all CSRF attacks protected by Django's current 
machinery are entirely mitigated by SameSite=Lax on the _session_ cookiue?

Yes. Therefore imho, the CSRF protection is just some nasty legacy, 
developers have to fiddle with. It doesn't add any security benefit anymore.
That said, maybe there is still a possible attack vector on cross site 
request forgeries, but I was unable to exploit them with disabled CSRF 
protection.
Therefore it would be great, if someone with more hacking experience than 
myself, could try this.

– 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/18aaa4cf-4612-4373-bd91-90cfb3fd07b8n%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

[Jacob Rief]

Actually, I attempted to forge POST requests on Django with disabled CSRF 
protection – and failed.
Maybe I wasn't creative enough, but modern browsers do indeed have a good 
protection against this attack vector.
I therefore welcome this proposal, unless someone can show how to bypass 
this protection.
– 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/2b349cdb-7502-4d6d-b299-cf62e1edc265n%40googlegroups.com.

Re: Feedback for my draft proposal

[Jacob Rief]

Hi Jayant,
before inventing the wheel a second time, did you have a look at these 
Cookiecutter templates?
https://github.com/cookiecutter/cookiecutter-django

They probably are all you need for the purpose you're proposing.

– 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/7d6a3dcd-9eda-429d-8252-8d872555bd3dn%40googlegroups.com.

Re: Exporting some of the `datetime` functions from `django.utils.timezone`

[Jacob Rief]

I find it confusing that we have to import now from django.utils.timezone, 
but timedelta from Python's internal datetime.
This btw. is a violation of the Law of Demeter 
, hence I agree with Suayip's 
proposal.

– Jacob

On Monday, March 20, 2023 at 10:09:02 AM UTC+1 Mariusz Felisiak wrote:

I'm strongly against it. Things should be imported from source modules, not 
cross-imported from Django modules just because we use them. This is 
confusing to the users who might have the impression that 
`django.utils.timezone.timedelta` is more than `datetime.timedelta`, which 
is not True.

-- 
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/4c5d6229-49d5-41b2-9d08-2a185c584952n%40googlegroups.com.

Re: Model icons

[Jacob Rief]

On Thu, Feb 23, 2023 at 7:38 AM Brice Parent  wrote:

> 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.
>
> In my opinion, Django models shall not have to specify parts of their
representation layer, such as icons.
This shall be left exclusively to the view layer: The ModelAdmin is such a
candidate.

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").
>
> I don't like the idea that Django becomes dependent on any
UTF-8-Symbol/Dingbats/Emojis/Glyphicon/Font-Awesome/Bootstrap/Remix/etc-Iconset.
Some Models might have a purpose which can not be mapped to any of those
icons and need to be custom designed.


> 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.
>
> That's a violation of the well established MVC pattern of keeping the
visual part in the view, and the "business model" within the model.

Just my 2 cents
– 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/CAJ_HXxpnzW-bA%2BrJwBZC67CRwb0ss%2B0mmT6fZ6VAh1PDuhucGg%40mail.gmail.com.

Re: Model icons

[Jacob Rief]

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/a5e570a9-5cba-442c-abe6-435b320d5579n%40googlegroups.com.

Re: dynamically added INSTALLED_APPS

[Jacob Rief]

Isn't it a bit dangerous to auto-add a package from PyPI to a running 
Django installation? That module then gains full database access and could 
do all kind of nasty stuff.
Maybe I am a bit naive here, but 3rd party packages sometimes get installed 
incautiously.
– 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/8c725ee5-3d05-4baf-a1a0-134334cac465n%40googlegroups.com.

Re: Multiple instances of DjangoAdmin share the same model LogEntry

[Jacob Rief]

Hi Adam,
I'm currently preparing a pull request on this. No changes will be made to 
the model LogEntry. It will just allow implementers to filter
log entries by registered models (of that instantiated admin). Not doing 
this, in my opinion is unexpected behaviour anyway.
Thanks to Carlton for pointing this out.

We therefore should change the subject of this post to "Optionally filter 
LogEntry by registered model".

– 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/d7f30f1a-a358-4459-bbcf-9308abc78157n%40googlegroups.com.

Re: Multiple instances of DjangoAdmin share the same model LogEntry

[Jacob Rief]

Hi Carlton,
that proposal makes a lot of sense.

This means that one could for instance add a custom function to that 
context which, if set, would be called
by the AdminLogNode.render method and then overrides the 
context[self.varname].
How would you name that extra context variable, maybe "render_log_entries"?
Another approach would be to move the functionality of method render into 
the class AdminSite. This would
allow Django implementers to override the way, log entries are rendered.

This would be a minimalistic change to the existing code base but would 
allow to change the rendering
of log entries in a much more flexible way.

Shall I create a ticket and a proof of concept?

– 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/e50bce39-d1dd-44b5-9fae-fc1bc8c9c864n%40googlegroups.com.

Re: Multiple instances of DjangoAdmin share the same model LogEntry

[Jacob Rief]

Hi Carlton,

As I understand it, separate admin sites may register different models, but 
I'm only going to see the History for instances that are visible to the 
current admin no? 

The Django admin interface uses a templatetag named get_admin_log. It 
renders the content of all entries of model LogEntry filtered by the 
current user.
Check here for 
details: 
https://github.com/django/django/blob/34b328814976a2e2f7907361a494202763649f3f/django/contrib/admin/templatetags/log.py#L14
If you instantiate more than one Django-Admin interface, the logged in user 
therefore sees all his actions, regardless of the chosen admin instance.

My proposal would be to add another column to LogLevel containing the name 
of the admin interface. That column then shall be used as an additional 
filter. 
It should also be possible to swap that model against a compatible 
implementation, for instance if someone separates the admin interface 
because he also
separated the underlying databases.
 
Maybe you mean the Recent actions > My actions bit of the index page? (I 
didn't check but, if not already, could that list be filtered by the 
content type of registered models for the current admin? 🤔)

Yes, that's what I wrote and intended.

– 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/bfcd58e8-bbf1-42bc-a7dc-25a788e47b1en%40googlegroups.com.

Multiple instances of DjangoAdmin share the same model LogEntry

[Jacob Rief]

If someone uses two or more instances of the Django Admin interface,
the sidebar on the right containing the "Recent actions", shares the same
information for all instances of the Django Admin interface.
This is because the model LogEntry is a singleton and shared across all
instances of the Django Admin interface.
As a consequence this may be confusing to some users, since they might
expect that the log entries are bound to the current user interface.

I had a look at the code and although it is possible to create separate 
entries
for those logs, this is really complicated and requires a lot of work. 
Therefore
I wanted to ask, if it would make sense to allow each instance of a Django
Admin to specify its own model used to log entries? The default would of
course be to fall back on the current behaviour.

I have some ideas on how to achieve this. An instantiation
of a Django Admin could specify its own model similar to LogEntry
which itself should inherit from a class named AbstractLogEntry (which
doesn't yet exist). This would also allow integrators to extend this class 
with
additional columns for extra log entries.

– 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/38c055d3-58ef-4a73-9784-be6877e31b2cn%40googlegroups.com.

Re: (Circa end of 2021) Localization issues with input type=date?

[Jacob Rief]

How about ditching the JS based datepicker altogether and replace it 
against the built-in datepicker offered by modern browsers? This would also 
help users of mobile devices because they already have good internal 
implementations to select a date. I agree that on desktop browsers the 
built-in datepicker does not really look nice, but IMO still works way 
better than the  widget, (ab-)used for date types as 
currently implemented in Django. 

A compromise for the Django Admin could be to detect the CSS query "@media 
(pointer:coarse)". If this matches, it's a mobile device and we can fall 
back on the internal date selector. Otherwise use a nice looking JS 
implementation.

There is a good article on CSS Tricks about date input types:
https://css-tricks.com/better-form-inputs-for-better-mobile-user-experiences/#aa-a-quick-detour-into-date-types

Btw., since PR#15806  is 
stale, may I reclaim it?

– 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/8411cb4f-b93c-4e5b-9dd4-d540baee83a1n%40googlegroups.com.

Re: Proposal: Add An in-memory data storage backend in Django

[Jacob Rief]

Big +1 from my side.
(Would indeed help me to write more portable unit tests.)

– 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/e151d10a-22cf-41f8-bd7b-181b622dbc2an%40googlegroups.com.

Re: Proposal: Add utility class "ClassList"

[Jacob Rief]

Hey Carlton,
in my opinion, the main use case would be to improve type safety, 
readability and to add a
utility class for 3rd party packages. Someday, Django may add type hints 
and then this would
be really beneficial.

In Django itself, the mentioned method css_classes 
<https://github.com/django/django/blob/main/django/forms/boundfield.py#L211-L222>
 does 
not offer any type safety;
the passed in argument extra_classes can be None, a string containing a 
single
CSS class or list containing those classes.

By adding such a utility class, we can rewrite the above method to

css_classes(extra_classes: ClassList):
# optionally: extra_classes = ClassList(extra_classes)
extra_classes.toggle(getattr(self.form, "error_css_class", None), 
self.errors)
extra_classes.toggle(getattr(self.form, "required_css_class", None), 
self.field.required)
return extra_classes

which is much easier to read.

In my project django-formset <https://github.com/jrief/django-formset>, I 
was able to remove a lot of boilerplate, by introducing that class.

Naming that Python class ClassSet or CSSClassSet or CSSClasses might be a 
better option.
I used ClassList because that's the name in JavaScript.

– Jacob  


On Thursday, September 29, 2022 at 9:35:02 AM UTC+1 Carlton Gibson wrote:

> Hey Jacob. Thanks for this. 
>
> Can I ask you to give a few examples of potential usages in Django, and 
> showing the gain over use a set in these cases? 
>
> I'm trying to imagine exactly what you have in mind, but I'm not entirely 
> clear. 
>
> Thanks again. 
> Carlton
>
> On Friday, 23 September 2022 at 11:14:27 UTC+2 Jacob Rief wrote:
>
>> In JavaScript each HTMLElement has a property named classList 
>> <https://developer.mozilla.org/en-US/docs/Web/API/Element/classList>. 
>> This actually is a set allowing to *add* a single CSS class string, 
>> *remove* it
>> and/or *toggle* it.
>>
>> If we would reimplement this as a Python class, methods such as
>> css_classes 
>> <https://github.com/django/django/blob/main/django/forms/boundfield.py#L211-L222>
>>  
>> could be implemented as a one-liner. This would also be beneficial
>> for future uses of similar methods in Django and 3rd party libraries, 
>> because it is a quite
>> common use case that one has to change the list of CSS classes as an 
>> element
>> attribute.
>>
>> – 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/6d01cf69-23eb-4e8a-a13e-b29f26deab7an%40googlegroups.com.

Proposal: Add utility class "ClassList"

[Jacob Rief]

In JavaScript each HTMLElement has a property named classList 
. 
This actually is a set allowing to *add* a single CSS class string, *remove* 
it
and/or *toggle* it.

If we would reimplement this as a Python class, methods such as
css_classes 

 
could be implemented as a one-liner. This would also be beneficial
for future uses of similar methods in Django and 3rd party libraries, 
because it is a quite
common use case that one has to change the list of CSS classes as an element
attribute.

– 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/eecbea4e-84f8-4aef-8998-26ff96a82bc0n%40googlegroups.com.

Re: More user friendly delete confirmation template

[Jacob Rief]

On Wednesday, August 17, 2022 at 7:23:35 AM UTC+2 Carlton Gibson wrote:

> > Can we at least agree to put an id="..." onto the  element wrapping 
> that list.
>
> That seems pretty minimal. 🙂  Do you want to open a PR so we can have a 
> look? 
>

Okay, will do that.
Any suggestions for a name? My proposal is id="deleted-objects".

– 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/5dd47fd5-adcb-4a28-934f-8d132c3c540cn%40googlegroups.com.

Re: More user friendly delete confirmation template

[Jacob Rief]

Can we at least agree to put an id="..." onto the  element wrapping 
that list.
That would help me to add some JS and CSS to the overwritten 
delete_selected_confirmation template without
having to copy a huge block of HTML code from that template.

– 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/1bbb2f37-765d-4bcf-83d6-7ddc04dd5edcn%40googlegroups.com.

Re: More user friendly delete confirmation template

[Jacob Rief]

The least intrusive change would be to add an id="..." to the -element 
wrapping that list.
This at least allows me to add such a Javascript snippet into {% block 
extrahead %}.

– 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/c1127d9a-e1f9-45fc-9104-0b478f18ee6dn%40googlegroups.com.

Re: More user friendly delete confirmation template

[Jacob Rief]

On Tuesday, August 16, 2022 at 4:23:03 PM UTC+2 Carlton Gibson wrote:

>
> Then as Maxim points out, this is already possible with overriding the 
> template. 
>
>
That's what I did of course in the first place. It however turns out that 
you have to copy quite a bunch of boilerplate code, the complete {% block 
content %}, in order to add a tiny Javascript snippet.
Since Django templates can evolve considerably between versions, this can 
lead to other side effects after upgrading.
An alternative would be add a {% block objects_to_be_deleted %} around the 
list of objects-to-be-deleted. This at least would allow to simpler extend 
that template. 

> I would argue that if the list of objects is "overwhelming" / 
> "unsettling", then this is perhaps an indicator that the admin interface is 
> being used beyond its intended scope. The admin is designed for site 
> administrators, mostly developers. Yes, most projects seem to push it 
> beyond that, but we can't make it something for all people.
>
Well Django-CMS is built around the Django-Admin user interface and its 
users typically are not site administrators. Moreover, why would Django 
offer
a sophisticated permission framework, if the only users being "allowed" to 
work with the Django-Admin are "site administrators".

Side note, if you're unfamiliar with Django-CMS: Whenever you delete a 
CMS-page, you also delete its page-titles, placeholders and their plugins, 
which can lead to a really long list of objects to be deleted.

– 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/7c900403-5aca-47e0-9c4d-23c77b8b174dn%40googlegroups.com.

More user friendly delete confirmation template

[Jacob Rief]

Whenever a user attempts to delete an object inside the Django admin,
a delete confirmation page is shown. If the object to be deleted contains
many relations, the user is overwhelmed with a list of other objects to be
deleted together with the current object. Often those objects are just
internal relations the user never heard of, and this may be unsettling.

I therefore propose to hide those related objects behind a link named
"Show related object to delete"
If the user clicks on that link, the complete list of objects to be deleted 
is
expanded into the confirmation page. This also prevents having to scroll
down to the end of a potentially very long page in order to confirm the
deletion by clicking on "Yes I'm sure".

[image: Screenshot 2022-08-16 at 13.34.46.png]

– 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/e59f0771-cb65-4564-ace4-50a7ffd96cf6n%40googlegroups.com.

Re: UI/UX - FilteredSelectMultiple - Filtering the selected options

[Jacob Rief]

I'have implemented such a widget in django-formset 
. It just hides (removes) the selected 
options which have been filtered out.
Otherwise, filtering by muting options, wouldn't have the desired visual 
effect.

Please note that in order to implement this feature, I used three  elements, two of them visible (the left
and right one) and one hidden, which contains the currently selected 
options, even if filtered. A nice side-effect of this
architecture is, that it allows autocompletion for long source lists, and 
in addition, undoing and redoing a selection.

Please check in the link from above the example:
 *> Default *(or any other CSS framework) *> Opinion*.

– 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/c4e152b7-2cb5-4dec-8f0e-6b18ac100d18n%40googlegroups.com.

Re: Feature Request: New PostgreSQL ArrayField

[Jacob Rief]

Hello Liamine,
Django offers a JSONField 
 which 
can be used to store an array.
You can use it to store a list of prices. What's the benefit of using an 
array instead of JSON?
– 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/45971297-a63f-4409-8ee0-357cbed31fe0n%40googlegroups.com.

Re: Custom Ordering and Grouping of Models in Django Admin

[Jacob Rief]

Hi Mariusz,

On Thursday, June 16, 2022 at 7:20:23 PM UTC+2 Mariusz Felisiak wrote:

> It's already solved in Django 4.1+ by 
> https://github.com/django/django/commit/2bee0b4328319eaf6a0d1686677d629f2ecf6dec.
>  
> You can now override get_app_list() to change the default order on the 
> admin index page. See docs 
> 
> .
>

Thanks and ups, apparently I missed that.
This indeed makes life much easier, because now I only have to override 
method AdminSite.get_app_list which is much shorter.
– 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/5719b10b-23bc-4f54-9db2-361712637304n%40googlegroups.com.

Re: Custom Ordering and Grouping of Models in Django Admin

[Jacob Rief]

Hi,
just encountered this same problem today.
As Roman reported in ticket-32484 
:

> Sometimes model names are so unfortunate that default alphabetical order 
> of models in contrib.admin application makes no sense at all.
> The same applies to applications themselves. When there are many 
> applications or many models within application there is a natural need to 
> group them up logically.
>
> Reordering of models is covered in many online resources, but the very 
> process is so inconsistent and complex, that few get it right.
>
I would like to propose the following solution:

We add a new method order_models (or sort_models) to class admin.AdminSite. 
This method then sorts the models according to its own
logic and defaults to models.sort(key=lambda x: x["name"]). Whenever 
someone wants to sort his models otherwise, he just has to
override this method. This new method then is called by 
AdminSite.get_app_list and AdminSite.app_index.

The alternative I had to use today, was to override both methods, 
get_app_list and app_index to override just the model sorting part –
I therefore had to copy & paste 30 lines of Django code to replace just one 
function!

It btw. is much DRYer to implement the sorting of something into an 
external overridable method, rather than implementing this twice, as in both
methods just mentioned.

If the named ticket is reopened, I will implement this.

– 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/196da0a6-2ad7-4067-b893-64fb987483e9n%40googlegroups.com.

Re: Status of 4.1 pre-release.

[Jacob Rief]

Hi Carlton,
there is somehow a contradiction:
In https://code.djangoproject.com/wiki/Version4.1Roadmap it's written:

Better yet, find someone to review your patch and mark the ticket as "Ready 
> for checkin".
>

but 
https://docs.djangoproject.com/en/4.0/faq/contributing/#i-m-sure-my-ticket-is-absolutely-100-perfect-can-i-mark-it-as-ready-for-checkin-myself
states:
 

> ’m sure my ticket is absolutely 100% perfect, can I mark it as “Ready For 
> Checkin” myself?
>
> Sorry, no. It’s always better to get another set of eyes on a ticket. If 
> you’re having trouble getting that second set of eyes, see questions above.
>
 
I'm actually asking, because of this I left one of my tickets 
 on "Accepted".

Kind Regards,
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/b4e386d5-b8be-4880-aa29-0c923c986518n%40googlegroups.com.

Re: For discussion: JSON-aware views for error responses

[Jacob Rief]

I encountered this problem many times myself, so I'm +1 for this proposal. 

– 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/639a72d1-ae5d-4bae-bd28-b3b5f1d2d955n%40googlegroups.com.

Re: Ticket #21289 - Login rate limiting

[Jacob Rief]

How about this proposal?

Someone opens the login page. In addition to the visible 
fields username and password and the hidden field csrftoken we add another 
hidden field. This field contains the earliest (server-)timestamp a user 
might login, and lies in the near future, for instance now() + 
timedelta(seconds=5). That value is cryptographically signed 

.

In addition to this, we disable the submit button and add a small 
Javascript function which sets an interval corresponding to the mandatory 
login delay. After that interval expired, the submit button is enabled 
again.

A malicious client who bypasses the disabled button and attempts to submit 
the login for, will receive a HTTP response with an error code > 400.

What are the advantages?

   - Django doesn't have to store any state of users and/or IP addresses 
   attempting to log in.
   - Django doesn't have to delay itself to throttle requests. This btw. is 
   a DoS attack vector by blocking server threads.
   - We transfer responsibility for delaying login requests to the client – 
   who can't bypass them.

-- 
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/b64d44a3-c7dd-4f9a-bf4f-1b8e9818fb64n%40googlegroups.com.

Re: Issue with documentation page

[Jacob Rief]

The SSL certificate for docs.djangoproject.com was issued on December, 6th 
and is valid until March 6th, so that's not the problem.

You're accessing that site through a misconfigured proxy, that's the 
problem.

-- 
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/1d74a73e-4d4f-4bbc-b803-00081b2f9948n%40googlegroups.com.

Re: Proposal on how add configuration options to Email Backends

[Jacob Rief]

On Monday, January 31, 2022 at 7:55:47 AM UTC+1 f.apo...@gmail.com wrote:

> Okay then,
>
> some of the things like sender reputation and different bounce hooks came 
> to my mind as well, but it is good to hear confirmation from others. I 
> think the next steps would be to create a new ticket to add support for 
> *multiple* email backends and then work from that (I would only link the 
> old ticket since it's scope was mainly putting the config into a dict as 
> opposed to multiple backends). Given that there are plenty of +1 here 
> already I think we already have our implementors? :)
>
> Some items that I like to see addressed in a PR:
>  * Backwards compat
>  * Similarity to Caches & Databases (ie so we don't invent yet another 
> syntax)
>  * Support for connection aliases (default/…) in send_email % friends 
> (basically everything taking a connection now should probably take aliases 
> as well)
>

OK. Since I made the proposal, it then is probably up to me to create the 
ticket.  

-- 
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/9f15a814-5424-46f7-8d91-fd4303d58579n%40googlegroups.com.

Re: Proposal on how add configuration options to Email Backends

[Jacob Rief]

Well, that ticket is 8 years old and in the meantime other email backends 
have emerged, requiring different configuration options.
I made this proposal after attempting to fix a 14 year old open ticket 
#6989 but this was ultimately postponed, see comment by
Carlton Gibson on 
https://github.com/django/django/pull/13728#issuecomment-987762791

To summarize the discussion from 7 years ago

Collin Anderson wrote:

> I don't see any benefit to moving email settings to a dictionary. It is 
> helpful for databases and caches because there can be multiple backends.  

It makes the popular "from local_settings import *" convention harder to 
> use. What's wrong with 6 individual settings? If the goal is to allow

multiple email backends, then let's make that the ticket goal.

 
and Carl Meyer replied:

> I agree with Collin; unless we are adding new capabilities (i.e. multiple 
> configured email backends, which it seems nobody really wants), it's hard 

to find any actual benefit from this change to justify the churn (and the 
> additional complexities of working with dictionary settings in 
> partial-override scenarios).

 
why shouldn't it makes sense to have different email backends? If you have 
a staging system you may want to use you local SMTP-relay, while in 
production
you may for instance use AWSs SES 
 service. That 
service may require additional configuration settings not available in the 
local smtp backend.
I can also imagine that in some situations it may make sense to have two 
email backends concurrently. We maybe should rethink about that.

-- 
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/bcbd308a-217c-44eb-b96a-3a487683a345n%40googlegroups.com.

Proposal on how add configuration options to Email Backends

[Jacob Rief]

This proposal attempts to address the following issues:
https://code.djangoproject.com/ticket/6989  (14 years old)
https://github.com/django/django/pull/13728
and
https://code.djangoproject.com/ticket/31885
https://github.com/django/django/pull/13305

Currently all the parameters to configure the email backend are located
in the global namespace, typically starting with EMAIL_...
This in the past led to discussions whenever a new configuration parameter
was required, because it added another entry to the yet too long list of 
configuration
settings.

Since Django allows us to use more than one email backend concurrently,
why don't we configure them in a similar way as we already do it with
database, caching or template engine backends?

Such a configuration setting then may look like:

EMAIL = [
{
'BACKEND': 'django.core.mail.backends.smtp.EmailBackend',
'HOST': 'smtp.example.org',
'HOST_USER': 'smtp_user',
'HOST_PASSWORD': 'smtp_secret',
'PORT': 25,
'FQDN': 'example.org',
# all other related directives 
}
]

This would allow each email backend to "bring" its own configuration 
settings
contained in their own dictionary. Adding extra settings to this dict will 
certainly
lead to less discussions as we currently have.

Personally, I would prefer SMTP = {...} as the main configuration 
directive, but EMAIL seems to be more popular in Django.

This would mean that the configuration directives starting from here 
 will 
have
to be replaced, by their counterparts as explained before.

-- 
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/73f2e1b5-48c7-4331-9041-d6537cda6b7cn%40googlegroups.com.

Re: Admin webcomponents

[Jacob Rief]

In the past month, I have written a webcomponent, which encapsulates most 
of the functionality the Django admin's change view implements.
It is very Pythonic/Djangonic in the sense, that it does not require to 
write any JavaScript, nor HTML. You can just use your Django Form
as usual, warp it inside that component ... 
and use a slightly modified Django View.

Here is a list of additional features:

   - Before submitting, our Form is prevalidated by the browser, using the 
   constraints we defined for each Django Field.
   - The Form's data is send by an Ajax request, preventing a full page 
   reload. This gives a much better user experience.
   - Server side validation errors are sent back to the browser, and 
   rendered near the offending Form Field.
   - Non-field validation errors are renderer together with the form.
   - CSRF-tokens are handled through a Cookie, hence there is no need to 
   add that token to each form.
   - Forms can be rendered for different CSS frameworks using their 
   specific style-guides for arranging HTML. Currently *django-formset* 
includes 
   renderers for Bootstrap 
   , Bulma 
   , Foundation 
   , Tailwind 
    1 
   

and UIKit .
   - Support for all standard widgets Django currently offers. This also 
   includes radio buttons and multiple checkboxes with options.
   - File uploads are handled asynchronously. This means that the user 
   opens the file dialog or drags a file to the form. This file then is 
   uploaded immediately to a temporary folder, returning a unique handle 
   together with a thumbnail of it. On form submission, this handle then is 
   used to access that file and proceeds as usual.
   - Select boxes with too many entries, can be filtered by the server 
   using a search query. No extra endpoint is required for this feature.
   - Radio buttons and multiple checkboxes with only a few fields can be 
   rendered inlined rather than beneath each other.
   - The Submit buttons can be configured as a chain of actions. It for 
   instance is possible to change the CSS depending on success or failure, add 
   delays and specify the further proceedings. This for instance allows to 
   specify the success page in HTML rather than in the Django View.
   - A Formset can group multiple Forms into a collection. On submission, 
   this collection then is sent to the server as a group a separate entities. 
   After all Forms have been validated, the submitted data is provided as a 
   nested Python dictionary.
   - Such a Form-Collection can be declared to have many Form entities of 
   the same kind. This allows to create siblings of Forms, similar the 
   Django's Admin Inline Forms. However, each of these siblings can contain 
   other Form-Collections, which themselves can also be declared as siblings. 
   This list of siblings can be extended or reduced using one "Add" and 
   multiple "Remove" buttons.
   - By using the special 
   attributes show-if="condition", hide-if="condition" or 
disable-if="condition" on 
   input fields or fieldsets, one can hide or disable these marked fields. 
   This condition can evaluate all field values of the current Formset by a 
   Boolean expression.
   - The client part, has no dependencies to any JavaScript-framework. It 
   is written in pure TypeScript and compiles to a single, portable JS-file.

That library only runs with Django>=4 and will be announced together when 
Django-4.0 will be released. A working prototype can be found here:
https://github.com/jrief/django-formset

– 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/60ec115e-3aba-47d5-9a2b-f4f22ab21412n%40googlegroups.com.

Re: Developing an SPA version of Django admin

[Jacob Rief]

I really would like to see the django-admin being more SPA-like. I 
therefore wrote a library which implements all the features of the admin's 
change view
and much more. It is very Pythonic/Djangonic in the sense, that it does not 
require to write any JavaScript, nor HTML. You can just use your Django 
Forms
as usual in a slightly modified Django View.

Here is a list of features:

   - Before submitting, our Form is prevalidated by the browser, using the 
   constraints we defined for each Django Field.
   - The Form's data is send by an Ajax request, preventing a full page 
   reload. This gives a much better user experience.
   - Server side validation errors are sent back to the browser, and 
   rendered near the offending Form Field.
   - Non-field validation errors are renderer together with the form.
   - CSRF-tokens are handled through a Cookie, hence there is no need to 
   add that token to each form.
   - Forms can be rendered for different CSS frameworks using their 
   specific style-guides for arranging HTML. Currently *django-formset* 
includes 
   renderers for Bootstrap 
   , Bulma 
   , Foundation 
   , Tailwind 
    1 
   

and UIKit .
   - Support for all standard widgets Django currently offers. This also 
   includes radio buttons and multiple checkboxes with options.
   - File uploads are handled asynchronously. This means that the user 
   opens the file dialog or drags a file to the form. This file then is 
   uploaded immediately to a temporary folder, returning a unique handle 
   together with a thumbnail of it. On form submission, this handle then is 
   used to access that file and proceed as usual.
   - Select boxes with too many entries, can be filtered by the server 
   using a search query. No extra endpoint is required for this feature.
   - Radio buttons and multiple checkboxes with only a few fields can be 
   rendered inlined rather than beneath each other.
   - The Submit buttons can be configured as a chain of actions. It for 
   instance is possible to change the CSS depending on success or failure, add 
   delays and specify the further proceedings. This for instance allows to 
   specify the success page in HTML rather than in the Django View.
   - A Formset can group multiple Forms into a collection. On submission, 
   this collection then is sent to the server as a group a separate entities. 
   After all Forms have been validated, the submitted data is provided as a 
   nested Python dictionary.
   - Such a Form-Collection can be declared to have many Form entities of 
   the same kind. This allows to create siblings of Forms, similar the 
   Django's Admin Inline Forms. However, each of these siblings can contain 
   other Form-Collections, which themselves can also be declared as siblings. 
   This list of siblings can be extended or reduced using one "Add" and 
   multiple "Remove" buttons.
   - By using the special 
   attributes show-if="condition", hide-if="condition" or 
disable-if="condition" on 
   input fields or fieldsets, one can hide or disable these marked fields. 
   This condition can evaluate all field values of the current Formset by a 
   Boolean expression.
   - The client part, has no dependencies to any JavaScript-framework. It 
   is written in pure TypeScript and compiles to a single, portable JS-file.

That library only runs with Django>=4 and will be announced together when 
Django-4.0 will be released. A working prototype can be found here:
https://github.com/jrief/django-formset

– 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/5483f81a-1b78-465b-b181-7f01fa08777cn%40googlegroups.com.

Re: Django's issue tracker uses timezone CDT

[Jacob Rief]

On Monday, August 9, 2021 at 12:10:51 PM UTC+2 Adam Johnson wrote:

> I'd be +1 on moving the default to UTC.
>
> Or we could change Trac to pick up the browser's timezone offset and 
> display datetimes accordingly.
>

The latter world be the cleanest solution. I'm not familiar with Trac's 
template rendering engine, but in my opinion the timestamp shall be 
rendered as ISO-timestamp in UTC and then be converted to the browsers 
local timezone using a JS one-liner.

-- 
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/e0b10deb-d1d1-41ed-a41d-e85f35f1b32en%40googlegroups.com.

Django's issue tracker uses timezone CDT

[Jacob Rief]

This presumably is a legacy from the days when Adrian Holovaty and
Jacob Kaplan-Moss started the Django project in Kansas City.

The Django issue tracker uses the timezone CDT which is correct for central 
Americas,
but since Django became a world wide project, in my opinion this should 
either
be UTC, or if possible, the browser's local time.

Is there any reason, why this never has been adjusted?

– 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/9d952402-1efd-419e-b4a5-0f8635c1ac73n%40googlegroups.com.

Re: Removal of USE_L10N setting

[Jacob Rief]

I in favor with René Fleschenberg's proposal to enforce localization using 
a template filter.
It happened too often, that someone forgot to unlocalize a primary key in 
their templates
causing unwanted results.

-- 
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/88ec616c-0dfa-4858-b282-dcfe923572d3n%40googlegroups.com.

Re: Proposal to add attribute 'step' to FloatField and DecimalField

[Jacob Rief]

The problem with modulo on floats is, that due to rounding errors it often 
created weird results,
for instance in Python-3.8 this happens: 3.5 % 0.1 = 0.09981
This btw. also applies to the builtin divmod and math.fmod functions.
Therefore I proposed to do it via classic division and check if it's near 
enough to an integer value.

-- 
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/ce5717e1-db00-4c76-b98b-908a5202470bn%40googlegroups.com.

Re: Proposal to add attribute 'step' to FloatField and DecimalField

[Jacob Rief]

Say, you have a value and step, both are floats, then if value / step is 
can be represented
integer, the validation is fulfilled. Otherwise if the result has to be 
rounded to become an integer,
a ValidationError shall be raised.
Be aware of rounding errors.

On Sunday, March 21, 2021 at 9:53:43 PM UTC+1 kapilbansal...@gmail.com 
wrote:

> Hi everyone,
> I am working on this and I have a question.
> How to write validation check for this?
> Due to python floating point issues, I am not able to validate whether 
> field value is of given step_size or not
>

-- 
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/11953496-ad4c-49cd-857d-e8723692197bn%40googlegroups.com.

Re: Proposal to add attribute 'step' to FloatField and DecimalField

[Jacob Rief]

Great News!
So please accept ticket #32559 . 
I then will assign myself to it and implement it.
So I add step (or would you prefer step_value?) to IntegerField and 
FloatField, but not to DecimalField (because there it's handled through 
decimal_places).

-- 
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/b4a920d6-024f-4181-aef8-52fed51d40f2n%40googlegroups.com.

Re: Proposal to add attribute 'step' to FloatField and DecimalField

[Jacob Rief]

>
> We set maxlength/minlength on widgets for CharFields *because they map 
> from an already existing kwarg*. 
>
> For the case of `step` on a FloatField we’d need to add a kwarg — but 
> that’s only there to set a single attribute on the widget. 
>
> But FloatField also offers a min_value and max_value. When rendered as a 
widget, they are used as attributes min and max in their input
field. In addition to that, the field value is validated against a value in 
that range. To be consistent, the same should apply to the step value.
This would  furthermore allow the field to validate against a multiple of 
that step value. Such a feature currently has to be implemented on the 
project level.

I agree with Carlton that in the DecimalField this is handled by the 
attribute decimal_places.

– 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/e1402ecc-fa2b-47a8-ba79-f2d7f7f98f27n%40googlegroups.com.

Re: Proposal to add attribute 'step' to FloatField and DecimalField

[Jacob Rief]

On Wednesday, March 17, 2021 at 12:49:48 AM UTC+1 in...@markusholtermann.eu 
wrote:

> That sounds like a sensible feature. Do you want to open a ticket and 
> maybe implement it?
>

Hi Markus,
ticket #32559  has been issued 
to propose this feature.
If accepted I will assign myself to implement it.

– 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/061938e3-b44c-4a14-a343-fd8a6356fca2n%40googlegroups.com.

Proposal to add attribute 'step' to FloatField and DecimalField

[Jacob Rief]

If someone wants to use the step attribute as provided by the HTML field
 , she/he has to specify that using for instance
FloatField(widget=NumberInput(attrs={'step': 0.5})).

Since the HTML standard offers a step attribute on input fields of type 
number,
from my point of view, this feature shall be reflected by Django's 
FloatField and 
optionally DecimalField rather than having to parametrize the widget.

Min- and max-values are already supported by the FloatField, so the 
step-value
would make sense here as well. It furthermore would require to revalidate 
the
step-value by Django's Form validation, rather than by HTML alone.

– 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/9a35aa63-0d22-4353-8f58-70a181e05791n%40googlegroups.com.

Re: Add image and phone_number fields to Django User auth model

[Jacob Rief]

No they should not!

Django provides an easy way to extend (or replace) the built-in User model. 
There are far too many fields people might want to add and it would be a 
complete mess, if we would fulfill all of these requests.
Please refer to the docs 
at 
https://docs.djangoproject.com/en/3.1/topics/auth/customizing/#auth-custom-user

-- 
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/ade56f54-17da-4647-aab3-22909a113763n%40googlegroups.com.

Re: Adding Origin header checking to CSRF middleware (#16010)

[Jacob Rief]

Shouldn't we consider to put the CSRF token onto the deprecation list 
anyway?
All browsers released later than 2017 support the 'SameSite' cookie 
attribute , making the CSRF token 
obsolete.
I don't know what kind of policy the Django Project follows in deprecating 
browsers, but we can expect 
that IE, Edge<16, Safari<12, Chrome<51, etc. won't play a major role when 
Django-4 (or maybe 5?) will be released.

Strictly speaking, the CSRF token is a hack/workaround which in an ideal 
world shouldn't be required anyway.
And it always has been painful having to fiddle with it in my Django Form 
Views.

Just my two cents,
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/311bb8a8-5d84-4111-91ee-619ae8e8782an%40googlegroups.com.

Re: Replace the default django test runner to a more robust testing framework (like pytest)

[Jacob Rief]

There is already a ticket for this:
https://code.djangoproject.com/ticket/25707

I'm actually very much in favor of switching to pytest. In my newer 
projects I use pytest exclusively.

-- 
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/987d6da5-d1b0-455e-a33f-8e2865c18d40n%40googlegroups.com.

Re: Proposal: Make the domain part of the Email Message-ID configurable

[Jacob Rief]

Here is a pull request to fix https://code.djangoproject.com/ticket/6989 
https://github.com/django/django/pull/13728

-- 
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/d63bd685-ef45-4415-8fdf-d861f78843cfn%40googlegroups.com.

Re: Support for No-SQL database in Django

[Jacob Rief]

> Do you need aggregations, database functions, joins with filtering on
>> foreign keys, etc.? Then you should consider a relational database anyway.
>> Or would you just like to define models and have the Django admin
>> generate some nice editors for your non relational data-model?
>> If the latter is the case, then that's a valid point! In fact, maybe the
>> Django admin should provide hooks for extension, in order to add list- and
>> detail-views, not handled by the Django-ORM-to-Django-Admin mapper.
>
>

> Yes, the latter case you discussed is what I wanted. All I wanted was to
> have the same functionality as is there in SQL for NoSQL, and adding
> support for it in the admin section too
>

Then maybe you should propose to add the possibility for adding List- and
Detail-Views to the Django-Admin without an underlying Django-Model. You
could then
just use a normal Django Form and use it to edit your MongoDB model.

-- 
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/CAJ_HXxriZhLcSeYaUh5UseoT%2B%2B-gRCi5UQF7d1jzFfCaRE4U8w%40mail.gmail.com.

Re: Support for No-SQL database in Django

[Jacob Rief]

Hello Vineet,
you can perfectly use MongoDB together with Django. In fact I do that in 
one of my projects and where I use it, it perfectly makes sense.

The question you raised is, if the Django community can adopt the ORM for 
non-relational databases, such as MongoDB. I would say
no, for the same reasons as explained by Aymeric.

Now ask yourself why you want that.
Do you need aggregations, database functions, joins with filtering on 
foreign keys, etc.? Then you should consider a relational database anyway.
Or would you just like to define models and have the Django admin generate 
some nice editors for your non relational data-model?
If the latter is the case, then that's a valid point! In fact, maybe the 
Django admin should provide hooks for extension, in order to add list- and
detail-views, not handled by the Django-ORM-to-Django-Admin mapper.

Just my two cents ...

– 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/9166748c-8e2f-45d2-9ffd-14002e1116fen%40googlegroups.com.

Re: runserver MIME types on Windows

[Jacob Rief]

Hi Peter,
as a co-maintainer of django-filer I experienced similar problems. Often 
you can not rely on the MIME-type provided by the uploading browser.

In your situation, one possible solution would be to guess the MIME-type by 
looking at the magic header of the received file.
For this purpose you can use the filetype 
-library.

– 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/37df5e10-e0fa-4694-a933-93dddbcedf0dn%40googlegroups.com.

Proposal: Make the domain part of the Email Message-ID configurable

[Jacob Rief]

When Django's mail subsystem generates an email, it creates a unique 
Message-ID. This is a requirement specified in RFC2822 https://tools.ietf.org/html/rfc2822#section-3.6.4>.
The domain part of that Message-ID is generated by the Python network 
utilities. It defacto is the domain name determined by a reverse DNS lookup.

This can cause some problems:

   1. Django web services often run on private networks and its DNS 
   resolution could make that name quite common, such as 
   1.0.0.10.in-addr.arpa. This reduces the entropy to the generated 
   Message-IDs.
   2. It may expose some details of the internal network setup. Not every 
   sysadmin wants that.


Current state
The Message-ID is generated by:
django.core.mail.message.EmailMessage.message() 
Currently there is no way to configure the domain part inside this method.

Proposed state
Therefore I would suggest to add a new configuration directive to Django, 
say EMAIL_MESSAGEID_FQDN. Another possibility would be to allow to replace 
the hard-coded Message-ID generator email.utils.make_msgid() with a 
self-written callable.

-- 
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/97aa38e5-31e9-40c7-878b-08f87c031e91n%40googlegroups.com.

Re: f-strings again.

[Jacob Rief]

I strongly agree with Mariusz on

 I would also be in favor of keeping only %-formatting and f-strings in 
> Coding style docs. I don't see any reason to use also `format()` in a new 
> code.


so +1 from my side for f-strings.

Actually, in one of my side projects, %-formatting wouldn't even work, so 
`format()`, or the newer f-strings are an improvement in functionality.

- 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/15275abb-8f23-4732-bce5-be75426053eeo%40googlegroups.com.

Re: Admin webcomponents

[Jacob Rief]

I'm very much in favor of this. Getting rid of jQuery is a very important 
step to make Django future-prove.
In my other (non-legacy) projects, I currently replaced all JavaScript 
against webcomponents. I actually made good
experience with the StencilJS compiler. Compared to Svelte, I really 
appreciate the clean syntax and the readability
of the generated code of those components.

The big advantage of webcomponents is, that they play well together with 
all existing JavaScript frameworks
out there, hence embracing all developers using one of those. I recently 
found this article on Hackernews 

 
which
boils it down quite well.

Many years ago, I wrote a Django app to integrate client-side form 
validation with Django's server side logic.
See here  https://django-angular.awesto.com/combined_validation/
At that time it was based on AngularJS. The idea however remains the same 
and could well be applied to an
approach using webcomponents.

I'm very much interested in this topic, because I already implemented parts 
of this in AngularJS, although this now is
an obsolete technology.

– 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/0575817c-1130-4638-8e90-caa4e1cd04ebo%40googlegroups.com.

Re: Proposal: FileSystemFinder and AppDirectoriesFinder shall serve unminimized assets in DEBUG mode

[Jacob Rief]

On Friday, April 24, 2020 at 7:21:24 AM UTC+2, Carlton Gibson wrote:
>
> For instance if we were to include a compression step, you’d always just 
> reference the raw assets, these being processed, with source maps if we had 
> that, for production. 
>

It certainly is the proper approach to refer to the canonical 
representation of a file, rather than a transformed one. However in case of 
JavaScript and CSS assets, tools written in JavaScript (from my point of 
view) are much more sophisticated, rather than their Python equivalents. 
Therefore this step usually is performed outside of Django, usually within 
an npm run ... command. So unless Django embraces npm in order to execute 
the compile/compress/concatenate/uglify-steps, I don't see a lot of 
possibilities other than referring to the processed, aka *.min.xyz file.

-- 
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/372c5de7-b72d-45e5-b734-9042d8351aa8%40googlegroups.com.

Proposal: FileSystemFinder and AppDirectoriesFinder shall serve unminimized assets in DEBUG mode

[Jacob Rief]

When specifying paths to assets like JavaScript files, but also CSS, the 
Django documentation states: 

> Any links to the file in the codebase should point to the compressed 
> version. 
> 


This statement however does not properly reflect Django's internal handling 
of such assets, for instance in
https://github.com/django/django/blob/master/django/contrib/admin/helpers.py#L83-L84
https://github.com/django/django/blob/master/django/contrib/admin/options.py#L639-L648
https://github.com/django/django/blob/master/django/contrib/admin/options.py#L2026-L2028
https://github.com/django/django/blob/master/django/contrib/admin/widgets.py#L446-L460
we see, that Django only serves the minimized version of the file, when not 
in DEBUG mode.

This inconsistent handling of assets can cause other problems for third 
party apps, if they follow the documentation as show in the first link.
If in their Media definition they refer to the minimized version of a 
Django asset, say 'admin/js/vendor/jquery/jquery.min.js', then 
the automatic sorting does not work anymore in DEBUG mode. If on the other 
side they refer to 'admin/js/vendor/jquery/jquery.js',
then automatic sorting fails in production. 

There are two solutions to this problem.

*Either*

The documentation explicitly states that when a Media definition refers to 
internal Django assets, one *must* distinguish between the
minimized and unminimized version, just as Django's internal Media 
definitions do (see code examples above).
This however can easily be forgotten and errors therefore become visible 
only after deployment.

*Or*

We rewrite the FileSystemFinder and AppDirectoriesFinder so that in DEBUG 
mode, Django looks if an unminimized version
of the same asset exists, and if so it then serves that. Doing that 
automatically is easy, because the general convention is, that the .min
infix is always placed immediately before the .js- or .css file extension.

In many of my projects I therefore use these two alternative finders, which 
do exactly that:

import os
from django.conf import settings
from django.contrib.staticfiles.finders import (FileSystemFinder as 
FileSystemFinderBase, AppDirectoriesFinder as AppDirectoriesFinderBase)


class FileSystemFinder(FileSystemFinderBase):
"""
In debug mode, serve /static/any/asset.min.ext as /static/any/asset.ext
"""
locations = []
serve_unminimized = getattr(settings, 'DEBUG', False)

def find_location(self, root, path, prefix=None):
if self.serve_unminimized:
# search for the unminimized version, and if it exists, return it
base, ext = os.path.splitext(path)
base, minext = os.path.splitext(base)
if minext == '.min':
unminimized_path = super().find_location(root, base + ext, 
prefix)
if unminimized_path:
return unminimized_path
# otherwise proceed with the given one
path = super().find_location(root, path, prefix)
return path


class AppDirectoriesFinder(AppDirectoriesFinderBase):
serve_unminimized = getattr(settings, 'DEBUG', False)

def find_in_app(self, app, path):
matched_path = super().find_in_app(app, path)
if matched_path and self.serve_unminimized:
base, ext = os.path.splitext(matched_path)
base, minext = os.path.splitext(base)
if minext == '.min':
storage = self.storages.get(app, None)
path = base + ext
if storage.exists(path):
path = storage.path(path)
if path:
return path
return matched_path


In my opinion this approach makes Django's internal and 3rd party package 
code more readable, because it removes the clutter of
case distinction between DEBUG and production mode for each referred 
JavaScript and CSS asset. It also might be less error prone.


-- 
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/dd904eeb-a877-48d3-81fa-e72fe71a6735%40googlegroups.com.

Re: CrossDB JSONField — Testing needed.

[Jacob Rief]

The reason it behaves differently to jsonfield and jsonfield2 is that it 
does not use the built-in django.core.serializers.json.DjangoJSONEncoder. 
Therefore serializing Decimal fields fails.
In my opinion the basic types, such as Decimal and Date/Time fields shall 
be serializable to JSON, but apparently there are different opinions out 
there.

-- 
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/cc2b0a3b-1567-4da6-ac01-857bb808c356%40googlegroups.com.

Re: CrossDB JSONField — Testing needed.

[Jacob Rief]

Hi Carlton, hi Sage,
I just tested this implementation against my JSONField form editor library, 
namely django-entangled , using 
SQLIte.
As you can see from the testing matrix 
, everything works fine using 
the well known jsonfield  and 
jsonfield2 , which until Django-3 are 
the only viable options currently available for SQLite.

However, after switching to the new implementation using the built-in 
JSONField, one of my units tests does not pass 
. After 
examining this locally, I discovered, that the form
reports product_form._errors: {'properties': ['Value must be valid JSON.']}
The location where this exception is raised, is inside the JSONField's 
validate() 

 method. 
And the reason it is raised
is because json.dumps(value, cls=self.encoder) can not reparse a valid 
dictionary containing for instance a Python Decimal value.
Why should a valid Python dictionary be json.dumps(value, cls=self.encoder)
 anyway?

– 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/02f0df5e-3d9d-49c4-a81a-a1a2261a1b98%40googlegroups.com.

Re: CrossDB JSONField — Testing needed.

[Jacob Rief]

The error just reported, seems to be related to the use of Django's 
internal forms.DecimalField. If I change that to a FloatField, everything 
works as expected.

-- 
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/8fb68f8b-0d6a-429a-ac0f-89717089c531%40googlegroups.com.

Re: CrossDB JSONField — Testing needed.

[Jacob Rief]

Hi Carlton, hi Sage,
I just tested this implementation against my JSONField form editor library, 
namely django-entangled , using 
SQLIte.
As you can see from the testing matrix 
, everything works fine using 
the well known jsonfield  and 
jsonfield2 , which until Django-3 are 
the only viable options currently available for SQLite.

However, after switching to the new implementation using the built-in 
JSONField, one of my units tests does not pass 
. After 
examining this locally, I discovered, that the form
reports
product_form._errors: {'properties': ['Value must be valid JSON.']}
The only possible location to raise this exception, must be from inside the 
JSONField's validate() 

 
method; but in there I can't catch it.
Maybe this error is from my library, but I don't see any invalid passed in 
value. Or it comes from SQLite itself; could that be the problem?
– 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/1d3e3cb3-2456-428b-bc87-2ac5aa61484c%40googlegroups.com.

Re: declarative settings

[Jacob Rief]

You have hit a salient point in Django. It indeed is a mess how every third 
party
application must add its own configuration classes in order to make their 
own
default settings configurable through a settings.py. This results in 
settings directives
which can have any attribute name and do not follow any namespacing.

Some external apps, such as easy-thumbnails 
 add their own configuration 
framework 

with many different setting attributes, while others such as DRF use one 
Python dictionary
to keep all configurations in one closed namespace. The latter in my 
opinion is the
better approach but has its own issues. Having a consistent naming 
convention of setting
attributes, and a reconfiguration framework would certainly be beneficial 
in Django.

In my opinion, just switching to JSON does not resolve these naming 
convention issues,
but adds a bunch of other problems:

*Some configuration settings must be lazy.*
For instance, ugettext_lazy is used very often in the setting.py. This 
can't be handled by JSON.

*Writing JSON by hand is harder than writing Python.*
An alternative would be the usage of yaml or toml.

*Some settings must be taken from the environment.*
Especially database passwords and the SECRET_KEY shall be injected through 
the environment.
Typically here one would use os.getenv('DJANGO_SECRET_KEY') or similar. 
This can't be
handled by JSON either.

On Monday, December 30, 2019 at 11:46:03 PM UTC+1, Christian González wrote:
>
>
> * read json settings (if they exist), use them 
> * load settings.py which allows to override them again (using some 
> special code tricks like dynamic loading, environments etc.) 
>
>
If implemented, wouldn't it make more sense to use a JSON file to override 
a settings.py
rather than doing it vice versa? 

– just my two cents,
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/f5d9a23a-2927-454e-a3d3-6d2361c3aa06%40googlegroups.com.

Re: Form customization

[Jacob Rief]

>
>
> Hi Jacob — Possibly. Sounds like a moderate change... — what would it look 
> like? — proof of concept. (As ever... :) 
>
>
Something similar such as the templatetag render_form from 
django-restframework 
,
 
but instead of using a serializer, we'd use a form object.
crispy-forms uses a filter to achieve a similar goal, but somehow I prefer 
the DRF approach.

-- 
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/7cfb3d9a-e2f3-4da1-b2f3-b57f667a8875%40googlegroups.com.

Re: Form customization

[Jacob Rief]

With Django-1.10 we got the ability to override form fields with our own 
templates, however the form structure is still hard-coded.
Examples are BaseForm.as_table() 
,
 
BaseForm.as_ul() 

 
and BaseForm.as_p() 


For instance, the popular Bootstrap framework requires a  wrapped around each field, so I created a mixin class 
which I add to my Django Forms.
There I added a method named as_div() which renders all my fields in a 
Bootstrap-ish way. This of course is not very intuitive.

My question here is, couldn't we make the arguments normal_row, error_row, 
row_ender and help_text_html, which are passed to method self._html_output, 
more configurable?
Those arguments could maybe be replaced by some special templatetags and 
then consumed by a template responsible to render the form structure in a 
similar way as the as_...() methods mentioned before.

-- 
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/6eb291eb-91f9-4af0-9cd2-ae3fddc5ae4d%40googlegroups.com.

Re: Redis cache support in core

[Jacob Rief]

I'm also in favor on having it as part of the core, since memcache is also
supported.

One of the nice features Redis provides, is the possibility to invalidate
one or more cached object by using a wildcard key.
It namely is the method delete_pattern() added by django-redis-cache to the
given Django caching backend. That
(or a similar method) then should be part of the other Django caching
backends as well, such as the dummy cache or in-memory cache.

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/CAJ_HXxo9jpr-%3DFmLXcYwwR6tdn-NVDfrEoo-qYnB-vQwKv9O%3DA%40mail.gmail.com.

Re: Adding generated common table expressions

[Jacob Rief]

For my better understanding, could you please elaborate on what you mean by 
Hashes.as_literal(input_hashes) ?

-- 
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/48354bd1-5bd4-4b3a-b23e-376389ab2767%40googlegroups.com.

Re: Proposal to format Django using black

[jacob . rief]

Well, this thread is a very good example of Parkinson's law of triviality 
.

––
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 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/6fe41df0-f071-4958-93c7-fcbb9bba24e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Jacob Rief]

I share the opinion of Mariusz Felisiak, Luke Plant and Claude Paroz, and 
believe that it is a bad idea to do this in an automatic way without the 
possibility to interfere manually.
- 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 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/3195031d-e5e7-4a60-aa79-249010577a80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Jacob Rief]

To address some of Curtis Maloney's concerns:

>
> 1. automated code formatting will be a great boon - reduce work, lower 
> barrier for new committers, reduce work for the fellows, etc. 
>
> 2. there are issues with git history in doing "the great commit". 
>
> 3. there are issues with black's formatting choices. 
>
>  
How about, instead of reformatting all the code in one big go, discarding 
the "blame"-history,
instead we use a tool which only checks for formatting violations and 
prevents to commit such
code.

Such a tool, for instance is Coala https://coala.io/#/about?lang=Python
This could be added as a Pre-Commit Hook and prevents contributors to 
create non-conformant
branches on GitHub. This would address the problem of some pull requests 
not being merged
for a long period, because of minor formatting issues.

It also would enforce new coding styles over a longer period, keeping code 
annotations until
someone touches a file.

-- 
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/11c2539c-27bb-4ec4-b361-8f5f9a155aa3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.