Re: Incomplete documentation or bug? (linebreaksbr and stringfilter decorated filters)

[Carles Pina i Estany]

Hi,

Thanks Adam - type hints will help (specially if they can be represented
in the documentation), yes!

Matthew: thanks for the default_if_none tip!

For now I'll read the documentation in a different way regarding the
types :-) (well, it's easy now that I've seen the decorator
stringfilter!)

Thanks for the feedback,

Carles

On Sep/14/2020, Adam Johnson wrote:
> Yeah imo most filters should be worried about one type. We shouldn’t
> consider very variable “None-able” because it’s so pervasive.
> 
> This is somewhere that type hints will eventually help clarify.
> 
> On Mon, 14 Sep 2020 at 20:47, Matthew Pava  wrote:
> 
> > The filter states that it expects plain text. In Python, str(None) =
> > "None". To get the behavior you are seeking use the default_if_none filter,
> > and chain your other filters.
> >
> >
> > https://docs.djangoproject.com/en/dev/ref/templates/builtins/#default-if-none
> >
> > {{ text|default_if_none:""|linebreaksbr }}
> >
> >
> >
> > -Original Message-
> >
> > From: django-developers@googlegroups.com <
> > django-developers@googlegroups.com> On Behalf Of Carles Pina i Estany
> >
> > Sent: Monday, September 14, 2020 2:40 PM
> >
> > To: django-developers@googlegroups.com
> >
> > Subject: Incomplete documentation or bug? (linebreaksbr and stringfilter
> > decorated filters)
> >
> >
> >
> >
> >
> > Hi,
> >
> >
> >
> > Today I had a small surprise with templates and the linebreakbr filter.
> >
> >
> >
> > The "problem" (or root of the confusion) is that if None (of NoneType) is
> > given
> >
> > to linebreakbr it returns a SafeString 'None' instead of None (type
> > NoneType).
> >
> >
> >
> > The documentation says (
> > https://us-east-2.protection.sophos.com?d=djangoproject.com&u=aHR0cHM6Ly9kb2NzLmRqYW5nb3Byb2plY3QuY29tL2VuLzMuMS9yZWYvdGVtcGxhdGVzL2J1aWx0aW5zLyNzdGQ6dGVtcGxhdGVmaWx0ZXItbGluZWJyZWFrcw==&e=bWF0dGhldy5wYXZhQGlzcy5jb20=&t=eTYyb1Foa2VZVFJhdVU5dVBQazhvVFMycUpCMnZHSTFkZW9IOThqYVowWT0=&h=805589589ba040129c546a8f291d13ac
> > ):
> >
> > """
> >
> > Replaces line breaks in plain text with appropriate HTML; a single newline
> >
> > becomes an HTML line break () and a new line followed by a blank line
> >
> > becomes a paragraph break ().
> >
> > """
> >
> >
> >
> > Passing a None to linebreaksbr I was expecting to receive None. I read it
> >
> > literally that it would add line breaks in plain text and if there was no
> > plain
> >
> > text then nothing would be done. Or at least if None is passed it would
> >
> > return None.
> >
> >
> >
> > For example:
> >
> > {% with text=None %}
> >
> > {% if text %}{{ text }}{% else %}-{% endif %}
> >
> > {% endwith %}
> >
> > 
> >
> > {% with text=None|linebreaksbr %}
> >
> > {% if text %}{{ text }}{% else %}-{% endif %}
> >
> > {% endwith %}
> >
> >
> >
> > The second block prints "None" instead of "-".
> >
> >
> >
> > The None gets converted to the string in the decorator 'stringfilter'.
> >
> > The same happens in addslashes, capfirst, etc.
> >
> >
> >
> > Should this be noted in the documentation? Or the behaviour changed? (hard
> >
> > without backward compatibility issues). Or have I missed anything? Any
> >
> > thoughts?
> >
> >
> >
> > (I've checked the Django bug tracker and I haven't seen any bug describing
> >
> > this)
> >
> >
> >
> > Cheers,
> >
> >
> >
> > --
> >
> > Carles Pina i Estany
> >
> >
> > https://us-east-2.protection.sophos.com?d=pina.cat&u=aHR0cHM6Ly9jYXJsZXMucGluYS5jYXQ=&e=bWF0dGhldy5wYXZhQGlzcy5jb20=&t=QUNiOTdmclhvZW9UZm4reEtEaExwOE9hM05Vc1dQN3VIc1ZISUtjWm1UQT0=&h=805589589ba040129c546a8f291d13ac
> >
> >
> >
> > --
> >
> > 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://us-east-2.protection.sophos.com?d=google.com&u=aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9kL21zZ2lkL2RqYW5nby1kZXZlbG9wZXJzLzIwMjAwOTE0MTk0MDE0LkdBMTkwMDclNDBwaW5hLmNhdA==&e=bWF0dGhldy5wYXZhQGlzcy5jb20=&t=MkRHTjRCUitxY0NPeUVSbmlRQi9ZMHRwclIrVFNhQ1lNTXlrQ1FSeGswRT0=&h=805589589ba040129c546a8f291d13ac
> > .
> >
> >
> >
> > --
> >
> > 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/b888ccf136b7465b9bf7863e7a423945%40iss2.ISS.LOCAL
> > .
> >
> > --
> 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...

Re: Admin accessibility

[Thibaud Colas]

I’d love to! But worth bearing in mind that I haven’t done any Django 
contributions before.

I decided to end my talk with a call for feedback on your DEP – this feels 
like the ideal call to action to end on.

On Monday, 14 September 2020 at 18:00:03 UTC+1 t...@carrick.eu wrote:

> Carlton, I think that would be useful, thanks.
>
> Thibaud, shall I add you to the implementation team? It seems like you're 
> doing more work on this than I am lately. I think we could still use one or 
> perhaps two more people, but I think it's a good start.
>
> On Mon, 14 Sep 2020 at 16:44, Carlton Gibson  wrote:
>
>> Hi All. 
>>
>> Thanks for this. I'd be happy to play *Shepherd *if you need someone to 
>> put their hand up. 
>> I think that means I need to nag about getting it done. So... 🙂
>>
>> Who's going to be on the team to do the first review, and then subsequent 
>> work? Answer that and you have the Implementation Team. 
>> I like that you've thought about how the team can refresh periodically — 
>> I don't suppose the burden will be too great but folks tend to cycle-out 
>> naturally, so good to plan for that. 
>> Thibaud: Asking for hands in your talk seems sensible. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>>
>> On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:
>>
>>> Hi all,
>>>
>>> Now that the DEP PR has been submitted I was wondering what the next 
>>> steps would be. According to the documented DEP process I found, it’s at 
>>> the "forming the team" 
>>> 
>>>  
>>> stage? How do you go about creating an *Implementation Team* and 
>>> finding a *Shepherd*?
>>>
>>> The main reason I ask is that I’ll be giving a talk about accessibility 
>>> at DjangoCon EU in a couple of weeks, and I thought it would be a good 
>>> occasion to raise awareness of the issues with the Django admin, and 
>>> mention this DEP. But I want to make sure I provide accurate information.
>>>
>>> Thanks in advance,
>>>
>>> Thibaud
>>>
>>> On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:
>>>
 🎉 it’s wonderful to see this happening! Re-reading through the whole 
 thing, as Tobias mentioned I also find it very easy to read, and makes a 
 good case.

 On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:

> I've added a PR to the DEPs repo to hopefully get some eyes on it: 
> https://github.com/django/deps/pull/69
>
> Thibaud, I think whatever you have the time and motivation for sounds 
> good, all of those things are useful. If you're not sure about all the 
> admin features, I think that's pretty normal. One project I've had on my 
> mind for a while now is to build a simple django site that is essentially 
> just there to use every feature of the admin, so I might bump that up the 
> priority list, though it's somewhat daunting.
>
> Cheers,
> Tom
>
> On Mon, 13 Jul 2020 at 01:15, Thibaud Colas  
> wrote:
>
>> Update for the proof of concept CI tests from my side – thank you Tom 
>> for the feedback. Here are the latest additions to the test suite & 
>> reports, still living at 
>> https://thibaudcolas.github.io/django_admin_tests/,
>>
>> - Added as much as I know about in the admin, and now also outside of 
>> it a bit (startproject welcome page, error pages)
>> - Separated the issues between Axe and HTML_CS so the numbers are 
>> easier to understand
>> - Added anchor links everywhere for easier navigation
>> - I’ve also started a draft list of "things to (potentially) audit", 
>> over at 
>> https://github.com/thibaudcolas/django_admin_tests#scope-for-future-audits
>>
>> I think the next two big steps are what you mention:
>>
>> - Having a way to track the number of issues over time. Currently the 
>> report overwrites itself every week (well, every build). If you have a 
>> suggestion on ways to demo this that would be useful please let me know. 
>> Currently I’m thinking sparklines for each test case could be nice as a 
>> proof of concept, and a sparkline for the total number of issues. Or see 
>> whether I should get out of my comfort zone a bit and find a 
>> dashboard/graphing tool to send the metrics to and graph there.
>> - Testing more features of modeladmin. I don’t use it too frequently 
>> myself so don’t really know what’s “easy” to enable – if you know of an 
>> existing test suite I could repurpose, or of an example of using a lot 
>> of 
>> functionality – I’d be keen to invest time to add it to my test site.
>>
>> Alternatively something else I could do is to file a ticket for 
>> accessibility issues with the welcome page – I’ve tested it with screen 
>> readers, there are a few issues, but nothing that should be too hard to 
>> fix, and it might be a good demo of what