Admin and CSS Custom Properties

[Patrick Guido]

Hi everyone!

I think this is probably my first post here! Anyway... I was recently
working on a
django project where I was asked to change the admin theme (just the
colors).

I did so using CSS custom properties (see [1]) so that I would have all the
colors[2] set
in one file.

I'd like to start adopting CSS custom properties in the django admin.
It shouldn't take too much time, ideally what I'd like to do is this:

1. find all the colors used in the admin
2. create a `variables/colors.css` file where we put all the colors used in
the admin
3. add another color/background-color (or any CSS rule) where we use the
variable defined
  in the previous file, so that old browsers still use the default color,
but new ones use the
  color set from the variable.

That should mostly be it, a user can override the variables by adding
another CSS file, or
by creating a new static file in `admin/css/variables/colors.css`

The only issues I can see are:

1. there won't be an easy way to override colors for old browsers (same as
now)
2. one additional http request
3. if we ever change (or add/delete) one color we need to remember to
update the variable file
and the CSS

Do you any feedback on this? I might start a PR during this weekend or the
next one :)


[1] https://www.smashingmagazine.com/2017/04/start-using-
css-custom-properties/
[2] but this is not limited to colors, can be used for fonts, margins, etc

-- 
Patrick Guido Arminio

-- 
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/CAOUxZcv836UE3LL26JiZnrd7Mfes8_Yf2Cvxbr%2BOe9f2sTyTdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Organizing utilities for Django's test suite

[Tim Graham]

At present, we have a number of functions in django.test.utils which aren't 
documented and are meant for use in Django's test suite. Things like:

* extend_sys_path()
* isolate_lru_cache() 
* captured_stdout()/err()/in()
* freeze_time()
* require_jinja2()

I have the need to reuse a WidgetTestCase from forms_tests in 
postgres_tests so I tentatively proposed putting it in 
django/test/testcases.py with a comment that it's not a public API [0]. 
Simon proposed creating a django/tests/tests/utils.py submodule (alongside 
runtests.py) instead of defining it in django.test since it's not meant to 
be a public API.

Do you have any feelings about how to best organize things? I agree that 
mixing public and private things in django.test is not ideal. Another idea 
I had was to create something like django/test/_utils.py (underscore 
prefix) for private stuff. That would allow user code to continue using 
private APIs at their own risk (whereas putting test helpers in tests/ 
would not). 

[0] https://github.com/django/django/pull/8425

-- 
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/93178ea8-add8-4d40-96db-871ba12efa19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Organizing utilities for Django's test suite

[Markus Holtermann]

Hey Tim,

I think we can make a case for including this in django/tests/testcases.py 
and in a new module tests/utils/something.py which is then only available 
within Django's own the test suite. I think we should include that test 
case as part of Django's own test suite for now. It's IMO easier to move 
code from tests/utils/something.py to django/tests/something.py than vice 
versa.

That said, I think we should make capture_stdout()/err()/in() public API. 
It's super helpful.

/Markus

On Thursday, April 27, 2017 at 6:57:34 PM UTC+2, Tim Graham wrote:
>
> At present, we have a number of functions in django.test.utils which 
> aren't documented and are meant for use in Django's test suite. Things like:
>
> * extend_sys_path()
> * isolate_lru_cache() 
> * captured_stdout()/err()/in()
> * freeze_time()
> * require_jinja2()
>
> I have the need to reuse a WidgetTestCase from forms_tests in 
> postgres_tests so I tentatively proposed putting it in 
> django/test/testcases.py with a comment that it's not a public API [0]. 
> Simon proposed creating a django/tests/tests/utils.py submodule (alongside 
> runtests.py) instead of defining it in django.test since it's not meant to 
> be a public API.
>
> Do you have any feelings about how to best organize things? I agree that 
> mixing public and private things in django.test is not ideal. Another idea 
> I had was to create something like django/test/_utils.py (underscore 
> prefix) for private stuff. That would allow user code to continue using 
> private APIs at their own risk (whereas putting test helpers in tests/ 
> would not). 
>
> [0] https://github.com/django/django/pull/8425
>

-- 
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/05cff3b6-ded2-4243-9d77-bddf61c572c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The key of permissions model

[Flavio Curella]

I'd like to take another try at this.


My proposal is to temporarily supports two formats: the new 
`app_label.model_name.codename` (ref #25281) and the old `app.codename`. 
The old format will raise a PendingDeprecationWarning. Docs, code and tests 
will be updated to use the new format.

I believe that by having `app_label.model_name`. we can identify the 
`.content_type`. That, together with `.codename`, should be enough to 
uniquely identify the `Permission` instance.

There will be no model changes. Just checks and new code for all the 
methods that accepts the 'string api' for permissions.

Thanks,
–Flavio.

-- 
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/fb1b7c22-d436-4fa0-9f05-30f151a48da0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Admin and CSS Custom Properties

[Adam Johnson]

Thanks for introducing me to a new CSS feature! I clearly don't keep up
with front end stuff enough.

Re: your issues:

1. From the support grid at the bottom of the Smashing Magazine article you
linked, it looks like it's only IE 11 and Edge 14 that are major browsers
that don't support it. However I feel like if Django is going to announce a
feature like "you can override the Admin colours", it should work in all
browsers. I'm not sure if we have a written policy for this though.

2. I'm not a huge fan of an additional HTTP request for every admin page
load, for every admin site in existence whether or not the colours have
been overridden. HTTP/2 isn't very widely deployed still so requests still
ain't cheap.

3. This can be overcome with a test to ensure the two files are in sync, I
guess?

And one more question: how much less painful is this to override the
colours compared to the variable-less way, where you just clone the colour
definitions of every rule in the original file in a second override file?

On 27 April 2017 at 12:07, Patrick Guido  wrote:

> Hi everyone!
>
> I think this is probably my first post here! Anyway... I was recently
> working on a
> django project where I was asked to change the admin theme (just the
> colors).
>
> I did so using CSS custom properties (see [1]) so that I would have all
> the colors[2] set
> in one file.
>
> I'd like to start adopting CSS custom properties in the django admin.
> It shouldn't take too much time, ideally what I'd like to do is this:
>
> 1. find all the colors used in the admin
> 2. create a `variables/colors.css` file where we put all the colors used
> in the admin
> 3. add another color/background-color (or any CSS rule) where we use the
> variable defined
>   in the previous file, so that old browsers still use the default color,
> but new ones use the
>   color set from the variable.
>
> That should mostly be it, a user can override the variables by adding
> another CSS file, or
> by creating a new static file in `admin/css/variables/colors.css`
>
> The only issues I can see are:
>
> 1. there won't be an easy way to override colors for old browsers (same as
> now)
> 2. one additional http request
> 3. if we ever change (or add/delete) one color we need to remember to
> update the variable file
> and the CSS
>
> Do you any feedback on this? I might start a PR during this weekend or the
> next one :)
>
>
> [1] https://www.smashingmagazine.com/2017/04/start-using-css
> -custom-properties/
> [2] but this is not limited to colors, can be used for fonts, margins, etc
>
> --
> Patrick Guido Arminio
>
> --
> 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/CAOUxZcv836UE3LL26JiZnrd7Mfes8
> _Yf2Cvxbr%2BOe9f2sTyTdg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM3oX9U%3D%2B0U2bVPFN2T6Tb%3DyqqLK9HhfSGZM6ceSv25XxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.