Saturday, January 28, 2017

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

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
<django...@googlegroups.com> 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...@googlegroups.com.
> To post to this group, send email to django...@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.
>

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
<django...@googlegroups.com> 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...@googlegroups.com.
> To post to this group, send email to django...@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.
>

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
<django...@googlegroups.com> 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...@googlegroups.com.
> To post to this group, send email to django...@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.
>

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
<django...@googlegroups.com> 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...@googlegroups.com.
> To post to this group, send email to django...@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.
>

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
<django...@googlegroups.com> 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...@googlegroups.com.
> To post to this group, send email to django...@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.
>

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
<django...@googlegroups.com> 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...@googlegroups.com.
> To post to this group, send email to django...@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+unsubscribe@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/fd393e57-1fd8-46df-be60-f54baaf1d22b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment