Re: Allow usage of widgets in generic class-based views?

[Carlton Gibson]

I'd be pretty sceptical about any extra API here. Even an extra hook seems 
a bit much. 

def get_form_class(self):
base_form = super().get_form_class()
return modelform_factory(self.model, base_form, widgets=...)


Job done, no? 

(This assuming that "Just declare your form class normally" isn't good 
advice in context.) 

Kind Regards,

Carlton

-- 
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/457c3a50-a2a1-450c-be1b-c3a95405392d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default upload permissions

[Carlton Gibson]

Hi all, 

This has come up again. So proposal below.

https://code.djangoproject.com/ticket/30004 "Document TemporaryUploadedFile 
potential permission issues"

Issue is that, with the default settings, you get 0o644 permissions for 
"small" files and 0o600 permissions for "big" ones. 
(Depending on which upload handler is used.)

History: 

* Claude and I discussed this a bit. 
* We are agreed the inconsistent default isn't great. 
* We noted just setting FILE_UPLOAD_PERMISSION solves this. 
* Given FILE_UPLOAD_PERMISSION = None, Claude suggested a patch which would 
"guess" the permissions to use from the process umask.
* I didn't like this: 
   * too clever, and ultimately not our business.
   * Would work for default settings but get in the way once you started 
using the related file upload settings. (And so would need an opt-out.) 
* In the end we just added a note to the deployment checklist. 

This wasn't good enough. (Clearly.) 

*Proposal*: we should change the default for FILE_UPLOAD_PERMISSION to 
0o644 (or maybe 0o664), and document that as a backward incompatible 
change. This would be correct for almost all users.  If you're deliberately 
leveraging `FILE_UPLOAD_PERMISSION = None` it's an easy switch back to the 
current behaviour. 

Can I ask you to comment? Thanks. 

Kind Regards,

Carlton
 



-- 
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/d3ce3fba-340a-4379-9449-80e0c06f6aa1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

A faster paginator for django

[Saleem Jaffer]

Hi all,

The default paginator that comes with Django is inefficient when dealing 
with large tables. This is because the final query for fetching pages uses 
"OFFSET" which is basically a linear scan till the last index of the 
current page. Does it make sense to have a better paginator which does not 
use "OFFSET". 

If this sounds like a good idea, I have some ideas on how to do it and with 
some help from you guys I can implement it.

Saleem

-- 
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/020f66e0-ec58-47e2-be0b-00c3f1688c5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

PROBLEM

[David Figueroa]

In creating my first django project- I'm trying to create my first 
application (polls) through a view as shown below.
I'm finding the error shown in the image in the Annex.
can anybody help me?
I'm following the step-by-step suggested in (
https://docs.djangoproject.com/pt-br/1.11/intro/tutorial01/)
*polls/view.py *
Create your views here.
from django.http import HttpResponse


def index(request):
return HttpResponse("Hello, world. You're at the polls index.")
*pols/urls* 
from django.conf.urls import url

from . import views

urlpatterns = [
url(r'^$', views.index, name='index'),
]
*site1/urls* 
from django.conf.urls import include, url
from django.contrib import admin

urlpatterns = [
url(r'^polls/', include('polls.urls')),
url(r'^admin/', admin.site.urls),
]

-- 
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/485fed22-ceaa-4dc0-b4a3-f44e50e4f4f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PROBLEM

[Carlton Gibson]

Hi David, 

This group is for "Contributions to Django itself". You need to head over 
to Django Users  for 
support questions.

(But it looks like you didn't save your urls.py — the `polls/` route isn't 
shown as being searched.) 

Good luck!

Kind Regards,

Carlton

-- 
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/4e7d0d57-2a54-47a2-9f22-b027e23c3a91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A faster paginator for django

[ludovic coues]

The preferred way for this kind of scenario is to make a third party
package. This let you release new version faster than the Django
development cycle and it's super easy to install thanks to tools like pip.

Once your solution is stable, if it's popular enough, it could be
incorporated into Django.

I'm really curious how you want to do it. I thought there was no other way
to skip some row in an SQL query


On Wed, Dec 5, 2018, 13:15 Saleem Jaffer  Hi all,
>
> The default paginator that comes with Django is inefficient when dealing
> with large tables. This is because the final query for fetching pages uses
> "OFFSET" which is basically a linear scan till the last index of the
> current page. Does it make sense to have a better paginator which does not
> use "OFFSET".
>
> If this sounds like a good idea, I have some ideas on how to do it and
> with some help from you guys I can implement it.
>
> Saleem
>
> --
> 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/020f66e0-ec58-47e2-be0b-00c3f1688c5b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAEuG%2BTar6iM5sctRSyPkOHtmL7u9pM%3D01bUvWn%2BZEeQHZsk2fg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A faster paginator for django

[Jason Johns]

https://www.citusdata.com/blog/2016/03/30/five-ways-to-paginate/ has some 
interesting alternatives.  I believe Django uses the first one. But the 
others have some tradeoffs that might not apply to all the dbs that django 
supports.

-- 
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/b649819f-80c3-4b12-af07-0914c679287a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow usage of widgets in generic class-based views?

[Dan Frankowski]

Ah, I see.

It looks like I can use modelform_factory. So:

class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
model = models.Patient
fields = ['name', 'caregiver_name', 'sex', 'birth_date',
  'residence', 'country']

becomes

from django.forms.models import modelform_factory

_patient_create_form = modelform_factory(
models.Patient,
fields=['name', 'caregiver_name', 'sex', 'birth_date',
'residence', 'country'])

class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
form_class = _patient_create_form
template_name = 'healthdbapp/patient_form.html'

and then I can add the widgets:

from django.forms import HiddenInput

from django.forms.models import modelform_factory

_patient_create_form = modelform_factory(
models.Patient,
fields=['name', 'caregiver_name', 'sex', 'birth_date',
'residence', 'country'],
widgets={'country': HiddenInput()})


class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
form_class = _patient_create_form
template_name = 'healthdbapp/patient_form.html'


Works for me.

On Tue, Dec 4, 2018 at 5:04 PM charettes  wrote:

> I agree with Tim that this is a slippery slope.
>
> Maybe that adding a ModelFormMixin.get_form_class_options() that returns a
> {'fields': self.fields} dict by default and is passed to
> modelform_factory(**kwargs)
> in get_form_class() would be a good compromise?
>
> Best,
> Simon
>
> On Tuesday, December 4, 2018 17:28:39 UTC-5, Tim Graham wrote:
>>
>> What I meant is that modelform_factory() also has these parameters:
>>
>> localized_fields is a list of names of fields which should be localized.
>>
>> labels is a dictionary of model field names mapped to a label.
>>
>> help_texts is a dictionary of model field names mapped to a help text.
>>
>> error_messages is a dictionary of model field names mapped to a
>> dictionary of error messages.
>> field_classes is a dictionary of model field names mapped to a form
>> field class.
>>
>> If we accept the patch for widgets, then are we headed down the road of
>> adding support for the rest of those arguments? Customizing a form directly
>> rather than indirectly via the view seems like better design to me. It
>> doesn't require adding features to ModelFormMixin as they are added to
>> ModelForm.
>>
>> On Tuesday, December 4, 2018 at 4:57:40 PM UTC-5, Dan F wrote:
>>>
>>> https://code.djangoproject.com/ticket/24589
>>>
>>> This ticket has a patch to pass through the "widgets" argument for
>>> generic class-based views.
>>>
>>> It was closed with "won't fix" with this comment: "*I don't think the
>>> possibility of saving a few lines of user code justifies the complexity of
>>> reimplementing the parameters to modelform_factory() as CBV parameters and
>>> methods.*"
>>>
>>> I don't understand. The patch was quite small (doesn't seem complex),
>>> and it could give everyone the ability to overload widgets.
>>>
>>> Aside from just saving lines of code, it also would act more as
>>> expected. I tried using "widgets" before seeing that it didn't work. Also,
>>> it would support not making a new form class where every field just has to
>>> be copied (useless boilerplate).
>>>
>>> Can you accept the patch?
>>>
>> --
> 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/0281164b-9bf7-485f-83ad-
> c0301630c91a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Allow usage of widgets in generic class-based views?

[Alasdair Nicol]

This is getting into django-users territory, but I wanted to point out that 
it's often better to leave out the field instead of using a hidden input.

You can then override the form_valid() method, and set the value before the 
form is saved.

class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
model = models.Patient
fields = ['name', 'caregiver_name', 'sex', 'birth_date',
  'residence']


def form_valid(self, form):

form.instance.country = get_country()  # e.g. get country from 
self.request.user

return super().form_valid(form)


Cheers,
Alasdair


On Wednesday, 5 December 2018 16:06:57 UTC, Dan F wrote:
>
> Ah, I see.
>
> It looks like I can use modelform_factory. So:
>
> class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
> model = models.Patient
> fields = ['name', 'caregiver_name', 'sex', 'birth_date',
>   'residence', 'country']
>
> becomes
>
> from django.forms.models import modelform_factory
>
> _patient_create_form = modelform_factory(
> models.Patient,
> fields=['name', 'caregiver_name', 'sex', 'birth_date',
> 'residence', 'country'])
>
> class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
> form_class = _patient_create_form
> template_name = 'healthdbapp/patient_form.html'
>
> and then I can add the widgets:
>
> from django.forms import HiddenInput
>
> from django.forms.models import modelform_factory
>
> _patient_create_form = modelform_factory(
> models.Patient,
> fields=['name', 'caregiver_name', 'sex', 'birth_date',
> 'residence', 'country'],
> widgets={'country': HiddenInput()})
>
>
> class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
> form_class = _patient_create_form
> template_name = 'healthdbapp/patient_form.html'
>
>
> Works for me.
>
> On Tue, Dec 4, 2018 at 5:04 PM charettes > 
> wrote:
>
>> I agree with Tim that this is a slippery slope.
>>
>> Maybe that adding a ModelFormMixin.get_form_class_options() that returns 
>> a
>> {'fields': self.fields} dict by default and is passed to 
>> modelform_factory(**kwargs)
>> in get_form_class() would be a good compromise? 
>>
>> Best,
>> Simon
>>
>> On Tuesday, December 4, 2018 17:28:39 UTC-5, Tim Graham wrote:
>>>
>>> What I meant is that modelform_factory() also has these parameters:
>>>
>>> localized_fields is a list of names of fields which should be localized.
>>>
>>> labels is a dictionary of model field names mapped to a label.
>>>
>>> help_texts is a dictionary of model field names mapped to a help text.
>>>
>>> error_messages is a dictionary of model field names mapped to a 
>>> dictionary of error messages.
>>> field_classes is a dictionary of model field names mapped to a form 
>>> field class. 
>>>
>>> If we accept the patch for widgets, then are we headed down the road of 
>>> adding support for the rest of those arguments? Customizing a form directly 
>>> rather than indirectly via the view seems like better design to me. It 
>>> doesn't require adding features to ModelFormMixin as they are added to 
>>> ModelForm.
>>>
>>> On Tuesday, December 4, 2018 at 4:57:40 PM UTC-5, Dan F wrote:

 https://code.djangoproject.com/ticket/24589

 This ticket has a patch to pass through the "widgets" argument for 
 generic class-based views.

 It was closed with "won't fix" with this comment: "*I don't think the 
 possibility of saving a few lines of user code justifies the complexity of 
 reimplementing the parameters to modelform_factory() as CBV parameters and 
 methods.*"

 I don't understand. The patch was quite small (doesn't seem complex), 
 and it could give everyone the ability to overload widgets.

 Aside from just saving lines of code, it also would act more as 
 expected. I tried using "widgets" before seeing that it didn't work. Also, 
 it would support not making a new form class where every field just has to 
 be copied (useless boilerplate).

 Can you accept the patch?

>>> -- 
>> 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/0281164b-9bf7-485f-83ad-
>> c0301630c91a%40googlegroups.com 
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this messa

Re: A faster paginator for django

[Adam Johnson]

There are already some packages on listed on djangopackages that claim to
implement different pagination strategies:
https://djangopackages.org/grids/g/pagination/

On Wed, 5 Dec 2018 at 12:37, Jason Johns  wrote:

> https://www.citusdata.com/blog/2016/03/30/five-ways-to-paginate/ has some
> interesting alternatives.  I believe Django uses the first one. But the
> others have some tradeoffs that might not apply to all the dbs that django
> supports.
>
> --
> 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/b649819f-80c3-4b12-af07-0914c679287a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0R%3DHGSmRMs1mGnr9ZEBECPmRwTHF7_7U3FCBaHky69ug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A faster paginator for django

[Curtis Maloney]

On 12/5/18 8:30 PM, Saleem Jaffer wrote:

Hi all,

The default paginator that comes with Django is inefficient when dealing 
with large tables. This is because the final query for fetching pages 
uses "OFFSET" which is basically a linear scan till the last index of 
the current page. Does it make sense to have a better paginator which 
does not use "OFFSET".


If this sounds like a good idea, I have some ideas on how to do it and 
with some help from you guys I can implement it.


There are a number of alternatives to this, as well as low-cost 
solutions to improve OFFSET / LIMIT pagination.


By adding an index to the sorting field(s), it can drastically improve 
the "simple" case.


Beyond that, you start getting into cases with more significant 
trade-offs.  I know Matthew Schinckel was recently working on a drop-in 
replacement paginator that used "keyset pagination" 
https://bitbucket.org/schinckel/django-keyset-pagination


There's a lot of published work on this topic, and I'd be very 
interested to see, at least, a library implementing some of these 
alternatives.


At the very least, we could want to ensure the documentation recommends 
indexing on the ORDERing fields, where possible.


--
Curtis

--
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/f9c52aee-e28c-7ae0-306d-3ae2fbd828ee%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.