Re: limiting the drop down option of a one-to-one relationship in the admin app. is that possible ?

[Mike08]

Ok that makes sense.

Now I have something like this

class modelStudentAdmin(admin.ModelAdmin):
form = modelStudentAdminForm

#Only display students that belong to this user
def get_queryset(self, request):
qs = super(modelStudentAdmin, self).get_queryset(request)

if request.user.is_superuser:
return qs
else:
# Get the school instance
schoolInstance = modelSchool.objects.get(user=request.user)
qs = modelStudent.objects.filter(school=schoolInstance)
return qs

def get_form(self, request, obj=None, **kwargs):
self.fields["first_name"] = "asasa"
#modelStudentAdmin.form['first_name']="FooUSerFs"
#modelStudentAdmin.form.cleaned_data.setdefault("first_name","dsdsds")

#modelStudentAdmin.form.initial={"first_name":"JoeJoe"}
#form.cleaned_data.get('player')
return modelStudentAdmin.form




Now I am not sure how to assign values to fields in the form. Normally when 
assigning a value to a field in the form I would pass initial a dictionary 
in the constructor.
In this case it says

 'NoneType' object does not support item assignment

So my question is how can i mark a field as readonly in the form and assign 
an initial value ?

  

On Saturday, January 28, 2017 at 6:21:34 PM UTC-8, Mike08 wrote:
>
> I currently have a model that looks like this
>
> class modelStudent(models.Model):
> user = models.OneToOneField(User, on_delete=models.CASCADE,null=True, 
> blank=True)
> school   = models.ForeignKey(modelSchool)
>
> Now I also have a modelStudentAdmin of the above model which basically 
> filters out the data seen by the user. The code looks like this
>
> class modelStudentAdmin(admin.ModelAdmin):
> def get_queryset(self, request):
> qs = super(modelStudentAdmin, self).get_queryset(request)
>
> if request.user.is_superuser:
> return qs
> else:
> # Get the school instance
> schoolInstance = modelSchool.objects.get(user=request.user)
> qs = modelStudent.objects.filter(school=schoolInstance)
> return qs
>
> admin.site.register(modelStudent,modelStudentAdmin)
>
> now my question is in the admin when the user attempts to create a new 
> modelStudent for the field "user" all available users are shown in the drop 
> down. My question is if there is a way for me to limit/restrict that drop 
> down to a certain value or (set that drop down value to something and then 
> have the drop down disabled) ? I only want people creating 
> modelStudentAdmin under their respective user field.
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8dd86eb8-7670-4058-bc30-abdf6c81e97b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unclear Debug Message (Bug?) When Invalid Url in Extended Template

[Connor Boyle]

Does not appear to be fixed in Django 1.11a1.

On Monday, January 23, 2017 at 7:31:22 PM UTC-6, Tim Graham wrote:
>
> Could you check with Django 1.11a1? This might be fixed in 
> https://code.djangoproject.com/ticket/27584.
>
> On Saturday, January 21, 2017 at 6:02:27 PM UTC-5, Connor Boyle wrote:
>>
>> I've noticed that when I extend a template that references an invalid url 
>> name, in debug mode, the error message doesn't highlight the erroneous line 
>> in the parent template, but rather shows a section of the child template.
>>
>> For example if "base.html" is just:
>>
>> {% block content %}{% endblock %}
>> Page Three
>>
>> And "page_one.html" is:
>>
>> {% extends 'base.html' %}
>> {% block content %}This is page one{% endblock %}
>>
>> when there is no url named "page_three", debug mode will show an error 
>> message entitled:
>>
>> *NoReverseMatch at /page_one/*
>> Reverse for 'page_three' with arguments '()' and keyword arguments '{}' 
>> not found. 0 pattern(s) tried: []
>>
>> and show a few lines of page_one.html (instead of base.html, where the 
>> error originated). See attached screenshot for example.
>>
>> Debug mode seems to do a fine job of highlighting the invalid line in the 
>> parent template for other errors, such as an {% if %} without an {% 
>> endif %} or an unrecognized tag (e.g. {% asdf %} ).
>>
>> Is this a bug? Or at least a sorely missing feature? Am I crazy for 
>> thinking that this is not how this error should be displayed?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/fdc79d39-1e51-47cd-87fc-baf2c8849697%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: limiting the drop down option of a one-to-one relationship in the admin app. is that possible ?

[Mike08]

I am not sure if i understand this are you suggesting that i return a form 
instead of a queryset ? 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d210035c-ff04-4e70-a41a-6a54404f3e21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: limiting the drop down option of a one-to-one relationship in the admin app. is that possible ?

[Melvyn Sopacua]

On Saturday 28 January 2017 18:21:34 Mike08 wrote:

> now my question is in the admin when the user attempts to create a new
> modelStudent for the field "user" all available users are shown in
> the drop down. My question is if there is a way for me to
> limit/restrict that drop down to a certain value or (set that drop
> down value to something and then have the drop down disabled) ? I
> only want people creating
> modelStudentAdmin under their respective user field.

Set a custom form[1], exclude the User field and in the clean method of that 
form, 
set the user to request.user.

-- 
Melvyn Sopacua


[1] 
https://docs.djangoproject.com/en/1.10/ref/contrib/admin/#adding-custom-validation-to-the-admin

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

limiting the drop down option of a one-to-one relationship in the admin app. is that possible ?

[Mike08]

I currently have a model that looks like this

class modelStudent(models.Model):
user = models.OneToOneField(User, on_delete=models.CASCADE,null=True, 
blank=True)
school   = models.ForeignKey(modelSchool)

Now I also have a modelStudentAdmin of the above model which basically 
filters out the data seen by the user. The code looks like this

class modelStudentAdmin(admin.ModelAdmin):
def get_queryset(self, request):
qs = super(modelStudentAdmin, self).get_queryset(request)

if request.user.is_superuser:
return qs
else:
# Get the school instance
schoolInstance = modelSchool.objects.get(user=request.user)
qs = modelStudent.objects.filter(school=schoolInstance)
return qs

admin.site.register(modelStudent,modelStudentAdmin)

now my question is in the admin when the user attempts to create a new 
modelStudent for the field "user" all available users are shown in the drop 
down. My question is if there is a way for me to limit/restrict that drop 
down to a certain value or (set that drop down value to something and then 
have the drop down disabled) ? I only want people creating 
modelStudentAdmin under their respective user field.



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/efb6b1cb-ca74-4a6e-bcaa-2174e3a8d717%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Signals and dispatch uid

[Melvyn Sopacua]

Hello,

I'm having a hard time figuring out both from docs and code what the best 
strategy is 
for preventing a loop, if in post_save() you need to save the provided instance.

I'm implementing an ImageField that is able to handle multiple arbitrary 
thumbnail 
images.

For that purpose I've registered a signal, analog to what ImageField is doing, 
but using 
the post_save signal as I need to have the already saved original available:

*def contribute_to_class(*self, cls, name, kwargs*):
/super/()*.contribute_to_class*(*cls, name, kwargs*)*/# noinspection 
PyProtectedMember/*if not *cls._meta.abstract*:
*signals.pre_save.connect*(
*self.generate_thumbs, sender*=*cls,*)*

The idea was to have the available thumbnails and their url and path stored in 
a 
PostgreSQL Hstore field. For that to work, I need to save the model again, 
hence the 
loop.

To test how to prevent the loop using dispatch_uid, I've created a small test 
app. The 
model uses a HashedTextField:

*class HashedTextField(*TextField*):def __init__(*self, hash_fieldname, 
***args, 
kwargs*):*self.hash_fieldname *= *hash_fieldname
*/super/(*HashedTextField, self*)*./__init__/*(**args, kwargs*)

def contribute_to_class(*self, cls, name, kwargs*):
/super/(*HashedTextField, self*)*.contribute_to_class*(*cls, name, kwargs*) 
   
*post_save.connect*(*self.hash_field, sender*=*cls*)

def hash_field(*self, instance, ***args, kwargs*):*value *= 
/getattr/(*instance, self.name*)  */# type: *str*/ctx *= 
*Hash*('ripemd160')  */# 
type: HashDescriptor/ctx.update*(*value*)/setattr/(*instance, 
self.hash_fieldname, ctx.hexdigest*())
*instance.save*(*update_fields*=*[self.hash_fieldname]*)

**def deconstruct(*self*):*name, path, args, kwargs *= 
/super/(*HashedTextField, self*)*.deconstruct*()
*kwargs[*'hash_fieldname'*] *= 
*self.hash_fieldname*return *name, path, args, kwargs


(Hash and HashDescriptor are simple wrappers around hashlib, provided below sig 
for 
the interested).

I've tried:
* dispatch_uid in above contribute_to_class, either with a static string or 
dymically 
generated
* the same but then in __init__() (no diff, as __init__() is called when field 
is attached to 
model, not when an instance is created).

I can either use a different approach (save the hash as a ManyToMany) or use 
something like this on the model:

*def __init__(*self, ***args, kwargs*):*self._saving_hash *= False
/super/()*./__init__/*(**args, kwargs*)*

and then update _saving_hash within hash_field(), which is less then ideal as 
it 
requires the consuming model to alter it's __init__().

Am I missing an option to do this with dispatch_uid from within the field?

-- 
Melvyn Sopacua

/# noinspection PyUnresolvedReferences

/*class HashDescriptor(/object/):def update(*self, data, encode*=True**):   
 if 
*encode*:*self._ctx.update*(*data.encode*())else:   
 
*self._ctx.update*(*data*)

def hexdigest(*self*):return *self._ctx.hexdigest*()



class Hash(*HashDescriptor*):*_ctx *= None

def __init__(*self, name*):if *name *in 
*hashlib.algorithms_available*:
*self._ctx *= *hashlib.new*(*name*)else:*self._ctx *= 
*hashlib.sha256*()
/super/(*Hash, self*)*./__init__/*()



*

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

Re: Separator between forms in formset factory

[Grzegorz Tężycki]

How you render your formset. 
You can add separator in your html template:

example:
{% for form in formset.forms %}
{{ form.as_p }}
{% if not forloop.last %}

{% endif %}
{% endfor %}




W dniu sobota, 28 stycznia 2017 15:08:00 UTC+1 użytkownik Jeroen van 
Oorschot napisał:
>
> Hi,
> I'm using a 
> modelformset_factory()
>
> for displaying a form multiple times automatically. This works perfect.
>
> I would like to have some kind of separator between the individual forms 
> in the page. Now the formsetfactory just shows all forms after eachother, 
> and it can be quite hard too see which input belongs to which form.
>
> Does anyone have an idea how to make this? If not, i'd like to request it 
> as a feature on the formset_factory 
> 
> .
>
> Kind regards,
> Jeroen
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ca03d2d0-ecb3-45bc-bdb6-a54822aa8196%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django shell on django admin site

[Grzegorz Tężycki]

Hi everyone.
I created small application which can execute python code in django project 
environment.Maybe someone will be interested and has any suggestions.

django-admin-shell:
https://github.com/djk2/django-admin-shell

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6d6e0491-714b-42f7-acd8-66c00d4ecaab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Debug Toolbar installation

[Vijay Khemlani]

Did you install debug_toolber on your server?

pip install django-debug-toolbar

On 1/28/17, Richard Jackson  wrote:
> Hi everyone,
>
> I've recently installed the Django Debug Toolbar for local use; I've just
> pushed the code online and am greeted with the below error:
>
> [81.95.157.172] out: Traceback (most recent call last):
> [81.95.157.172] out:   File "", line 1, in 
> [81.95.157.172] out:   File
> "/home/rjackson87/.virtualenvs/richardjackson/lib/python2.7/site-packages/django/__init__.py",
>
> line 18, in setup
> [81.95.157.172] out: apps.populate(settings.INSTALLED_APPS)
> [81.95.157.172] out:   File
> "/home/rjackson87/.virtualenvs/richardjackson/lib/python2.7/site-packages/django/apps/registry.py",
>
> line 85, in populate
> [81.95.157.172] out: app_config = AppConfig.create(entry)
> [81.95.157.172] out:   File
> "/home/rjackson87/.virtualenvs/richardjackson/lib/python2.7/site-packages/django/apps/config.py",
>
> line 86, in create
> [81.95.157.172] out: module = import_module(entry)
> [81.95.157.172] out:   File
> "/usr/local/lib/python2.7/importlib/__init__.py", line 37, in import_module
> [81.95.157.172] out: __import__(name)
> [81.95.157.172] out: ImportError: No module named debug_toolbar
> [81.95.157.172] out:
>
> Fatal error: run() received nonzero return code 1 while executing!
>
> Requested: python -c "import
> os;os.environ['DJANGO_SETTINGS_MODULE']='richardjackson.settings';import
> django;django.setup();from django.conf import
> settings;print(settings.STATIC_ROOT)"
> Executed: /bin/bash -l -c "cd /home/rjackson87/webapps/richardjackson
>>/dev/null && source
> /home/rjackson87/.virtualenvs/richardjackson/bin/activate && python -c
> \"import
> os;os.environ['DJANGO_SETTINGS_MODULE']='richardjackson.settings';import
> django;django.setup();from django.conf import
> settings;print(settings.STATIC_ROOT)\""
>
> What should I do to resolve this?
>
> Cheers,
>
> Rich
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/d3657e15-1375-481c-ba6d-f3a97ed0dca5%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CALn3ei33n0c9wxz_%3Depj2er1jbE1PYF8nYRq1sO_91wk8omYSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Moving from django 1.3 to 1.9

[Alan]

Many thanks to you all guys, I will follow this path.

Alan

On 27 January 2017 at 22:05, bobhaugen  wrote:

> I agree with all the advice to go a step at a time.
>
> Here's a bunch of clues and chatter in github issues about how we upgraded
> from 1.4 to 1.8, one minor version at a time.
> https://github.com/FreedomCoop/valuenetwork/issues?q=is%3Aclosed+label%
> 3Aupgrade
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/0d810dcd-9411-4259-9bdb-07144e073677%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Alan Wilter SOUSA da SILVA, DSc
Senior Bioinformatician, UniProt
European Bioinformatics Institute (EMBL-EBI)
European Molecular Biology Laboratory
Wellcome Trust Genome Campus
Hinxton
Cambridge CB10 1SD
United Kingdom
Tel: +44 (0)1223 494588

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

Django Debug Toolbar installation

[Richard Jackson]

Hi everyone,

I've recently installed the Django Debug Toolbar for local use; I've just 
pushed the code online and am greeted with the below error:

[81.95.157.172] out: Traceback (most recent call last):
[81.95.157.172] out:   File "", line 1, in 
[81.95.157.172] out:   File 
"/home/rjackson87/.virtualenvs/richardjackson/lib/python2.7/site-packages/django/__init__.py",
 
line 18, in setup
[81.95.157.172] out: apps.populate(settings.INSTALLED_APPS)
[81.95.157.172] out:   File 
"/home/rjackson87/.virtualenvs/richardjackson/lib/python2.7/site-packages/django/apps/registry.py",
 
line 85, in populate
[81.95.157.172] out: app_config = AppConfig.create(entry)
[81.95.157.172] out:   File 
"/home/rjackson87/.virtualenvs/richardjackson/lib/python2.7/site-packages/django/apps/config.py",
 
line 86, in create
[81.95.157.172] out: module = import_module(entry)
[81.95.157.172] out:   File 
"/usr/local/lib/python2.7/importlib/__init__.py", line 37, in import_module
[81.95.157.172] out: __import__(name)
[81.95.157.172] out: ImportError: No module named debug_toolbar
[81.95.157.172] out:

Fatal error: run() received nonzero return code 1 while executing!

Requested: python -c "import 
os;os.environ['DJANGO_SETTINGS_MODULE']='richardjackson.settings';import 
django;django.setup();from django.conf import 
settings;print(settings.STATIC_ROOT)"
Executed: /bin/bash -l -c "cd /home/rjackson87/webapps/richardjackson 
>/dev/null && source 
/home/rjackson87/.virtualenvs/richardjackson/bin/activate && python -c 
\"import 
os;os.environ['DJANGO_SETTINGS_MODULE']='richardjackson.settings';import 
django;django.setup();from django.conf import 
settings;print(settings.STATIC_ROOT)\""

What should I do to resolve this?

Cheers,

Rich

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d3657e15-1375-481c-ba6d-f3a97ed0dca5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Separator between forms in formset factory

[Michal Petrucha]

On Sat, Jan 28, 2017 at 04:33:47AM -0800, Jeroen van Oorschot wrote:
> Hi,
> I'm using a 
> modelformset_factory()
> 
> for displaying a form multiple times automatically. This works perfect.
> 
> I would like to have some kind of separator between the individual forms in 
> the page. Now the formsetfactory just shows all forms after eachother, and 
> it can be quite hard too see which input belongs to which form.
> 
> Does anyone have an idea how to make this? If not, i'd like to request it 
> as a feature on the formset_factory 
> 
> .
> 
> Kind regards,
> Jeroen

Hi Jeroen,

Have you considered simply iterating over the individual forms in your
template, and including the separator in the for loop? You can find
some examples in the docs [1].

Good luck,

Michal


[1]: 
https://docs.djangoproject.com/en/1.10/topics/forms/formsets/#using-a-formset-in-views-and-templates

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20170128163659.GA23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Am I stupid or is there an essential error in Django 1.10 Docs?

['Peter Müller' via Django users]

I do not think that

"Each view is responsible for doing one of two things: Returning an 
> HttpResponse object containing the content for the requested page, or 
> raising an exception such as Http404. The rest is up to you." 
>

is easy for a beginner to understand. Also the tutorial directly asks me to 
copy and paste the code. And I think everybody agrees that copy pasting is 
teaching almost nothing of value.
 I think an explanation like:

A view processes a request and returns a Response such as a webpage.

is much rather fitting. Also the explanation should be given while the 
first view is written.
However I still get what the tutorial is trying to achieve:
To create a working project and then explain afterwards what each part does.
But then why not deliver a zip-file with all code already written?


As a matter of fact it is easier to use Class based views usually, so 
> calling render explicitly is not that common, but function based views 
> are easier to understand initially. 
>

I agree that this is the case. However my point is that the tutorial should 
not show* every possible way* to make a view.
Rather than just *one way* and stick to it.


To make my argument more short and concise:
The tutorial lacks simplicity and tries to show *everything you could 
possibly imagine* doing with django while not managing to transmit the most 
basic usage.



Am Samstag, 28. Januar 2017 16:31:04 UTC+1 schrieb Vijay Khemlani:
>
> > A quick one is e.g. that there is no explanation of what a view is and 
> what 
> > 
> > its purpose is. 
>
> "The code above maps URLs, as simple regular expressions, to the 
> location of Python callback functions (“views”)" 
>
> "Each view is responsible for doing one of two things: Returning an 
> HttpResponse object containing the content for the requested page, or 
> raising an exception such as Http404. The rest is up to you." 
>
> > For a beginner it would be much more easy to simply user render() from 
> the 
> > beginning on and later show cases where render() is not sufficient to do 
> > the job. 
>
> As a matter of fact it is easier to use Class based views usually, so 
> calling render explicitly is not that common, but function based views 
> are easier to understand initially. 
>
> > If I could I would gladly rewrite the tutorial. But sadly I do not have 
> > enough time to do so. 
>
> Maybe... it's a good thing you don't have time really 
>
> On 1/28/17, 'Peter Müller' via Django users 
> > wrote: 
> > 
> > If I could I would gladly rewrite the tutorial. But sadly I do not have 
> > enough time to do so. 
> > However I think it is bad since it not only completely disregards the 
> zen 
> > of py but also its own principles (DRY etc.) If you need concrete 
> examples 
> > I can name you tons. 
> > A quick one is e.g. that there is no explanation of what a view is and 
> what 
> > 
> > its purpose is. 
> > Also there is literally in part three: "But, don’t do that. It’s 
> silly.". 
> > If I should not do it then do not mention in a beginners tutorial… 
> > Another example here is the "shortcut" render() function. It is a 
> beginners 
> > 
> > tutorial so I do not expect an in-depth explanation of any way possible 
> but 
> > 
> > only the easiest one. 
> > For a beginner it would be much more easy to simply user render() from 
> the 
> > beginning on and later show cases where render() is not sufficient to do 
> > the job. 
> > By far the best tutorial I yet had was of pygame. One well documented 
> > example and the docs were enough to teach me how it works. 
> > 
> > On a side-note (this is only personal preference): 
> > I do not like that the tutorial is part of the documentation. 
> > A tutorial should never be a documentation. A documentation should 
> capture 
> > anything you can do with the framework. 
> > However a tutorial should only show you one way (and also the easiest) 
> of 
> > doing of one certain task. 
> > 
> > Am Freitag, 27. Januar 2017 20:50:39 UTC+1 schrieb Melvyn Sopacua: 
> >> 
> >> https://github.com/django/django/pulls 
> >> 
> >> 
> >> 
> >> The tutorial has a very logical order, going from the database 
> abstraction 
> >> 
> >> up to the template layer and beyond. But feel free to rewrite it and 
> >> submit 
> >> it to the project. 
> >> 
> >> 
> >> 
> >> I never follow tutorials to the letter - for example back when I did it 
> in 
> >> 
> >> Django 1.3, my polls app had an ip-based rate limiter tucked onto 
> existing 
> >> 
> >> code - but it certainly is one of the top tutorials for a framework 
> I've 
> >> seen. 
> >> 
> >> 
> >> 
> >> On Friday 27 January 2017 10:27:46 'Peter Müller' via Django users 
> wrote: 
> >> 
> >> > What do you mean by PR? 
> >> 
> >> > 
> >> 
> >> > Am Freitag, 27. Januar 2017 18:32:23 UTC+1 schrieb Melvyn Sopacua: 
> >> 
> >> > > On Monday 16 January 2017 07:49:00 'Peter Müller' via Django users 
> >> wrote: 
> >> 
> >> > > > Also I used the tutorial just that I abstracted the concept since 
> >>

Re: Am I stupid or is there an essential error in Django 1.10 Docs?

[Vijay Khemlani]

> A quick one is e.g. that there is no explanation of what a view is and what
>
> its purpose is.

"The code above maps URLs, as simple regular expressions, to the
location of Python callback functions (“views”)"

"Each view is responsible for doing one of two things: Returning an
HttpResponse object containing the content for the requested page, or
raising an exception such as Http404. The rest is up to you."

> For a beginner it would be much more easy to simply user render() from the
> beginning on and later show cases where render() is not sufficient to do
> the job.

As a matter of fact it is easier to use Class based views usually, so
calling render explicitly is not that common, but function based views
are easier to understand initially.

> If I could I would gladly rewrite the tutorial. But sadly I do not have
> enough time to do so.

Maybe... it's a good thing you don't have time really

On 1/28/17, 'Peter Müller' via Django users
 wrote:
>
> If I could I would gladly rewrite the tutorial. But sadly I do not have
> enough time to do so.
> However I think it is bad since it not only completely disregards the zen
> of py but also its own principles (DRY etc.) If you need concrete examples
> I can name you tons.
> A quick one is e.g. that there is no explanation of what a view is and what
>
> its purpose is.
> Also there is literally in part three: "But, don’t do that. It’s silly.".
> If I should not do it then do not mention in a beginners tutorial…
> Another example here is the "shortcut" render() function. It is a beginners
>
> tutorial so I do not expect an in-depth explanation of any way possible but
>
> only the easiest one.
> For a beginner it would be much more easy to simply user render() from the
> beginning on and later show cases where render() is not sufficient to do
> the job.
> By far the best tutorial I yet had was of pygame. One well documented
> example and the docs were enough to teach me how it works.
>
> On a side-note (this is only personal preference):
> I do not like that the tutorial is part of the documentation.
> A tutorial should never be a documentation. A documentation should capture
> anything you can do with the framework.
> However a tutorial should only show you one way (and also the easiest) of
> doing of one certain task.
>
> Am Freitag, 27. Januar 2017 20:50:39 UTC+1 schrieb Melvyn Sopacua:
>>
>> https://github.com/django/django/pulls
>>
>>
>>
>> The tutorial has a very logical order, going from the database abstraction
>>
>> up to the template layer and beyond. But feel free to rewrite it and
>> submit
>> it to the project.
>>
>>
>>
>> I never follow tutorials to the letter - for example back when I did it in
>>
>> Django 1.3, my polls app had an ip-based rate limiter tucked onto existing
>>
>> code - but it certainly is one of the top tutorials for a framework I've
>> seen.
>>
>>
>>
>> On Friday 27 January 2017 10:27:46 'Peter Müller' via Django users wrote:
>>
>> > What do you mean by PR?
>>
>> >
>>
>> > Am Freitag, 27. Januar 2017 18:32:23 UTC+1 schrieb Melvyn Sopacua:
>>
>> > > On Monday 16 January 2017 07:49:00 'Peter Müller' via Django users
>> wrote:
>>
>> > > > Also I used the tutorial just that I abstracted the concept since
>>
>> > > > I
>>
>> > > >
>>
>> > > > think the tutorial is more than bad.
>>
>> > >
>>
>> > > Awaiting your PRs.
>>
>> > >
>>
>> > >
>>
>> > > Melvyn Sopacua
>>
>>
>>
>> --
>>
>> Melvyn Sopacua
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/6c24f788-7a60-4118-96d7-58c52376bb30%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CALn3ei0_8Pi2ZC0KJ5U70DpZpuR145TMVqkgW52ce6Sga%2BXZAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Am I stupid or is there an essential error in Django 1.10 Docs?

['Peter Müller' via Django users]

If I could I would gladly rewrite the tutorial. But sadly I do not have 
enough time to do so.
However I think it is bad since it not only completely disregards the zen 
of py but also its own principles (DRY etc.) If you need concrete examples 
I can name you tons.
A quick one is e.g. that there is no explanation of what a view is and what 
its purpose is.
Also there is literally in part three: "But, don’t do that. It’s silly.". 
If I should not do it then do not mention in a beginners tutorial…
Another example here is the "shortcut" render() function. It is a beginners 
tutorial so I do not expect an in-depth explanation of any way possible but 
only the easiest one.
For a beginner it would be much more easy to simply user render() from the 
beginning on and later show cases where render() is not sufficient to do 
the job.
By far the best tutorial I yet had was of pygame. One well documented 
example and the docs were enough to teach me how it works.

On a side-note (this is only personal preference):
I do not like that the tutorial is part of the documentation.
A tutorial should never be a documentation. A documentation should capture 
anything you can do with the framework.
However a tutorial should only show you one way (and also the easiest) of 
doing of one certain task.

Am Freitag, 27. Januar 2017 20:50:39 UTC+1 schrieb Melvyn Sopacua:
>
> https://github.com/django/django/pulls
>
>  
>
> The tutorial has a very logical order, going from the database abstraction 
> up to the template layer and beyond. But feel free to rewrite it and submit 
> it to the project.
>
>  
>
> I never follow tutorials to the letter - for example back when I did it in 
> Django 1.3, my polls app had an ip-based rate limiter tucked onto existing 
> code - but it certainly is one of the top tutorials for a framework I've 
> seen.
>
>  
>
> On Friday 27 January 2017 10:27:46 'Peter Müller' via Django users wrote:
>
> > What do you mean by PR?
>
> > 
>
> > Am Freitag, 27. Januar 2017 18:32:23 UTC+1 schrieb Melvyn Sopacua:
>
> > > On Monday 16 January 2017 07:49:00 'Peter Müller' via Django users 
> wrote:
>
> > > > Also I used the tutorial just that I abstracted the concept since
>
> > > > I
>
> > > > 
>
> > > > think the tutorial is more than bad.
>
> > > 
>
> > > Awaiting your PRs.
>
> > > 
>
> > > 
>
> > > Melvyn Sopacua
>
>  
>
> -- 
>
> Melvyn Sopacua
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6c24f788-7a60-4118-96d7-58c52376bb30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adding line-level profiling to Django admin functions?

[Derek]

I am looking for a way to get detailed profiling information (line-level
timing) for custom Django admin functions - especially actions.

All the various guides and blog posts seem to deal with adding profiling
(e.g. via decorators) to plain Django views, and nothing at all deals with
this aspect of Django.

If there is a simple plug-in or app that can handle this, I'd appreciate
being pointed to it; otherwise, if there is some known way of getting at
this information it would be very helpful to hear about it.

Thanks
Derek

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

Separator between forms in formset factory

[Jeroen van Oorschot]

Hi,
I'm using a 
modelformset_factory()

for displaying a form multiple times automatically. This works perfect.

I would like to have some kind of separator between the individual forms in 
the page. Now the formsetfactory just shows all forms after eachother, and 
it can be quite hard too see which input belongs to which form.

Does anyone have an idea how to make this? If not, i'd like to request it 
as a feature on the formset_factory 

.

Kind regards,
Jeroen

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c11a89d1-ace1-447f-9526-fb090f09d8a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: file fields

[ludovic coues]

The error should give some information on what is going wrong and how to fix it

2017-01-27 23:25 GMT+01:00 ايهاب توفيق :
>
> Thank you for your reply and I try the fixed model but the problem with the
> view that I use to store the files from templets to the db I followed the
> django documents as
>
> def custmoer(request):
> if request.method == 'POST':
> form = CustomerForm(request.POST, request.FILES)
> if form.is_valid():
> form.save()
> return HttpResponseRedirect('/login/custmoer/')
> else:
> return HttpResponseRedirect('/login')
> else:
> form= CustomerForm()
> return render(request, "custmoer.html", {'form':form})
>
>  this will work if it one file filed but for more than one will give erro I
> don’t know how to fix this
>
> بتاريخ الخميس، 26 يناير، 2017 1:04:28 ص UTC+2، كتب ايهاب توفيق:
>>
>> I am new in django and to know how to use multiple file field in the same
>> model can any one help me
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/9edfcc46-e3e6-4ce7-a7ff-8ca12ed16ec8%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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