4 ms·

These are pretty good. I really liked #6, the tip for template_tags. I hadn't thought of that before and will definitely do that. I will also look into extensio

These are pretty good. I really liked #6, the tip for template_tags. I hadn't thought of that before and will definitely do that. I will also look into extensions of the template system as suggested at the bottom. Those were really helpful, even for someone who has been using Django for a few months. I disagree with #4, the suggestion to not include business logic in views. What Django calls 'views' are what other frameworks call 'controllers' (MTV=MVC), and the business logic should reside there. I'm totally for separating the code into helper functions in other files, but putting business logic into models definitely violates the idea of MVC. For #5, I would recommend the second approach of having a separate settings.py for production vs development. Or at least code it where DEBUG=False is only overridden if socket confirms you are on a development machine - not the other way around. Debug contains too much info to risk exposing in production, but maybe my fear of socket screwing up is unfounded.

mhb 17y ago
For template tags, is doing it that way better than importing them in a base template which is included by the children templates?
- kennethlove 17y ago
  Templatetags don't inherit (at least not in my experience) so if you don't want to have to load the tags on every template, add them to your global templatetags: http://www.djangosnippets.org/snippets/160/ http://www.djangosnippets.org/snippets/160/
jsdalton 17y ago
Not to get into a pedantic argument with you, friend, but the generally accepted definition of "model" in the MVC pattern is "the place that holds your business logic." See http://en.wikipedia.org/wiki/Model-view-controller http://en.wikipedia.org/wiki/Model-view-controller, for example (the article uses the term "domain logic," but it's the same thing - http://en.wikipedia.org/wiki/Domain_logic http://en.wikipedia.org/wiki/Domain_logic).
phernandez 17y ago
Re: #4 My 2 cents: I come from a Java web background, so I may be a bit biased. I like to think of the view functions as controlling state in an app and deciding what do show on a page (handing input or sticking stuff in the request). Something in between the presentation logic (in templates) or "business logic". I think the django docs suggest that business (or domain) logic should go in the model (in an extra method) if it pertains to a particular instance of the model - or row in the db. Class level logic should go in a Manager for the model - like doing special queries, for example. As an aside, I think that this approach makes my code pretty easy to test, I can whip up a test case that uses data in fixtures without having to worry about the view. Using something like the command_extensions makes it pretty easy to prototype model/manager code in the python shell against real data in my dev env. This is probably my favorite thing about working with python/django over java.

mhb 17y ago

For template tags, is doing it that way better than importing them in a base template which is included by the children templates?

kennethlove 17y ago
Templatetags don't inherit (at least not in my experience) so if you don't want to have to load the tags on every template, add them to your global templatetags: http://www.djangosnippets.org/snippets/160/ http://www.djangosnippets.org/snippets/160/

jsdalton 17y ago

Not to get into a pedantic argument with you, friend, but the generally accepted definition of "model" in the MVC pattern is "the place that holds your business logic." See http://en.wikipedia.org/wiki/Model-view-controller http://en.wikipedia.org/wiki/Model-view-controller, for example (the article uses the term "domain logic," but it's the same thing - http://en.wikipedia.org/wiki/Domain_logic http://en.wikipedia.org/wiki/Domain_logic).

phernandez 17y ago

Re: #4 My 2 cents: I come from a Java web background, so I may be a bit biased. I like to think of the view functions as controlling state in an app and deciding what do show on a page (handing input or sticking stuff in the request). Something in between the presentation logic (in templates) or "business logic". I think the django docs suggest that business (or domain) logic should go in the model (in an extra method) if it pertains to a particular instance of the model - or row in the db. Class level logic should go in a Manager for the model - like doing special queries, for example. As an aside, I think that this approach makes my code pretty easy to test, I can whip up a test case that uses data in fixtures without having to worry about the view. Using something like the command_extensions makes it pretty easy to prototype model/manager code in the python shell against real data in my dev env. This is probably my favorite thing about working with python/django over java.