Re: collectstatic command should output minified files

[Dmitriy Sintsov]

There is one trouble: Webpack assumes it's own subtree of assets to
process, while Django loads assets from packages (Django apps) directories.
I still haven't seen a successful setup of webpack which would respect
loading assets from Django packages directories.
Another trouble, not everyone wants to carry node.js subsystem with it's
huge list of packages in their Python / Django project.
But there are changes that transpiling would not be required in the future
at all, after IE11 would fade to the past:
https://www.freecodecamp.org/news/you-might-not-need-to-transpile-your-javascript-4d5e0a438ca/

On Tue, Dec 22, 2020 at 1:20 PM Adam Johnson  wrote:

> django-compressor is also popular:
> https://pypi.org/project/django-compressor/
>
> IMO we should not include anything in Django since JavaScript is a
> separate language, and they have much better tools for minification and
> bundling, and these tools can move faster than and orthogonally to Django.
> And there are many options: Webpack, Parcel, Gulp, Grunt, Rollup, ..
>
> On Tue, 22 Dec 2020 at 10:06, quest...@gmail.com 
> wrote:
>
>> There is CSS / Javascript merge and compress package for Python:
>> https://github.com/miracle2k/webassets
>> which supports Django, Flask, Pyramid.
>>
>> See also:
>>
>> https://www.slideshare.net/__amol__/pyconit7-dukpy-webassets-free-yourself-from-nodejs-chains
>> https://pypi.org/project/dukpy/
>> https://gist.github.com/amol-/0fd016bbb0c6c9a0fb6ab5bbedfcb7ad
>> https://github.com/rclmenezes/webassets-rollup
>>
>>
>> On Tuesday, December 22, 2020 at 5:03:54 AM UTC+3 arvind...@gmail.com
>> wrote:
>>
>>> I kinda like the idea of being able to run collectstatic and not have to
>>> worry about setting up a full on frontend workflow for pretty much just
>>> minification. It is a great default to have when this is all you need.
>>>
>>> That said, I’d be more interested in seeing something like an official
>>> or a django-blessed unofficial default option similar to the
>>> sprokects-rails gem for ruby. Allowing for a much more flexible and
>>> extensive frontend pipeline without having to rely on an external task
>>> runner.
>>>
>>> On 22 Dec 2020, at 7:24, Diptesh Choudhuri wrote:
>>>
>>> The default files copied to STATIC_ROOT when you run python manage.py
>>> collectstatic should have two versions- file.js and file.min.js (similarly
>>> for css files). As far as I can see, this happens only for the preinstalled
>>> apps (like admin/actions.min.js) but not for user installed apps.
>>> Serbing minified static files is important for all production
>>> environments for pretty much everyone who uses vanilla django. Though there
>>> are packages out there to do this, I feel it is important enough and has
>>> enough use cases to be added to the django core.
>>>
>>> I can start working on this if it is accepted.
>>> Let me know what you think!
>>>
>>> Best
>>> Diptesh Choudhuri
>>>
>>> --
>>> 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/5bcb1522-3486-452e-b061-2cce2bb6d2c9n%40googlegroups.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/b4ee304c-6861-417c-a20c-bf79b5e2d9efn%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Adam
>
> --
> 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/dZDRivF29po/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/CAMyDDM2xcYM9M1AB-ZK47V4JHH0mNoYvXntz8-wrbzxdOJ1QFg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubsc

Re: Digest for django-developers@googlegroups.com - 1 update in 1 topic

[Dmitriy Sintsov]

If you want to populate the data after migration is complete, several times
or each time, you may try to use post_migrate signal:
https://docs.djangoproject.com/en/1.11/ref/signals/#post-migrate

On Fri, Oct 20, 2017 at 6:44 AM,  wrote:

> django-developers@googlegroups.com
> 
>  Google
> Groups
> 
> 
> Topic digest
> View all topics
> 
>
>- Feature request: Allow to process data-migrations after flush
><#m_-4246296427101809839_group_thread_0> - 1 Update
>
> Feature request: Allow to process data-migrations after flush
> 
> Alan Arellano : Oct 16 01:45PM -0300
>
> Precisely, because data migrations are indeed supported, it should be an
> option.
>
> Today I'm in other situation, I have a data migration which requires
> being run several times (because updates needed data from remote
> sources), today I can't do this with an straightforward command.
>
>
> On 08/26/2017 04:58 AM, Adam Johnson wrote:
> Back to top <#m_-4246296427101809839_digest_top>
> You received this digest because you're subscribed to updates for this
> group. You can change your settings on the group membership page
> 
> .
> To unsubscribe from this group and stop receiving emails from it send an
> email to django-developers+unsubscr...@googlegroups.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 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/CAC5UD1x8h_YhEaoLR36qx38D51zhvEv3Rx0n_qTcCqMeJyR3WA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP Pre-posal: Re-Designing Django Forms

[Dmitriy Sintsov]

Hi.

Client-side implementation of fields visual behavior and their validation 
should be hooked up via document.ready custom JS scripts via form ID or 
form class. There is no universal solution for that.

When using pure client-side forms from npm, it is possible to map these to 
Django models via DRF, however there will be no custom server-side widgets 
then. To me one of the most important parts of Django Forms is the ability 
to develop your own custom widgets.

Server-side validation of forms can be processed with AJAX, there are few 
implementations of that, including mine:
https://github.com/Dmitri-Sintsov/django-jinja-knockout/blob/master/docs/forms.rst#ajax-forms-processing

It saves quite enough ot HTTP traffic, because instead of complete 
re-rendering of submitted form HTML page, only the list of field ID's and 
their error messages are returned to be highlighed by client-side 
Javascript code.
It also allows to submit forms in AJAX "popup-like" dialogs:
https://github.com/Dmitri-Sintsov/django-jinja-knockout/blob/db4beeb18296c87af8626980b6a0c91e16f80863/django_jinja_knockout/views/ajax.py#L203

It supports file upload progress bar automatically as well:
https://github.com/Dmitri-Sintsov/django-jinja-knockout/blob/db4beeb18296c87af8626980b6a0c91e16f80863/django_jinja_knockout/static/djk/js/app.js#L1568

It's not so flexible (tied to Bootstrap 3 via Jinja2 macros) but it's 
possible to generalize such approach.

With client-side Javascript there is always the trouble which library to 
chose - Angular / Vue / React - cannot suit everyone. I use Knockout.js 
which is outdated but requires no webpack / npm and works with ES5. It is 
also fully compatible to server-side DTL / Jinja2 templates (it does not 
use double curly braces, thus causes no syntax clashes).

Dmitriy
On Wednesday, January 31, 2018 at 6:31:56 PM UTC+3, Robert Roskam wrote:
>
> Hey All,
>
> Something I've regularly run into as a challenge is the implementation of 
> Django forms work well in the simple use cases, but as the use case grows 
> in complexity, Django forms become more difficult to work with.
>
> I know that's a super general statement, but here's the simplest complex 
> example I can give you. Lets say you're making an application for a home 
> builder, so that their Project Managers can better coordinate the builds. 
> One of the features is the ability to take notes and pictures on anything 
> that's not yet done and specifically if it relates to a specific piece of 
> equipment (AC, furnace, water pump, etc), they can add that too. Below is a 
> moderately simplistic example:
>
> class Note(models.Model):
> project = models.ForeignKey('project_management.Project', 
> related_name="notes")
> equipment = models.ForeignKey('equipment.Equipment', null=True, 
> blank=True, related_name="notes")
> picture = models.FileField(null=True, blank=True)
> is_blocker = models.BooleanField(default=True)
> comment = models.TextField()
> created_by = models.ForeignKey('users.User', verbose_name="Created By")
> created_date = models.DateTimeField(default=timezone.now, 
> verbose_name="Created Date")
>
>
> class NoteModalForm(forms.ModelForm):
> class Meta:
> fields = ('comment', 'is_blocker','equipment', 'picture')
> model = Note
> labels = {
> 'comment': 'Note',
> 'is_blocker': 'Blocking Issue',
> 'picture': 'Picture',
> }
> widgets = {
> 'picture': DragNDropFileButtonInput(button_text='Select file 
> to Upload',
> button_classes='btn 
> btn-bordered uploader'),
> }
>
>
>
> General comments first: 
>
>1. I would say there's no better way to accomplish what is currently 
>on that form given the current Form Meta API. (Willing to be challenged on 
>this point, btw.)
>2. The repetition of picture 3 times over (fields tuple, labels dict, 
>widgets, dict) seems to be inherently not DRY. If this gets very long, 
> then 
>it becomes harder to manage.
>3. The API on the Model Form itself behaves not quite like you'd 
>expect initially. You'd expect redeclaring fields directly on a form for 
> it 
>to function like a dictionary update, if the value doesn't exist in the 
>incoming dictionary, it keeps what's there. It actually behaves like 
>re-declaration. This very significant behavior is buried in a note (
>
> https://docs.djangoproject.com/en/2.0/topics/forms/modelforms/#overriding-the-default-fields).
>  
>Additionally, you'll have sources like pydanny basically tell you this is 
>an anti-pattern: https://www.pydanny.com/overloading-form-fields.html
>4. The API on Meta leads you to believe initially that you can 
>override lots of things via Meta, and it's difficult to discover what is 
> or 
>is not supported. (I usually dig into django.forms.models, and then wander 
>around until I get 

Re: GSoC 2018

[Dmitriy Sintsov]

Hi!

Template languages are my favorite topic in programming.

If you implement html library yourself, it is much better to define tags 
not as functions but as classes with base Tag class which has properties 
for tag name, attributes and the nested list of tags. Such way you will 
re-implement DOM, although it is already available in lxml library.

So maybe it's a better idea to figure out whether lxml can be used as 
template engine for Django, because it can load source html into nested 
structures via binary optimized code. It should be cleaner and faster than 
manual composition of html in Python code.

In such case bindings could be performed via data-bind attribute like in 
Knockout,js or via Vue-like v-bind attribute:

http://knockoutjs.com/documentation/observables.html
https://vuejs.org/v2/guide/syntax.html#Attributes

Binding server-side data via html5 data attributes is the most 
non-obtrusive approach, and it does not create syntax clashes with 
server-side templates like DTL or Jinja which use double braces, 
semantically alien to XML / HTML (however Jinja is much more than html 
templating, it's an arbitrary text templating engine and an almost complete 
language itself).

But the most interesting thing in such approach are custom tags, including 
nested custom tags - so-called "components".

It was implemented ages ago in XSLT, where one may define small template 
with xml tags which then are transformed into larger, more verbose html:
https://www.w3schools.com/xml/xsl_transformation.asp

It is also supported in lxml:
http://lxml.de/xpathxslt.html

But XSL / XSLT did not gain wide adaption because the language syntax is 
made via XML tags and attributes thus became very verbose and difficult to 
read.

Maybe you could create template language like XSLT but with Python syntax? 
How's about such idea?

For example, Python XSLT-like well-readable transformation code could be 
dynamically converted to XSL style sheet then the XSL style sheet applied 
to source template to produce the final html.
https://www.w3schools.com/xml/xsl_transformation.asp



  
  


Instead xsl:for-each there will be Python's for, shorter and cleaner 
version, translated to xsl:for-each via AST parser.

Dmitriy
On Saturday, March 17, 2018 at 1:35:49 AM UTC+3, Manasvi Saxena wrote:
>
> Hello Sir,
>
> Okay, so the idea is to render HTML by generally defining it in Python. I 
>> could've sworn that I'd seen something like this years ago, but I'm failing 
>> to find it. That stated, I think this is basically a generating version of 
>> BeautifulSoup (https://www.crummy.com/software/BeautifulSoup/bs4/doc/) 
>> as opposed to a parsing version. 
>>
>> It's roughly like the Storm ORM (https://storm.canonical.com/) but for 
>> HTML instead of database queries.
>>
>> It's interesting, but I'll ask if one can get 90% of the functionality 
>> from xml.etree, which is in the standard Python Library.
>>
>> import xml.etree.ElementTree as ET
>>
>> a = ET.Element('p', style='{color: red;}')
>> a.text = "hello world"
>> ET.dump(a) # will match yours
>>
>> Note that this gets even weirder with something like "hello ignore 
>> this world".
>>
>> b = ET.Element('p')
>> b.text = "hello "
>> c = ET.Element('i')
>> c.text = "ignore this"
>> c.tail = " world"
>> b.append(c)
>> ET.dump(b) # will match above
>>
>
>
> I'm sure xml.etree has its drawbacks which I will improve in my library.
> The whole idea here is to bring python closer in the picture of generating 
> HTML content.
> Its applications are vast and not only limited to this. If time permits I 
> intend to write a complete framework like Bootstrap for python where things 
> like cards, navbars etc will be inbuilt and purely written on the basis of 
> my library.
> And that is the new feather I intend to add to Django's hat.
> Just like we have some inbuilt  'forms' in Django we'll have a lot of 
> other front-end related objects written in python and easily manipulative.
> And thus I intend to extend Django's reign in the front-end domain as 
> well. And make it a full-stack framework.
> Surely designing is something that changes very frequently in today's 
> world but if this is successfully implemented we can bring developers from 
> front-end world to contribute to it too. 
> Logic + Design.
>
> Regards,
> Manasvi Saxena
>

-- 
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/67d7a24c-d508-41cd-ab52-c3415cbb5131%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

[Dmitriy Sintsov]

Hi!
I think you should read the links about Knockout.js templates, Vue.js
templates and about XSLT templates and their support via lxml library.
Read about custom tags in XSLT and maybe in JSX.
Also read more about lxml library and how to use it.
Hope that will help you to improve your proposal.
Dmitriy


On Sat, Mar 17, 2018 at 12:12 PM, Manasvi Saxena 
wrote:

> Hello sir,
>
>
> On Saturday, March 17, 2018 at 2:07:03 PM UTC+5:30, Dmitriy Sintsov wrote:
>>
>> Hi!
>>
>> Template languages are my favorite topic in programming.
>>
>> If you implement html library yourself, it is much better to define tags
>> not as functions but as classes with base Tag class which has properties
>> for tag name, attributes and the nested list of tags. Such way you will
>> re-implement DOM, although it is already available in lxml library.
>>
>> So maybe it's a better idea to figure out whether lxml can be used as
>> template engine for Django, because it can load source html into nested
>> structures via binary optimized code. It should be cleaner and faster than
>> manual composition of html in Python code.
>>
>> In such case bindings could be performed via data-bind attribute like in
>> Knockout,js or via Vue-like v-bind attribute:
>>
>> http://knockoutjs.com/documentation/observables.html
>> https://vuejs.org/v2/guide/syntax.html#Attributes
>>
>> Binding server-side data via html5 data attributes is the most
>> non-obtrusive approach, and it does not create syntax clashes with
>> server-side templates like DTL or Jinja which use double braces,
>> semantically alien to XML / HTML (however Jinja is much more than html
>> templating, it's an arbitrary text templating engine and an almost complete
>> language itself).
>>
>> But the most interesting thing in such approach are custom tags,
>> including nested custom tags - so-called "components".
>>
>> It was implemented ages ago in XSLT, where one may define small template
>> with xml tags which then are transformed into larger, more verbose html:
>> https://www.w3schools.com/xml/xsl_transformation.asp
>>
>> It is also supported in lxml:
>> http://lxml.de/xpathxslt.html
>>
>> But XSL / XSLT did not gain wide adaption because the language syntax is
>> made via XML tags and attributes thus became very verbose and difficult to
>> read.
>>
>> Maybe you could create template language like XSLT but with Python
>> syntax? How's about such idea?
>>
>> For example, Python XSLT-like well-readable transformation code could be
>> dynamically converted to XSL style sheet then the XSL style sheet applied
>> to source template to produce the final html.
>> https://www.w3schools.com/xml/xsl_transformation.asp
>>
>> 
>> 
>>   
>>   
>> 
>>
>> Instead xsl:for-each there will be Python's for, shorter and cleaner
>> version, translated to xsl:for-each via AST parser.
>>
>> Dmitriy
>>
>
>
> I can't tell you how happy I'm to read your mail. This was the type of
> feedback I was craving for.
> The prototype I have created uses functions, for now, that's because I
> just thought of giving a basic idea of what my library will contain.
> Yes, I'll use concepts of class to write tags and not functions as a whole.
> And that's why I feel an obvious need of a good mentor who can provide his
> or her insight on things I'll do during my GSoC project.
>
> I intend to create a templating language with python syntax. Can you
> suggest me how should I move forward with my application and increase my
> chances of getting selected?
>
> Best regards,
> Manasvi Saxena
>
> --
> 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/ldhY8sAQc-0/unsubscribe.
> To unsubscribe from this group and all its topics, 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/4e742fb4-84ab-4ae1-9aca-
> f6c2c79b4f24%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/4e742fb4-84ab-4ae1-9aca-f6c2c79b4f24%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups

Re: Automatically initialise the project as git repo

[Dmitriy Sintsov]

On Friday, January 25, 2019 at 3:35:40 PM UTC+3, mihir karbelkar wrote:
>
> Hi,
> I have made several projects with Django but every time I create a new 
> project I have to initialize the repo for git. It would be better if the 
> project initialized itself. Maybe we can add this feature in to help make 
> development "even faster to meet goals in record time".
> I would love to work on this but it will only be my first contribution 
> so If we agree on this I can open probably open an issue and work on it.
> Also I would like to work for django in GSOC 2019 so any help would be 
> appreciated.
> Thanks.
>

Git is not the only choice. There is Mercurial version control system, 
which is written in Python and thus I prefer it for private non-git 
repositories of code. You can even "import mercurial" from Django code to 
get the current revision, for example. Favoring git only which is 
non-Python solution would be to opinionated.

-- 
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/2bc5dac0-ac96-4ea1-9a45-9a829a34619c%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?"

[Dmitriy Sintsov]

Speaking of Rails AJAX forms. It's quite trivial to submit Django ModelForm 
in Javascript AJAX request. It's a bit harder to have the customizable 
success action and to display the field validation errors via AJAX response.

I implemented AJAX viewmodels for that:

https://django-jinja-knockout.readthedocs.io/en/latest/viewmodels.html#ajax-actions

However it's the mixed traditional forms + AJAX approach, not the pure SPA. 
In pure SPA Django becomes the "data supplier" where most of the templates, 
forms, presentation is performed by Javascript framework.

So, the question is, whether the features of Django such as inline formsets 
and custom widgets are required, or should Django become the data store 
only.

On Tuesday, February 5, 2019 at 3:52:42 AM UTC+3, Maciek Olko wrote:
>
> I didn't find this topic being discussed before.
>
> It seems to me to be good idea to place "How do I get Django and my JS 
> framework to work together?" or similar question and answer to it in FAQ in 
> Django's docs.
>
> Having very big popularity of JS frameworks now it is indeed very common 
> question being asked or searched on the Internet. Such question for ReactJS 
> has 65k views on StackOverflow [1]. 
>
> The answer could briefly explain that one can make use of Django backend 
> and produce API to be consumed by JS clients. Probably it would be good to 
> link to Django REST API project as a suggestion for big projects.
>
> What do you think about such addition to FAQ?
>
> Regards,
> Maciej
>
> [1] 
> https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together
>

-- 
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/0cafc96d-bc4f-4316-9022-28e5134a1bcd%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?"

[Dmitriy Sintsov]

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: Help for GSoC proposal (Formset improvements)

[Dmitriy Sintsov]

It would be nice to have paginated formsets when there are lots of one to 
many relationships in the inline form, otherwise such rendered formset is 
slow and huge.

On Tuesday, March 26, 2019 at 8:56:56 PM UTC+3, PARTH PATIL wrote:
>
> I was planning  to do the "Formset Improvements 
> " 
> project in GSoC. I would need some more explanation on what is expected as 
> nothing was clearly mentioned there.
> You can link the related tickets or elaborate on what is needed that would 
> be helpful.
>
> I dug a little bit deeper into this. and found some related issues 1 
> 
>  
> | 2. 
> 
>
> I'm planning to add a request variable in the BaseFormSet Class 
> 
>  
> and then handle it such that it will be available within every form (not 
> completely polished till now).
>
>1. Is this a good approach?
>2. Will this solve the problem? (If not please mention the problems 
>which will not be solved
>
> I am also looking for some additional features that maybe added to formset 
> so am open for suggestions.
> I'm currently in middle of making the abstract so before moving forward i 
> would like to get some confirmation that this is correct approach. Thank you
>

-- 
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/4aa66060-b6a0-465d-acbf-9b31ac6a69a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Dmitriy Sintsov]

Why can't it use mixed quotes, single quotes for all strings except the 
strings that contain single quote characters? I think mixed syntax of 
strings is made in various programming languages so both single and double 
quotes can be used inside strings not having to use ugly backslash 
escaping. Maybe you or someone can create such feature request in black 
repo? Why the people do not like mixed quotes strings and try to eliminate 
such great feature? Aesthetical issues are very much biased and enforcing 
these automatically is not always a good idea. Does the switching to double 
quote string makes the code error prone and safer? Probably not. Just some 
voluntary personal choice.

On Monday, April 15, 2019 at 2:02:49 AM UTC+3, charettes wrote:
>
> I was and and I'm still bugged by how black decided to go for double 
> quotes instead of single ones. Even if it's backed some valid arguments it 
> left all the projects following PEP 8's recommendations over the years with 
> this git blaming loss trade off. From past experimentation with large'ish 
> projects following PEP8's guideline string quotes changes represented well 
> over 50% of the diff and there's no way to turn off only this form of 
> string normalization, it's all or nothing. At $WORK we even went as far as 
> forking the project to switch to use single quotes instead[0]. I understand 
> requiring the use of a fork is not a feasible solution for Django but I 
> just wished there was an option to stick to single quotes to reduce the 
> cost of adoption for such projects without loosing all the other nifty 
> string formatting goodies[1] /rant
>
> Even if I don't completely agree with black's formatting choices and the 
> sometimes quite unnatural code it generates my past month's usage at work 
> and the adoption of the project in the Python ecosystem that made it's way 
> in most IDE makes me mostly share the same feeling as Aymeric; it's not 
> always pretty but not having to think about it makes it worth it. I suggest 
> we stick to disabling string normalization to reduce the noise generated by 
> the migration though.
>
> Cheers,
> Simon
>
> [0] https://github.com/zapier/black/pull/1
> [1] https://github.com/ambv/black#strings
>
> Le dimanche 14 avril 2019 09:40:10 UTC-4, Aymeric Augustin a écrit :
>>
>> Hello,
>>
>> I'm strongly in favor of adopting black with the default options.
>>
>> In my opinion, it's the first Python code formatter that passes the bar 
>> of "on average, does better than any single programmer". Trying to enforce 
>> something else manually is a waste of energy that produces worse results.
>>
>> I like nicely formatted code and I hate some of what black produces, 
>> typically on Django model definitions. However, I've seen the benefits of 
>> an automated code formatter, even on projects where I write almost all of 
>> the code.
>>
>> I'm positive the benefits will be great on Django, where you can tell 
>> when a module was (re)written just by looking at the style. Yes, there are 
>> some downsides, but it's clearly a good tradeoff.
>>
>> Regarding the migration strategy, converting one package at a time sounds 
>> good, because then we can proof-read the Big Diff and perhaps tweak the 
>> code where the result really hurts the eyes.
>>
>> Most of Django's style guide will still applies, as it's mostly 
>> conventions about naming things, ordering declarations, etc.
>>
>> Best regards,
>>
>> -- 
>> Aymeric.
>>
>>
>>
>> On 13 Apr 2019, at 13:52, Herman S  wrote:
>>
>> Hi.
>>
>> I propose that Django starts using 'black' [0] to auto-format all Python 
>> code.
>> For those unfamiliar with 'black' I recommend reading the the projects 
>> README.
>> The short version: it aims to reduce bike-shedding and non value-adding
>> discussions; saving time reviewing code; and making the barrier to entry 
>> lower
>> by taking some uncompromissing choices with regards to formatting.  This 
>> is
>> similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.
>>
>> Personally I first got involved contributing to Django couple of weeks 
>> back,
>> and from anecdotal experience I can testify to how 'formatting of code' 
>> creates
>> a huge barrier for entry. My PR at the time went multiple times back and 
>> forth
>> tweaking formatting. Before this, I had to research the style used by 
>> exploring
>> the docs at length and reading at least 10-20 different source – and even 
>> those
>> were not always consistent. At the end of the day I felt like almost 50% 
>> of the
>> time I used on the patch was not used on actually solving the issue at 
>> hand.
>> Thinking about code formatting in 2019 is a mental energy better used for 
>> other
>> things, and it feels unnecessary that core developers on Django spend 
>> their time
>> "nit-picking" on these things.
>>
>> I recently led the efforts to make this change where I work. We have a 
>> 200K+
>> LOC Django code-base with more than 30K commits. Some key take-aways: it 

Ticket 28087: Allow filtering and ordering with RawQuerySet

[Dmitriy Sintsov]

Hi!
I implemented FilteredRawQuerySet which supports filter() and order_by() 
like model manager QuerySet.

https://code.djangoproject.com/ticket/28087
https://github.com/Dmitri-Sintsov/django-jinja-knockout/blob/master/django_jinja_knockout/query.py

Internally it contains RawQuerySet and QuerySet for the target model.

SELECT part of the query is borrowed from RawQuerySet, while WHERE and 
ORDER BY statements are generated via QuerySet query.

This feature is useful when the code uses programmatically generated 
arguments of filter() / order_by(), for example in class-based ListView 
with custom filtering and / or sorting.

Is such feature worth to be included to Django core?

I could just continue to use my own implementation (probably imperfect) 
however I am worrying about possible query generation code changes that 
could make my module incompatible in the future.

In case such queryset would be included to Django code, there are much more 
chances that the code which uses it would not break when updating to newer 
Django version.

Dmitriy

-- 
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/a20e043e-aec8-4806-9e6b-c5c669361c44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 28087: Allow filtering and ordering with RawQuerySet

[Dmitriy Sintsov]

I know that it does not work in the general case, but still having 
orthogonal processing of RAW queries with the same filter() / order_by() 
calls matches Django's DRY philosophy.
Raw queries which has hardcoded WHERE and ORDER BY statements will simply 
raise an error when another WHERE / ORDER BY statement is added by filter() 
/ order_by().
But there is no point to specify WHERE manually when there is filter() 
available and such error brings no direct harm.
I implemented it mostly to use in paginated ListView-like CBVs with LEFT 
JOIN. Here is the example of real query from private project:

'SELECT isp_finances_profilerequisites.*, '
'isp_user_profile.user_id, isp_user_profile.last_name, 
isp_user_profile.first_name, isp_user_profile.is_verified, isp_user_profile.inn 
'
'FROM isp_user_profile '
'LEFT JOIN isp_finances_profilerequisites '
'ON isp_finances_profilerequisites.profile_id = isp_user_profile.user_id '
'JOIN auth_user '
'ON auth_user.id = isp_user_profile.user_id '


Is such RAW query (with working pagination and sorting) possible to convert 
to model manager QuerySet query?

On Friday, April 21, 2017 at 1:02:40 AM UTC+3, Adam Johnson wrote:
>
> I'm worried this doesn't work in the general case, as there are a lot of 
> different query formats one can write with raw SQL, such as UNION, SQL 
> variables, or other database specific formats. You have a lot of code 
> there, but from what I can tell the code is simply setting up the 
> RawSqlCompiler which adds WHERE etc. after the raw SQL, ignoring the fact 
> that there could already be a WHERE in it - am I right?
>
> Also - what do you find raw queries being needed for? In general the ORM 
> is very capable these days and the general development focus on it is to 
> make it cover even more of SQL's capabilities.
>
> On 20 April 2017 at 20:36, Dmitriy Sintsov  > wrote:
>
>> Hi!
>> I implemented FilteredRawQuerySet which supports filter() and order_by() 
>> like model manager QuerySet.
>>
>> https://code.djangoproject.com/ticket/28087
>>
>> https://github.com/Dmitri-Sintsov/django-jinja-knockout/blob/master/django_jinja_knockout/query.py
>>
>> Internally it contains RawQuerySet and QuerySet for the target model.
>>
>> SELECT part of the query is borrowed from RawQuerySet, while WHERE and 
>> ORDER BY statements are generated via QuerySet query.
>>
>> This feature is useful when the code uses programmatically generated 
>> arguments of filter() / order_by(), for example in class-based ListView 
>> with custom filtering and / or sorting.
>>
>> Is such feature worth to be included to Django core?
>>
>> I could just continue to use my own implementation (probably imperfect) 
>> however I am worrying about possible query generation code changes that 
>> could make my module incompatible in the future.
>>
>> In case such queryset would be included to Django code, there are much 
>> more chances that the code which uses it would not break when updating to 
>> newer Django version.
>>
>> Dmitriy
>>
>> -- 
>> 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 post to this group, send email to django-d...@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/a20e043e-aec8-4806-9e6b-c5c669361c44%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/a20e043e-aec8-4806-9e6b-c5c669361c44%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> 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/08e7fa46-8aa1-4e92-bb70-9990abfc0e4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 28087: Allow filtering and ordering with RawQuerySet

[Dmitriy Sintsov]

How can I chose whether select_related() will use LEFT JOIN or INNER JOIN? 
There are two joins, one is LEFT another is INNER one.

On Friday, April 21, 2017 at 1:40:47 PM UTC+3, Adam Johnson wrote:
>
> Joining two tables like that on one-to-one relations can be easily 
> achieved with select_related 
> <https://docs.djangoproject.com/en/1.11/ref/models/querysets/#select-related>
> .
>
> On 21 April 2017 at 09:47, Dmitriy Sintsov  > wrote:
>
>> I know that it does not work in the general case, but still having 
>> orthogonal processing of RAW queries with the same filter() / order_by() 
>> calls matches Django's DRY philosophy.
>> Raw queries which has hardcoded WHERE and ORDER BY statements will simply 
>> raise an error when another WHERE / ORDER BY statement is added by filter() 
>> / order_by().
>> But there is no point to specify WHERE manually when there is filter() 
>> available and such error brings no direct harm.
>> I implemented it mostly to use in paginated ListView-like CBVs with LEFT 
>> JOIN. Here is the example of real query from private project:
>>
>> 'SELECT isp_finances_profilerequisites.*, '
>> 'isp_user_profile.user_id, isp_user_profile.last_name, 
>> isp_user_profile.first_name, isp_user_profile.is_verified, 
>> isp_user_profile.inn '
>> 'FROM isp_user_profile '
>> 'LEFT JOIN isp_finances_profilerequisites '
>> 'ON isp_finances_profilerequisites.profile_id = isp_user_profile.user_id '
>> 'JOIN auth_user '
>> 'ON auth_user.id = isp_user_profile.user_id '
>>
>>
>> Is such RAW query (with working pagination and sorting) possible to 
>> convert to model manager QuerySet query?
>>
>> On Friday, April 21, 2017 at 1:02:40 AM UTC+3, Adam Johnson wrote:
>>>
>>> I'm worried this doesn't work in the general case, as there are a lot of 
>>> different query formats one can write with raw SQL, such as UNION, SQL 
>>> variables, or other database specific formats. You have a lot of code 
>>> there, but from what I can tell the code is simply setting up the 
>>> RawSqlCompiler which adds WHERE etc. after the raw SQL, ignoring the fact 
>>> that there could already be a WHERE in it - am I right?
>>>
>>> Also - what do you find raw queries being needed for? In general the ORM 
>>> is very capable these days and the general development focus on it is to 
>>> make it cover even more of SQL's capabilities.
>>>
>>> On 20 April 2017 at 20:36, Dmitriy Sintsov  wrote:
>>>
>>>> Hi!
>>>> I implemented FilteredRawQuerySet which supports filter() and 
>>>> order_by() like model manager QuerySet.
>>>>
>>>> https://code.djangoproject.com/ticket/28087
>>>>
>>>> https://github.com/Dmitri-Sintsov/django-jinja-knockout/blob/master/django_jinja_knockout/query.py
>>>>
>>>> Internally it contains RawQuerySet and QuerySet for the target model.
>>>>
>>>> SELECT part of the query is borrowed from RawQuerySet, while WHERE and 
>>>> ORDER BY statements are generated via QuerySet query.
>>>>
>>>> This feature is useful when the code uses programmatically generated 
>>>> arguments of filter() / order_by(), for example in class-based ListView 
>>>> with custom filtering and / or sorting.
>>>>
>>>> Is such feature worth to be included to Django core?
>>>>
>>>> I could just continue to use my own implementation (probably imperfect) 
>>>> however I am worrying about possible query generation code changes that 
>>>> could make my module incompatible in the future.
>>>>
>>>> In case such queryset would be included to Django code, there are much 
>>>> more chances that the code which uses it would not break when updating to 
>>>> newer Django version.
>>>>
>>>> Dmitriy
>>>>
>>>> -- 
>>>> 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 post to this group, send email to django-d...@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

Re: Ticket 28087: Allow filtering and ordering with RawQuerySet

[Dmitriy Sintsov]

If I understand correctly, LEFT JOIN is automatically chosen when 
ForeignKey(null=True) otherwise it will be INNER JOIN?

My ProfileRequisites.profile ForeignKey is not nullable yet I need to use 
LEFT JOIN in this query so I have profiles and ProfileRequisites in the 
same list. Profiles are always retrieved while ProfileRequisites only if 
these are available (LEFT):


class ProfileRequisites(models.Model):

profile = models.ForeignKey(Profile, related_name='requisites')
requisites_type = models.ForeignKey(
ContentType, null=True, related_name='related_requisites', 
verbose_name='Тип реквизитов'
)
requisites_id = models.PositiveIntegerField(verbose_name='Ссылка на 
реквизиты')
requisites_object = GenericForeignKey('requisites_type', 'requisites_id')
is_preferred_withdrawal = models.NullBooleanField(default=None, 
verbose_name='Предпочтительный способ вывода')


On Friday, April 21, 2017 at 7:55:31 PM UTC+3, Adam Johnson wrote:
>
> It depends upon whether the foreignkey/onetoonefield is nullable.
>
> On 21 April 2017 at 17:16, Dmitriy Sintsov  > wrote:
>
>> How can I chose whether select_related() will use LEFT JOIN or INNER 
>> JOIN? There are two joins, one is LEFT another is INNER one.
>>
>> On Friday, April 21, 2017 at 1:40:47 PM UTC+3, Adam Johnson wrote:
>>>
>>> Joining two tables like that on one-to-one relations can be easily 
>>> achieved with select_related 
>>> <https://docs.djangoproject.com/en/1.11/ref/models/querysets/#select-related>
>>> .
>>>
>>> On 21 April 2017 at 09:47, Dmitriy Sintsov  wrote:
>>>
>>>> I know that it does not work in the general case, but still having 
>>>> orthogonal processing of RAW queries with the same filter() / order_by() 
>>>> calls matches Django's DRY philosophy.
>>>> Raw queries which has hardcoded WHERE and ORDER BY statements will 
>>>> simply raise an error when another WHERE / ORDER BY statement is added by 
>>>> filter() / order_by().
>>>> But there is no point to specify WHERE manually when there is filter() 
>>>> available and such error brings no direct harm.
>>>> I implemented it mostly to use in paginated ListView-like CBVs with 
>>>> LEFT JOIN. Here is the example of real query from private project:
>>>>
>>>> 'SELECT isp_finances_profilerequisites.*, '
>>>> 'isp_user_profile.user_id, isp_user_profile.last_name, 
>>>> isp_user_profile.first_name, isp_user_profile.is_verified, 
>>>> isp_user_profile.inn '
>>>> 'FROM isp_user_profile '
>>>> 'LEFT JOIN isp_finances_profilerequisites '
>>>> 'ON isp_finances_profilerequisites.profile_id = isp_user_profile.user_id '
>>>> 'JOIN auth_user '
>>>> 'ON auth_user.id = isp_user_profile.user_id '
>>>>
>>>>
>>>> Is such RAW query (with working pagination and sorting) possible to 
>>>> convert to model manager QuerySet query?
>>>>
>>>> On Friday, April 21, 2017 at 1:02:40 AM UTC+3, Adam Johnson wrote:
>>>>>
>>>>> I'm worried this doesn't work in the general case, as there are a lot 
>>>>> of different query formats one can write with raw SQL, such as UNION, SQL 
>>>>> variables, or other database specific formats. You have a lot of code 
>>>>> there, but from what I can tell the code is simply setting up the 
>>>>> RawSqlCompiler which adds WHERE etc. after the raw SQL, ignoring the fact 
>>>>> that there could already be a WHERE in it - am I right?
>>>>>
>>>>> Also - what do you find raw queries being needed for? In general the 
>>>>> ORM is very capable these days and the general development focus on it is 
>>>>> to make it cover even more of SQL's capabilities.
>>>>>
>>>>> On 20 April 2017 at 20:36, Dmitriy Sintsov  wrote:
>>>>>
>>>>>> Hi!
>>>>>> I implemented FilteredRawQuerySet which supports filter() and 
>>>>>> order_by() like model manager QuerySet.
>>>>>>
>>>>>> https://code.djangoproject.com/ticket/28087
>>>>>>
>>>>>> https://github.com/Dmitri-Sintsov/django-jinja-knockout/blob/master/django_jinja_knockout/query.py
>>>>>>
>>>>>> Internally it contains RawQuerySet and QuerySet for the target model.
>>>>>>

Re: Ticket 28087: Allow filtering and ordering with RawQuerySet

[Dmitriy Sintsov]

On Friday, April 21, 2017 at 10:30:49 PM UTC+3, Adam Johnson wrote:
>
> This isn't the place for a tutorial on how joins work in the Django ORM, 
> there is plenty of documentation, tutorials, blog posts, and stack overflow 
> posts for that. Check it out by internet-searching "Django select_related" 
> or "django join". Any combination of inner and left joins is possible with 
> the ORM.
>
> from isp_finances.models import ProfileRequisites
ProfileRequisites.objects.select_related('profile').query.__str__()
'SELECT "isp_finances_profilerequisites"."id", 
"isp_finances_profilerequisites"."profile_id", 
"isp_finances_profilerequisites"."requisites_type_id", 
"isp_finances_profilerequisites"."requisites_id", 
"isp_finances_profilerequisites"."is_preferred_withdrawal", 
"isp_user_profile"."user_id", "isp_user_profile"."has_verified_email", 
"isp_user_profile"."is_filled", "isp_user_profile"."is_verified", 
"isp_user_profile"."last_name", "isp_user_profile"."first_name", 
"isp_user_profile"."otchestvo", "isp_user_profile"."other_names", 
"isp_user_profile"."birthdate", "isp_user_profile"."country_id", 
"isp_user_profile"."region_id", "isp_user_profile"."identity_type", 
"isp_user_profile"."identity_date", "isp_user_profile"."identity_numbers", 
"isp_user_profile"."identity_misc", "isp_user_profile"."inn", 
"isp_user_profile"."education", "isp_user_profile"."resume", 
"isp_user_profile"."rating", "isp_user_profile"."rating_reason", 
"isp_user_profile"."accepted_license_id" FROM 
"isp_finances_profilerequisites" INNER JOIN "isp_user_profile" ON ( 
"isp_finances_profilerequisites"."profile_id" = 
"isp_user_profile"."user_id" ) ORDER BY "isp_user_profile"."user_id" ASC, 
"isp_finances_profilerequisites"."requisites_type_id" ASC'

There is INNER JOIN generated, while I need a LEFT JOIN. I understand you 
want me to make ForeignKey null-able but I do not really need it.
I use select_related() (as well as prefetch_related()) in different places 
in my code.
 

> On 21 April 2017 at 19:41, Dmitriy Sintsov  > wrote:
>
>> If I understand correctly, LEFT JOIN is automatically chosen when 
>> ForeignKey(null=True) otherwise it will be INNER JOIN?
>>
>> My ProfileRequisites.profile ForeignKey is not nullable yet I need to use 
>> LEFT JOIN in this query so I have profiles and ProfileRequisites in the 
>> same list. Profiles are always retrieved while ProfileRequisites only if 
>> these are available (LEFT):
>>
>>
>> class ProfileRequisites(models.Model):
>>
>> profile = models.ForeignKey(Profile, related_name='requisites')
>> requisites_type = models.ForeignKey(
>> ContentType, null=True, related_name='related_requisites', 
>> verbose_name='Тип реквизитов'
>> )
>> requisites_id = models.PositiveIntegerField(verbose_name='Ссылка на 
>> реквизиты')
>> requisites_object = GenericForeignKey('requisites_type', 'requisites_id')
>> is_preferred_withdrawal = models.NullBooleanField(default=None, 
>> verbose_name='Предпочтительный способ вывода')
>>
>>
>> On Friday, April 21, 2017 at 7:55:31 PM UTC+3, Adam Johnson wrote:
>>>
>>> It depends upon whether the foreignkey/onetoonefield is nullable.
>>>
>>> On 21 April 2017 at 17:16, Dmitriy Sintsov  wrote:
>>>
>>>> How can I chose whether select_related() will use LEFT JOIN or INNER 
>>>> JOIN? There are two joins, one is LEFT another is INNER one.
>>>>
>>>> On Friday, April 21, 2017 at 1:40:47 PM UTC+3, Adam Johnson wrote:
>>>>>
>>>>> Joining two tables like that on one-to-one relations can be easily 
>>>>> achieved with select_related 
>>>>> <https://docs.djangoproject.com/en/1.11/ref/models/querysets/#select-related>
>>>>> .
>>>>>
>>>>> On 21 April 2017 at 09:47, Dmitriy Sintsov  wrote:
>>>>>
>>>>>> I know that it does not work in the general case, but still having 
>>>>>> orthogonal processing of RAW qu

Re: Ticket 28087: Allow filtering and ordering with RawQuerySet

[Dmitriy Sintsov]

On Friday, April 21, 2017 at 10:44:54 PM UTC+3, Ian Foote wrote:
>
> Hi Dmitriv, 
>
> I think you're running into https://code.djangoproject.com/ticket/27332. 
> Unfortunately this isn't fixed yet, but there's a pull request, so it 
> might land in 2.0: https://github.com/django/django/pull/7560 
>
> Ian 
>
> Actually I like ORM (not only Django but any ORM) only for straightforward 
(not complex) queries, the more complex query become the better it looks in 
RAW. However improving ORM always is a good idea. If there is no need to 
have filtered raw QuerySet, please close my ticket.
 

> On 21/04/17 19:41, Dmitriy Sintsov wrote: 
> > If I understand correctly, LEFT JOIN is automatically chosen when 
> > ForeignKey(null=True) otherwise it will be INNER JOIN? 
> > 
> > My ProfileRequisites.profile ForeignKey is not nullable yet I need to 
> > use LEFT JOIN in this query so I have profiles and ProfileRequisites in 
> > the same list. Profiles are always retrieved while ProfileRequisites 
> > only if these are available (LEFT): 
> > 
> > 
> > class ProfileRequisites(models.Model): 
> > 
> > profile = models.ForeignKey(Profile, related_name='requisites') 
> > requisites_type = models.ForeignKey( 
> > ContentType, null=True, related_name='related_requisites', 
> verbose_name='Тип реквизитов' 
> > ) 
> > requisites_id = models.PositiveIntegerField(verbose_name='Ссылка на 
> реквизиты') 
> > requisites_object = GenericForeignKey('requisites_type', 
> 'requisites_id') 
> > is_preferred_withdrawal = models.NullBooleanField(default=None, 
> verbose_name='Предпочтительный способ вывода') 
> > 
> > 
>
>
>

-- 
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/ef6d8fcc-3fc7-45d5-be27-bf6855bad8fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 28087: Allow filtering and ordering with RawQuerySet

[Dmitriy Sintsov]

There is also ListQuerySet
https://django-jinja-knockout.readthedocs.io/en/latest/quickstart.html#listqueryset
 
to be used with Prefetch() results but it's probably is too specific one.

I use it in private project.

On Friday, April 21, 2017 at 10:44:54 PM UTC+3, Ian Foote wrote:
>
> Hi Dmitriv, 
>
> I think you're running into https://code.djangoproject.com/ticket/27332. 
> Unfortunately this isn't fixed yet, but there's a pull request, so it 
> might land in 2.0: https://github.com/django/django/pull/7560 
>
> Ian 
>
> On 21/04/17 19:41, Dmitriy Sintsov wrote: 
> > If I understand correctly, LEFT JOIN is automatically chosen when 
> > ForeignKey(null=True) otherwise it will be INNER JOIN? 
> > 
> > My ProfileRequisites.profile ForeignKey is not nullable yet I need to 
> > use LEFT JOIN in this query so I have profiles and ProfileRequisites in 
> > the same list. Profiles are always retrieved while ProfileRequisites 
> > only if these are available (LEFT): 
> > 
> > 
> > class ProfileRequisites(models.Model): 
> > 
> > profile = models.ForeignKey(Profile, related_name='requisites') 
> > requisites_type = models.ForeignKey( 
> > ContentType, null=True, related_name='related_requisites', 
> verbose_name='Тип реквизитов' 
> > ) 
> > requisites_id = models.PositiveIntegerField(verbose_name='Ссылка на 
> реквизиты') 
> > requisites_object = GenericForeignKey('requisites_type', 
> 'requisites_id') 
> > is_preferred_withdrawal = models.NullBooleanField(default=None, 
> verbose_name='Предпочтительный способ вывода') 
> > 
> > 
>
>
>

-- 
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/b38d2f6e-b2f3-4901-8163-ddbb1a9712a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Dmitriy Sintsov]

Microsoft probably will take Django support to the next level with Windows 
Subsystem for Linux. It's still beta but a very promising one. Not only it 
should make compiling Python module binaries (like lxml) much easier, it 
also fixes binary / nix specific support of node.js / Ruby packages.

On Friday, April 28, 2017 at 10:55:26 PM UTC+3, uri...@gmail.com wrote:
>
> I wonder if there have been any updates on MS support for a 
> official/supported MS SQL Django driver? Did the offered engineering effort 
> from MS ever come through? Given the availability of of MS SQL on Linux, as 
> well as support for Django in Visual Studio, it would be great if this came 
> to fruition.
> Explicit support for Django with IronPython would also be nice, if MS 
> would really want to take their Django support to the next level...
>
> On Monday, March 7, 2016 at 5:37:06 PM UTC-5, Meet Bhagdev wrote:
>>
>> Hi all,
>>
>> On interacting with several Django developers and committers, one of the 
>> questions often came up, can I use SQL Server on non Window OS's? I wanted 
>> to share that today Microsoft announced SQL Server availibility on Linux - 
>> https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
>> . 
>>
>> While there is still work needed to strengthen the MSSQL-Django story, we 
>> hope this aids more Linux developers to give SQL Server a shot. Let me know 
>> of your thoughts and questions :)
>>
>> Cheers,
>> Meet
>>
>> On Monday, February 22, 2016 at 4:54:38 PM UTC-8, Vin Yu wrote:
>>>
>>> Hey Folks, 
>>>
>>> My name is Vin and I work with Meet in the Microsoft SQL Server team. 
>>> Just wanted to let you all know we are still looking into how we can better 
>>> improve and support MSSQL for the Django framework. We’ll continue to sync 
>>> with Michael and let you know of any updates soon. 
>>>
>>> Christiano and Tim - thanks for sharing your interest and sharing how 
>>> you are using Django with MSSQL. It's great to learn from your scenarios. 
>>>
>>> If you have any concerns, questions or comments feel free to reach out 
>>> to me at vinsonyu[at]microsoft.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 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/80728ca3-efe3-42c4-a131-8e99a0c40576%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Admin and CSS Custom Properties

[Dmitriy Sintsov]

CSS variables are long time available at server-side via LESS / SASS 
compilers. For example MediaWiki has built-in ResourceLoader that includes 
LESS compiler and JS minifier. It uses caching to re-compile only when 
source .less or .js are changed. Everything works even with IE8. But 
MediaWiki is an "out-of-box use" software not a framework like Django.

When changing colors, most easy way is to use Bootstrap for admin 
templates. In such way, changing colors is as easy as dropping bootstrap 
skin into 'static/css/bootstrap_skin.css' and specifying it with 
Admin.Media subclass css attribute. There are lots of ready bootstrap 3 
skins as well as bootstrap editors. Also it works with old IE and no CSS 
variables are needed (they are compiled separately from Bootstrap source 
code).

On Friday, April 28, 2017 at 3:00:36 PM UTC+3, Collin Anderson wrote:
>
> I suggest supporting IE11+, as that's the latest on Windows 7 and there's 
> not much 9-10 usage. Now's probably a good time to bump them if needed 
> because we're just past an LTS.
>
> Though, yes, it doesn't allow CSS variables.
>
> On Fri, Apr 28, 2017 at 6:38 AM, Curtis Maloney  > wrote:
>
>> I recently discovered that the stated "policy" on browser support in 
>> Admin is... well... not clear at all.
>>
>>
>> https://docs.djangoproject.com/en/1.11/faq/admin/#what-browsers-are-supported-for-using-the-admin
>>
>> It claims to support full function for "YUI's A-Grade" browsers, but the 
>> link it provides does nothing to explain the supported versions, and a 
>> further "target environments matrix" link still lists IE6.
>>
>> So perhaps it's time to update the FAQ, and have a discussion on what 
>> Admin's browser support policy needs to be updated to.
>>
>> --
>> Curtis
>>
>> On 28/04/17 19:14, Patrick Guido wrote:
>>
>>> On 27 April 2017 at 23:18, Adam Johnson 
>>> > wrote:
>>>
>>> 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.
>>>
>>> I guess it also depends on use cases, usually (where I work) we tend to
>>> support only latest browsers when it comes to admin, since
>>> it will be used by only a few people :) But I see your point.
>>>
>>> A friend of mine was suggesting configuring colours in python, but this
>>> means that the css would be rendered via python, which is
>>> not ideal.
>>> Another solution would be to add a JS polyfill to make it work on older
>>> browsers, but I'm against it :)
>>> Let's also keep in mind that this (if approved) will be included in
>>> django 2.0 or later, so the browser support will be even better :)
>>>
>>>
>>> 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.
>>>
>>> Uhm, I think we can easily skip one request if the colours have not been
>>> overridden. We can put the vars in base.css.
>>> Then we can add the variables by changing the template (but that's more
>>> cumbersome) either by adding an external css link
>>> or by adding a style tag with the variables.
>>>
>>>
>>> 3. This can be overcome with a test to ensure the two files are in
>>> sync, I guess?
>>>
>>> Uhm, true!
>>>
>>>
>>> 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?
>>>
>>> I haven't checked all the rules, but I think it will require quite a bit
>>> of work. Maybe we can create a "template" file
>>> that can be used to override quite easily the colours, but that doesn't
>>> scale too well I think.
>>>
>>>
>>> --
>>> 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-develop...@googlegroups.com 
>>> .
>>> To post to this group, send email to django-d...@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/CAOUxZcugkWEnyx3wt7uXNYJE_Rgix-5N_iPw