Re: Implement show/hide changelist_filter div

[kiran chaudhari]

Great idea...
k j chaudhari


On Sat, Jun 19, 2021 at 3:09 PM Gil Obradors  wrote:

> Hi,
>
> This thread is for generating a first look about creating a hide/show
> button for the list_filter option on the admin-list view.
>
> Sometimes if you have a lot of columns in the admin-list view, it could be
> better to allow the user to hide all list_filter, like left nav_side_bar on
> app_models.
>
> I have attached some images showing the free pixel space benefits from
> that.
>
> If it seems to be a good idea, I would try to implement it myself, but I
> need some guidance about js project policies, creating new functions in
> existing admin/js file, or new file... using or not
> jquery,animations...etc...etc...
>
>
> What do you think?
>
>
>
>
> Gil
>
> Best djangos!
>
>
>
>
>
>
>
>
>
>
>
> --
> 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/CAK-JoTSfhjhGX9wErapqS7%3DJc2YZAqyZqXj_WccswnioE0i_cA%40mail.gmail.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/CAF%2BAdsZvPYZwtYsBFHzRHpwXs44axNvSyJw%2BJVEnm%2B%2BJBhv7aA%40mail.gmail.com.

Re: How to do a counter in DB cache class?

['Adam Johnson' via Django developers (Contributions to Django itself)]

I would love to make it work on all backends so we could have an improved
database cache class, but haven't the time.

On Tue, 1 Jun 2021 at 19:44, 'Mike Lissner' via Django developers
(Contributions to Django itself)  wrote:

> Wow, that's pretty great! Did you consider merging this functionality into
> django itself? I hadn't seen anything related before now.
>
> On Tue, Jun 1, 2021 at 11:38 AM 'Adam Johnson' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> Hi Mike!
>>
>> Probabilistic culling probably is the best we can do in the DB cache,
>> aside from moving culling to a background task.
>>
>> I wrote an implementation of this probabilistic culling in the
>> django-mysql cache backend (which is mysql only):
>> https://django-mysql.readthedocs.io/en/latest/cache.html#culling . This
>> also shows a way of pushing the cull into a background task by setting the
>> probability to 0 and calling the cull() method.
>>
>> Counting in the DB is a bad idea since it will put every write through a
>> single hot row, and if transactions are active that will even serialize
>> requests - ouch!
>>
>> An in-python counter, with a random offset per process (actually process
>> id *plus* thread id), could also work. But it would be trickier imo.
>>
>> Thanks,
>>
>> Adm
>>
>> On Tue, 1 Jun 2021 at 18:28, 'Mike Lissner' via Django developers
>> (Contributions to Django itself) 
>> wrote:
>>
>>> This might be more of a Python question than a Django one, but in this
>>> ticket  I'm hoping to make
>>> the DB cache a bit more performant by having it not cull stale entries
>>> *every* time somebody adds, changes, or touches a cache key.
>>>
>>> The idea is to use a setting or or class attribute so that the cache is
>>> instead culled every 50 times or 1000 times or whatever. Most of this is
>>> easy, but is there a good way to maintain a counter of how many times a key
>>> has been set?
>>>
>>> The best I've come up with is just to do a mod of a random number, and
>>> let that be good enough. E.g.:
>>>
>>> random_number = randint(0, CULL_EVERY_X)
>>> if random_number == CULL_EVERY_X:
>>> cull()
>>>
>>> That's pretty sloppy, but it'd work (on average), and it'd handle things
>>> like counting in a multi-process set up.
>>>
>>> The other approach, I suppose, would be to keep a counter in the DB and
>>> just increment it as needed, but it'd be nice to do something in memory
>>> even if it's a little less accurate, since this counter doesn't have to be
>>> exact.
>>>
>>> Anybody have thoughts on this?
>>>
>>> Thanks,
>>>
>>>
>>> Mike
>>>
>>>
>>> --
>>> 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/7f74e5f0-3206-4956-9ede-79788eda7982n%40googlegroups.com
>>> 
>>> .
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/qFxdRNLDGuA/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CAMyDDM2jSqZNGuBAobuuh%3D6%3DgWyD7SD0TTEzgUxO9CdqRhXotg%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Mike Lissner
> Executive Director
> Free Law Project
> https://free.law
>
> --
> 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/CAKs1xOEofZLoe7RMCR%2BxT6vkCbiFjGjMrJprfLGsVubXR6n9mQ%40mail.gmail.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 vis

Re: Discussion regarding #32628 and #32823

['Adam Johnson' via Django developers (Contributions to Django itself)]

I've made a PR to remove the options parameter:
https://github.com/django/django/pull/14542

On Wed, 9 Jun 2021 at 07:03, 'Sébastien Gélis' via Django developers
(Contributions to Django itself)  wrote:

> > *The number of lines is not the most important factor. There is no
> point in adding a new feature without tests and docs, because without them
> we will add a feature only for a single user, i.e. for the reporter. Also,
> we cannot add features just because they are not complex ("death by a
> thousand cuts"), each of them has a maintenance cost. Moreover, adding new
> features to the admin which are not used by admin itself is quite
> controversial.*
>
> Totally agree with you on that. My point was therefore: let's either
> implement this feature fully or, as Adam later suggested, remove the
> options parameter.
>
> > *Django's policy for what is maintained and extensible as "public API"
> is only those things that have been documented. This is its "deprecation
> policy":
> https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy
> 
> . Since neither the function nor the parameter have been documented, no one
> should not rely on them. It's the same for an unused parameter in an
> internal Python function. We remove many such parameters in each Django
> version without deprecation.*
>
> Thanks for this important clarification. I'll refactor my code to use a
> totally custom JS then, and leave this undocumented autocomplete.js alone
> for good :-)
>
> > *If anything, your highlighting the parameter has made me think we
> could remove it.*
>
> Count me in favor of this + documenting how front-end overrides of
> autocomplete are expected to be done (complete override of autocomplete.js
> or custom version compatible with AutocompleteJsonView).
> Would be happy to push a commit in this direction.
>
> Thanks again to you guys for taking the time to lead me through this!
>
> Sébastien
>
> Le mardi 8 juin 2021 à 17:39:22 UTC+2, Adam Johnson a écrit :
>
>> I'd be happy to suggest longer versions (if technically possible to
>>> implement).
>>>
>>
>> At least the documentation for triaging tickets is here:
>> https://github.com/django/django/blob/main/docs/internals/contributing/triaging-tickets.txt
>> .
>>
>>  I do not understand why the $.fn.djangoAdminSelect2 function would
>>> accept an options parameter at all then. This options parameter is never
>>> used in Django's own code, as far as I can tell.
>>>
>>
>> This looks like an oversight in the original commit to add the function:
>> https://github.com/django/django/commit/94cd8efc50c717cd00244f4b2233f971a53b205e
>> . The parameter has indeed never been used by Django.
>>
>> Django's policy for what is maintained and extensible as "public API" is
>> only those things that have been documented. This is its "deprecation
>> policy":
>> https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy
>> . Since neither the function nor the parameter have been documented, no one
>> should not rely on them. It's the same for an unused parameter in an
>> internal Python function. We remove many such parameters in each Django
>> version without deprecation.
>>
>> If anything, your highlighting the parameter has made me think we could
>> remove it.
>>
>> On Tue, 8 Jun 2021 at 15:55, Mariusz Felisiak 
>> wrote:
>>
>>> > Additionally, I do not see how this would add complexity to the code
>>> and/or the API. The API would remain strictly the same (
>>> $.fn.djangoAdminSelect2(options)) and the code itself needs only an
>>> additional ~5 lines.
>>>
>>> The number of lines is not the most important factor. There is no point
>>> in adding a new feature without tests and docs, because without them we
>>> will add a feature only for a single user, i.e. for the reporter. Also, we
>>> cannot add features just because they are not complex (*"death by a
>>> thousand cuts"*), each of them has a maintenance cost. Moreover, adding
>>> new features to the admin which are not used by admin itself is quite
>>> controversial.
>>>
>>> My 2 cents.
>>>
>>> Best,
>>> Mariusz
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/07713c30-7d56-4f34-b802-8e4d3cfc2bc6n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To 

Implement show/hide changelist_filter div

[Gil Obradors]

Hi,

This thread is for generating a first look about creating a hide/show
button for the list_filter option on the admin-list view.

Sometimes if you have a lot of columns in the admin-list view, it could be
better to allow the user to hide all list_filter, like left nav_side_bar on
app_models.

I have attached some images showing the free pixel space benefits from that.

If it seems to be a good idea, I would try to implement it myself, but I
need some guidance about js project policies, creating new functions in
existing admin/js file, or new file... using or not
jquery,animations...etc...etc...


What do you think?




Gil

Best djangos!

-- 
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/CAK-JoTSfhjhGX9wErapqS7%3DJc2YZAqyZqXj_WccswnioE0i_cA%40mail.gmail.com.