Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#18859 closed New feature (wontfix)

sample static folder when creating project

Reported by: Julien Bouquillon Owned by: nobody
Component: Core (Management commands) Version: 1.4
Severity: Normal Keywords:
Cc: ke1g Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When beginners starts their first django project, they struggle at their first staticfiles setup.

  • the official tuto doesnt even talk about static files
  • they usually have to hardcode the path in settings.py
  • they usually have to add an entry to their urls.py
  • they have to understand all the staticfiles process and complexity and long doc before using a single CSS or image

So i was wondering what do you guys think about setting up a "default" static dir when creating a new project with django-admin.py
This would just be a demo folder, with a sample image, but working without pain for the beginners.

this could be implemented like this (from the project_template) :

  • add a /static folder in the project directory with a sample image
  • add an entry for staticfiles to project.urls.py
  • setup the correct settings

Advantages of this would be :

  • less friction for beginners
  • demonstration of good practices when dealing with static files (security, names..)
  • better understanding on staticfiles capabilities

My goal is to make django beginners feel more confortable

An idea/suggestion ?

Change History (3)

comment:1 by ke1g, 12 years ago

Cc: ke1g added
Triage Stage: UnreviewedDesign decision needed

I think that there are other good choices for where static (and media) go, whether you are talking about where collectstatic puts things, or an additional directory not related to an app from which collectstatic gets things. I feel that putting a default static in the project directory represents too much of a pressure to accept that as the "correct" place to put it, whether by "project directory" you mean the directory containing manage.py, or the directory containing settings.py.

So I'm not in favor of this change.

in reply to:  description comment:2 by Aymeric Augustin, 12 years ago

Resolution: wontfix
Status: newclosed

During the February sprint in Utrecht, several contributors teamed up to improve the documentation: see #19582 and #19897.

The resulting pull request is here: https://github.com/django/django/pull/889


  • the official tuto doesnt even talk about static files

This is covered by #19582.

  • they usually have to hardcode the path in settings.py

The new tutorial solves this by recommending to put the files in a static/ subdirectory in an application.

  • they usually have to add an entry to their urls.py

Why would they have to do that? I cannot imagine why a beginner starting his first project would refuse to use runserver!

  • they have to understand all the staticfiles process and complexity and long doc before using a single CSS or image.

The tutorial aims at solving this problem. (Technically, your premise is wrong -- they just have to follow blindly three bullet points. But I recognize that most developers fail at this the first time.)


So i was wondering what do you guys think about setting up a "default" static dir when creating a new project with django-admin.py
This would just be a demo folder, with a sample image, but working without pain for the beginners.

I've recently stripped the default project template to the bare minimum, and I'm against adding a file that virtually everyone will have to remove before committing his initial project structure (or later on).

I think the new tutorial strikes the right balance between "just make it work" and "explain how it works". In fact, it was difficult to finding enough content to write a tutorial, because there isn't much more to say than "put you files in a static/ sub-directory of an application" :)

comment:3 by Aymeric Augustin, 12 years ago

Type: UncategorizedNew feature
Note: See TracTickets for help on using tickets.
Back to Top