Re: django logging - `ServerFormatter.uses_server_time()` forces users to use `{` logging style
Thanks for response.
Should I prepare some PR now?
Generally I think about implementing `.uses_server_time()` using
`_style.asctime_search` attribute:
`self._fmt.find(self._style.asctime_search.replace('asctime',
'server_time')) >= 0`
this call of `str.replace()` can be done even only once in
`ServerFormatter.__init__()`.
W dniu sobota, 9 lutego 2019 00:11:03 UTC+1 użytkownik Tim Graham napisał:
>
> I'm not opposed to a patch to address your use case.
>
> On Thursday, February 7, 2019 at 6:34:23 AM UTC-5, Łukasz Skarżyński wrote:
>>
>> Hello,
>>
>> I encountered some troubles with django logging configuration during the
>> update from Django 1.11 to 2.1. This issue was related to this commit
>>
>> and
>> generally `ServerFormatter.uses_server_time()` method.
>> This method forces users to use `{` logging style, by hard coding it in
>> the following line: `return self._fmt.find('{server_time}') >= 0`, so it
>> works only with `{` style, which is the default one.
>> I couldn't find any explanation why users should use `{` style instead of
>> `%` or `$` and I think style should be totally irrelevant to Django.
>> My suggestion is to make `ServerFormatter.uses_server_time()` workable
>> with all logging styles or to add some note to documentation that `{`
>> logging style must be used when `ServerFormatter` is overwritten.
>> If you decide to make some changes in relation to this issue, I am eager
>> to contribute.
>>
>> Thank you all for working on Django!
>>
>> Kind Regards,
>> Łukasz
>>
>
--
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/fd57a176-7614-4d43-972d-4faf8b9b5cca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Extend FAQ with "How do I get Django and my JS framework to work together?"
Hello, I wrote a three-part essay on this question last year: 1. https://fractalideas.com/blog/making-react-and-django-play-well-together/ 2. https://fractalideas.com/blog/making-react-and-django-play-well-together-hybrid-app-model/ 3. https://fractalideas.com/blog/making-react-and-django-play-well-together-single-page-app-model/ Even though I took a narrower view — I only considered React — I found enough decisions factors to write over 2000 words in the first post, which is too long for a FAQ :-) On one hand, I'm not sure the Django docs should go into this level of detail and provide specific information about a particular JS framework. On the other hand, it's rather useless to talk about integrating Django with a JS frontend without discussing authentication and it's hard to discuss authentication in less than 2000 words — which were just for justifying my favorite solution, not for investigating every option! I think we need a how-to guide rather than a FAQ entry. I would find it nice: A. To describe the Singe Page App model — where Django only serves the API We need to explain CORS and CSRF in the clearest terms possible. Many devs end up shotgun-debugging CORS or CSRF errors, which always results in insecure deployments. My consulting experience suggests that we have a problem there: I never did an audit where the client got that right, even though they're all smart people trying to get things right. Perhaps a condensed version of my third post could do the job? Some may disagree with my recommendation against JWT, which may too opinionated for the Django docs. Again, in my experience, people tend to get security more wrong with JWT, which is why I prefer discouraging it and letting those who know what they're doing ignore my advice. B. To say something about integrating a modern JS framework with django.contrib.staticfiles It's perfectly doable and provides all the benefits of django.contrib.staticfiles. However, it requires a bit of duct tape, as shown in my second post. I'm a huge fan of this technique for simple website but I'm afraid I'm biased by my experience with Django. This is unlikely to be a popular option for those who are more familiar with a modern frontend framework than with django.contrib.staticfiles. The docs should at least give the general idea of "compile your frontend to somewhere Django can find the files, then run collectstatic". If someone starts writing documentation about this, I'm interested in reviewing it. Best regards, -- Aymeric. > On 5 Feb 2019, at 11:17, Carlton Gibson wrote: > > I think this topic is very interesting. > > Two sides of it: > > * Static files handling > * APIs > > Curtis is right, there are other options but, Django REST Framework is > (whilst not perfect) pretty solid on the API front. I think Django has a good > story here. > It's pretty hard not to find DRF if you follow any guide, or any searching at > all. > > The static files story is a little different. It seems to me we don't tell > the best story there. > > Rails has two things which we could be envious of, even if we didn't want to > copy exactly: > > * The frontend framework integration that's already been mentioned. > * The very easy "Ajax your form", with controllers (i.e. for us "generic > views") automatically handling ajax form submissions. > > Both these features get users further quicker in these aspects than we are > able to offer. > > We struggle to think of areas for improvements (re GSoC for example) but > maybe here is an area. > > This ties into Claude's proposal here: > https://groups.google.com/d/topic/django-developers/KYmNnvwXDUI/discussion > > My own story is, I've had lots of success with, and still use, Django > Compressor. > At it's simplest you just map a content type to a shell command to run and > then include your Sass/Less/React/Elm/whatever files in your HTML (with > script or link tags, almost in the old-school way). > In development these are processed (& cached) per request. > For deployment you just run an offline compression task (management command) > and then upload the files. > That's it. > It's not a coverall approach — a frontend engineer will come along and > totally replace Compressor with whatever is this week's Top Javascript Build > System™ BUT it is a good 80:20: it lets me do something (that approximates) > respectable, without knowing hardly anything about the latest frontend > hotness. (GNU Make FTW! 🙂) > > I think if we were to offer something out-of-the-box that got as far as > Compressor, or further, we'd: > satisfy most of our users, > allow yet more to get off the mark quickly, > and... well... those that need the full frontend toolchain would still be > free to use it. > I worry we'd never get anything like this into core... but I think it would > be good. (As I say, I think it's one area where we are lacking/behind the > competition.) > >
Re: Extend FAQ with "How do I get Django and my JS framework to work together?"
Very nice tuturials! Although there is web components standard gradually being adapted by major browsers, which should bring custom tags / components not having to use the third party Javascript libraries like Vue or React. So, while in Python world the leadership of Django is quite stable and obvious one, in Javascript world it's not so easy to say whether Vue and React would dominate in a long run. Maybe Marko or Stencil.js are closer to the future vision of Javascript. On Sat, Feb 9, 2019 at 8:32 PM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > I wrote a three-part essay on this question last year: > 1. > https://fractalideas.com/blog/making-react-and-django-play-well-together/ > 2. > https://fractalideas.com/blog/making-react-and-django-play-well-together-hybrid-app-model/ > 3. > https://fractalideas.com/blog/making-react-and-django-play-well-together-single-page-app-model/ > > Even though I took a narrower view — I only considered React — I found > enough decisions factors to write over 2000 words in the first post, which > is too long for a FAQ :-) > > On one hand, I'm not sure the Django docs should go into this level of > detail and provide specific information about a particular JS framework. On > the other hand, it's rather useless to talk about integrating Django with a > JS frontend without discussing authentication and it's hard to discuss > authentication in less than 2000 words — which were just for justifying my > favorite solution, not for investigating every option! > > I think we need a how-to guide rather than a FAQ entry. I would find it > nice: > > *A. To describe the Singe Page App model — where Django only serves the > API* > > We need to explain CORS and CSRF in the clearest terms possible. Many devs > end up shotgun-debugging CORS or CSRF errors, which always results in > insecure deployments. > > My consulting experience suggests that we have a problem there: I never > did an audit where the client got that right, even though they're all smart > people trying to get things right. > > Perhaps a condensed version of my third post could do the job? > > Some may disagree with my recommendation against JWT, which may too > opinionated for the Django docs. Again, in my experience, people tend to > get security more wrong with JWT, which is why I prefer discouraging it and > letting those who know what they're doing ignore my advice. > > *B. To say something about integrating a modern JS framework with > django.contrib.staticfiles * > > It's perfectly doable and provides all the benefits of > django.contrib.staticfiles. However, it requires a bit of duct tape, as > shown in my second post. > > I'm a huge fan of this technique for simple website but I'm afraid I'm > biased by my experience with Django. This is unlikely to be a popular > option for those who are more familiar with a modern frontend framework > than with django.contrib.staticfiles. > > The docs should at least give the general idea of "compile your frontend > to somewhere Django can find the files, then run collectstatic". > > If someone starts writing documentation about this, I'm interested in > reviewing it. > > Best regards, > > -- > Aymeric. > > > > On 5 Feb 2019, at 11:17, Carlton Gibson wrote: > > I think this topic is very interesting. > > Two sides of it: > > * Static files handling > * APIs > > Curtis is right, there are other options but, Django REST Framework is > (whilst not perfect) pretty solid on the API front. I think Django has a > good story here. > It's pretty hard not to find DRF if you follow any guide, or any searching > at all. > > The static files story is a little different. It seems to me we don't tell > the best story there. > > Rails has two things which we could be envious of, even if we didn't want > to copy exactly: > > * The frontend framework integration that's already been mentioned. > * The very easy "Ajax your form", with controllers (i.e. for us "generic > views") automatically handling ajax form submissions. > > Both these features get users further quicker in these aspects than we are > able to offer. > > We struggle to think of areas for improvements (re GSoC for example) but > maybe here is an area. > > This ties into Claude's proposal here: > https://groups.google.com/d/topic/django-developers/KYmNnvwXDUI/discussion > > My own story is, I've had lots of success with, and still use, Django > Compressor. > >- At it's simplest you just map a content type to a shell command to >run and then include your Sass/Less/React/Elm/whatever files in your HTML >(with script or link tags, almost in the old-school way). >- In development these are processed (& cached) per request. >- For deployment you just run an offline compression task (management >command) and then upload the files. >- That's it. > > It's not a coverall approach — a frontend engineer will come along and > totally replace Compressor with whatever is this week's Top Ja
Re: Show applied datetime in showmigrations
I've worked up a solution for feedback. https://github.com/tim-schilling/django/pull/1 On Sunday, February 3, 2019 at 11:30:34 AM UTC-6, Tim Schilling wrote: > > My idea is to add the applied datetime value to the showmigrations command. > > I've run into the case where I'm working on a branch that involves a > number of migrations across various apps, but then have to switch to a > different branch which has different migrations. It can be troublesome to > determine which migrations are new and need to be rolled back. I've > recently started looking at the django_migrations table sorted on the > applied column to determine which I've run recently. This would make > switching between branches involving conflicting migrations easier. > > Thanks, > Tim > -- 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/3411da4b-927b-4aea-8e0b-f3d58bd5402c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Fellow Reports - February 2019
Week ending February 9, 2019 Triaged --- https://code.djangoproject.com/ticket/30167 - Allow Child Templates To Inherit Loaded Tags From Parent (duplicate) https://code.djangoproject.com/ticket/30168 - Change date, time and datetime inputs from text type (duplicate) Authored -- https://github.com/django/django/pull/10931 - Fixed #30155 -- Dropped support for PostgreSQL 9.4 and PostGIS 2.1. https://github.com/django/django/pull/10932 - Fixed #30156 -- Dropped support for SpatiaLite 4.1 and 4.2. https://github.com/django/django/pull/10935 - Refs #27753 -- Removed private Python 2 compatibility APIs. https://github.com/django/django/pull/10959 - Fixed #30166 -- Dropped support for GDAL 1.11. https://github.com/django/django/pull/10962 - Confirmed support for GDAL 2.4. https://github.com/django/django/pull/10960 - Dropped support for GEOS 3.4. Reviewed/committed -- https://github.com/django/django/pull/10933 - Refs #27753 -- Deprecated django.utils.http urllib aliases. https://github.com/django/django/pull/10938 - Refs #27753 -- Favored force/smart_str() over force/smart_text(). https://github.com/django/django/pull/10944 - Fixed #30157 -- Dropped support for Oracle 12.1. https://github.com/django/django/pull/10945 - Fixed #30159 -- Removed unneeded use of OrderedDict. https://github.com/django/django/pull/10776 - Fixed #16027 -- Added app_label to ContentType.__str__(). https://github.com/django/django/pull/10957 - Fixed #30165 -- Deprecated ugettext(), ugettext_lazy(), ugettext_noop(), ungettext(), and ungettext_lazy(). https://github.com/django/django/pull/10853 - Fixed #30027 -- Errored out on Window function usage if unsupported. https://github.com/django/django/pull/10939 - Fixed #30153 -- Fixed incorrect form Media asset ordering after three way merge. -- 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/5fdf125b-fe2a-4618-b61f-d174d7a803ae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
