Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#416 closed task (wontfix)

Automate site introspection for url pattern modules, view methods, template directories, and applications

Reported by: garthk@… Owned by: adrian
Component: contrib.admin Version: 0.91
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


Read this with your best over-the-top advertising voice:

Are you sick of maintaining module-level URL configuration files? Do you keep forgetting to refer to them in your site-level URL configuration file? Have you recently forgotten to populate TEMPLATE_DIRS or INSTALLED_APPS?

You need AUTOSITE!

AUTOSITE has been brought to you by one programmer's bizarre tendency to spend two hours writing 300+ lines of code to replace around 30 lines of code that were taking him less than two minutes per day to maintain. His
insanity is YOUR gain. If only 100 Django programmers benefit from this module, all his hard work will have been worthwhile.


Attachments (1) (11.5 KB) - added by garthk 10 years ago.

Download all attachments as: .zip

Change History (11)

Changed 10 years ago by garthk


comment:1 Changed 10 years ago by garthk@…

Okay, more seriously:

There's still a little that can be done to take manual work out of Django programming. If this were any other framework, I'd hardly bother: why save five minutes when the framework is costing you hours of time just to write a simple application? With Django, that application might only be a half hour job and saving five minutes might be significant.

Automatically figuring out which applications are in a site should be a no-brainer. I'm wading through the directory tree rather than looking through the content_types and packages tables, but either way we should be able to save the user the effort. If it's a package under sitename/apps, it's an application, right?

Similarly, there's no point requiring that the user manually tell us where to find the URL configuration file if it's sitting there in plain sight with an obvious name like sitename/ We're also giving them too much work to do if we insist that they create appname/settings/, appname/settings/urls/, and two files just so that the URLs and settings can live in packages rather than modules.

Eliminating the application-level URL configuration file entirely is arguably a step too far, but given the rest of the infrastructure it was pretty easy.

    # Set the URL pattern as an attribute manually... 
    def index(request): 
       # ...
    index.urlpattern = r'^/?$'

    # ... or use a decorator. 
    def index(request): 
       # ...

Needless to say, whilst I'm going to find pretty handy for my own sites I really wrote it for all the people I've seen on #django muttering about the various problems I've solved. Please feel free to use some or all of it for the core framework.

comment:2 Changed 10 years ago by hugo <gb@…>

Hmm. In my gallery I have two prefixes for URLs - /images/ and /manage/ - that point to two urlpattern configs in the same application (to make use of shortcut notation). So how would I do it with autosite? Will all methods have to have fully qualified urlpatterns - and will the advantage of decoupling app urls from project urls be lost - or will I still have to have a global project-level urlpattern file and all methods of a app will show up under the apps url prefix?

Maybe you should give a full sample on how to use autosite with a project that has two apps with different base urlpatterns, that would make it clearer how autosite is to be used.

comment:3 Changed 10 years ago by adrian

FYI: As of [415], startapp doesn't create a /apps/appname/urls/ directory, so that's no longer as complex.

comment:4 Changed 10 years ago by anonymous

out of sight!

comment:5 Changed 10 years ago by adrian

  • Resolution set to wontfix
  • Status changed from new to closed

The new does some stuff that makes this less complex.

comment:6 Changed 9 years ago by anonymous

Fun Site to view and learn. Look forward to more.

comment:7 Changed 9 years ago by anonymous

  • Component changed from Core framework to Admin interface
  • milestone set to Version 0.92
  • priority changed from normal to low
  • Severity changed from normal to minor
  • Type changed from defect to task
  • Version set to 0.91

comment:8 Changed 9 years ago by anonymous

  • Resolution wontfix deleted
  • Severity changed from minor to critical
  • Status changed from closed to reopened

comment:9 Changed 9 years ago by adrian

  • Resolution set to wontfix
  • Severity changed from critical to normal
  • Status changed from reopened to closed

comment:10 Changed 9 years ago by adrian

  • milestone Version 0.92 deleted

Milestone Version 0.92 deleted

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