21

I know there are a lot of naming conventions to build apps (name database tables in the singular, models in uppercase, and packages all lowercase), but I haven't found any recommendations to name related elements. Something like "If you name your url x, then your view should be named xview" would be useful.

I have decided to use the following rules with writing my first Django App, but I feel that I might be breaking some DRYesque principle. Is there anything wrong with how I am naming URL, templates, models and views?

Create

  1. URL: car/put
  2. view: car_put(); view name: car_put
  3. model: Car
  4. template: car_put.html

Read

  1. URL: car/1 (gets car with id 1);
  2. view: car_get(); view name: car_get
  3. model: Car
  4. template: car_get.html

Update

  1. URL: car/patch/1 (edits car with id 1)
  2. view: car_patch(); view name: car_patch
  3. model: Car
  4. template: car_patch.html

Delete

  1. URL: car/delete/1 (deletes car with id 1)
  2. view: car_delete(); view name: car_delete
  3. model: Car
  4. template: car_delete.html

I am not building an API, the naming rules that can be inferred from the above example are inspired by REST, but my purpose is not to build an API, just to better organize my code.

Federico
  • 3,650
  • 4
  • 32
  • 45
  • 1
    It comes to personal preference. You are very explicit in your naming - nothing wrong with that. Personally, I would leave out `car` in my urls and views because I sort them within the app. I do that to keep things more organized and to save myself headaches of searching for things. For my setup, it would be redundant to keep specifying the app all of my information is in. If you keep all of your urls in one place, then your approach is a good one. To summarize, you're doing just fine! (: – jape Aug 04 '15 at 18:43

1 Answers1

40

At first sight there's no standard, but the usual naming convention is perfectly specified in the wonderful Django Rest Framework, which is almost identical to the style found on the Django tutorial but a little more obvious. If you wanna follow a style, follow that one.

For a Car model the URLs would be (styled as action url):

  • list /cars/
  • create /cars/new/
  • detail /cars/1/
  • update /cars/1/edit/
  • delete /cars/1/delete/
  • any methods not dependent on an object /cars/view-name/
  • any methods dependent on a particular object /cars/1/view-name/

Something you forgot are the URL names (unless this is what you mean with 'view name'), which would be model-action. e.g. car-list.

The same model_name plus action is used for the Template names (in snake_case) and the View names (in CapitalCase).

Wait, why CapitalCase? Because a much more important standard than naming conventions is to use the powerful class-based views, as opposed to the old method-based views, which lack inheritance and ease of structuring.

If you read the tutorial you'll notice it begs you to upgrade from method-based to class-based views at around the half-point. Method-based views are useful only for very tiny operations and well, introducing you to Views in the Django Tutorial :P

TL;DR: Do as you wish (though I applaud your OCD :P) but if there's something to take away fromm this post is: use class-based views.

Agustín Lado
  • 1,045
  • 14
  • 15
  • 1
    What about adding wheels to a car? `cars/1/wheel/new` or `/cars/add-wheels`? – Federico Aug 07 '15 at 19:04
  • 4
    I'd go for the first one. However in cases like that where an object is so dependent from another, like a Wheel is to a Car, you can just create them along with the Car like the Django admin does with its inline formsets, so no URL for Wheel would be defined. Also, remember to end the URLs with a `/`. – Agustín Lado Aug 07 '15 at 19:14
  • This may be quite a bit old, but i feel like using `cars/1/wheels/1/new`, just to be consistent with the `set/identifier` style. – arielnmz Jun 14 '16 at 17:56
  • Is the 1 after wheels the PK of the soon to be created wheel? The identifiers are used to identify existing objects. That number is just a guess. What happens if two concurrent requests point toward the same ID? For the second request the ID will be wrong. In the 'new wheel' view you'll get two values, the ID of the car and the ID for the future wheel. You can't do anything with that value because it's likely to be wrong. I'm afraid that naming convention is one that doesn't make sense. – Agustín Lado Jun 14 '16 at 18:26
  • Obviously you can do it however you want; look at how many sites with garbage URLs there are. Even better, look at sites using AngularJS or equivalent JS frameworks, they don't even have URLs that are shown! But be careful when designing an API, if it doesn't make sense the consumers will have trouble programming against it. – Agustín Lado Jun 14 '16 at 18:28
  • 1
    I know it's an old post, but I would like to ask you why you think we have to use class based view i any case ? Some view are very specifics and using a class based view in certain case can be very painfull. Here is a short analyse explaining why function based view can still be used : http://lukeplant.me.uk/blog/posts/djangos-cbvs-were-a-mistake/. Can you tell what do you think about this point ? – Ben Sep 02 '16 at 20:19
  • How would you name an API URL that implements more that just one action? Like e.g. a view that implements list, create, read? – Micromegas Jan 31 '20 at 12:51