Comments on: Office Resource Locator Ported to Django http://www.heikkitoivonen.net/blog/2009/05/26/office-resource-locator-ported-to-django/ A Finn in Silicon Valley - Adventures in Technology Wed, 17 Aug 2011 08:58:27 +0000 hourly 1 http://wordpress.org/?v=3.0.5 By: Heikki Toivonen http://www.heikkitoivonen.net/blog/2009/05/26/office-resource-locator-ported-to-django/comment-page-1/#comment-11511 Heikki Toivonen Wed, 27 May 2009 16:27:26 +0000 http://www.heikkitoivonen.net/blog/?p=833#comment-11511 @James: I was assuming that I'd need to be inside the "mysite" directory to be able create apps with the manage script, which then makes imports of the form mysite.myapp. I know I can manually move myapp elsewhere and modify PYTHONPATH and the imports, but this feels like running through unnecessary hoops. But on second look, it seems like manage.py startapp takes two options (settings, pythonpath) that maybe let you do it without those manual steps. Thanks for the link to the queryset document; for some reason I had missed the existence of the whole document! No wonder I felt limited without seeing this. I know there is a school of thought that thinks templates should not allow any code to run because, well, they are templates. But in practice this seems to lead to hacks to work around this limitation (like the arithmetic example above). This reminds me of the Python "private" members: you indicate you think something is an implementation detail by starting the name with an underscore, but there is nothing stopping others from using it if they have to. I feel like templates should be the same: you should avoid putting code there, but when it makes sense to put some code in a template then please let me. @masklinn: Ah, I think you hit the nail on the head on that MEDIA_URL. Thank you! As for PYTHONPATH, I grant this is probably just a personal preference, but whenever my script or application needs to touch PYTHONPATH it feels like a hack. I prefer putting my things in site-packages, and deploying things in virtualenvs (which, ironically, modifies PYTHONPATH but I don't mind since it is not in my script). But it seems virtualenv has a way to create bootstrap scripts so maybe this could lead to a nice way to deploy a Django app. @James: I was assuming that I’d need to be inside the “mysite” directory to be able create apps with the manage script, which then makes imports of the form mysite.myapp. I know I can manually move myapp elsewhere and modify PYTHONPATH and the imports, but this feels like running through unnecessary hoops. But on second look, it seems like manage.py startapp takes two options (settings, pythonpath) that maybe let you do it without those manual steps.

Thanks for the link to the queryset document; for some reason I had missed the existence of the whole document! No wonder I felt limited without seeing this.

I know there is a school of thought that thinks templates should not allow any code to run because, well, they are templates. But in practice this seems to lead to hacks to work around this limitation (like the arithmetic example above). This reminds me of the Python “private” members: you indicate you think something is an implementation detail by starting the name with an underscore, but there is nothing stopping others from using it if they have to. I feel like templates should be the same: you should avoid putting code there, but when it makes sense to put some code in a template then please let me.

@masklinn: Ah, I think you hit the nail on the head on that MEDIA_URL. Thank you! As for PYTHONPATH, I grant this is probably just a personal preference, but whenever my script or application needs to touch PYTHONPATH it feels like a hack. I prefer putting my things in site-packages, and deploying things in virtualenvs (which, ironically, modifies PYTHONPATH but I don’t mind since it is not in my script). But it seems virtualenv has a way to create bootstrap scripts so maybe this could lead to a nice way to deploy a Django app.

]]> By: masklinn http://www.heikkitoivonen.net/blog/2009/05/26/office-resource-locator-ported-to-django/comment-page-1/#comment-11494 masklinn Wed, 27 May 2009 09:19:40 +0000 http://www.heikkitoivonen.net/blog/?p=833#comment-11494 Re media paths, using RequestContext will inject your settings.MEDIA_URL value in your templates (as {{ MEDIA_URL }}). For PYTHONPATH, how's setting it so that you can "see" your urls a hack? (alternatively, you can use virtualenv, put the app you're working on in your virtualenv directory and launch your servers & al from there) Re media paths, using RequestContext will inject your settings.MEDIA_URL value in your templates (as {{ MEDIA_URL }}).

For PYTHONPATH, how’s setting it so that you can “see” your urls a hack? (alternatively, you can use virtualenv, put the app you’re working on in your virtualenv directory and launch your servers & al from there)

]]> By: James Bennett http://www.heikkitoivonen.net/blog/2009/05/26/office-resource-locator-ported-to-django/comment-page-1/#comment-11487 James Bennett Wed, 27 May 2009 06:55:58 +0000 http://www.heikkitoivonen.net/blog/?p=833#comment-11487 Oh, and missed one point about the template language: in general, it's meant to be much more restrictive than other templating engines. What I've personally found is that if I'm writing a complicated piece of template code to work around a perceived limitation in the language, it's often because I'm really trying to move application logic out into my templates, and I almost always end up refactoring to produce a much cleaner solution. YMMV, of course, which is why we don't force you to use Django's template system :) Oh, and missed one point about the template language: in general, it’s meant to be much more restrictive than other templating engines. What I’ve personally found is that if I’m writing a complicated piece of template code to work around a perceived limitation in the language, it’s often because I’m really trying to move application logic out into my templates, and I almost always end up refactoring to produce a much cleaner solution. YMMV, of course, which is why we don’t force you to use Django’s template system :)

]]> By: James Bennett http://www.heikkitoivonen.net/blog/2009/05/26/office-resource-locator-ported-to-django/comment-page-1/#comment-11486 James Bennett Wed, 27 May 2009 06:53:29 +0000 http://www.heikkitoivonen.net/blog/?p=833#comment-11486 I'm a bit confused as to your trouble with "imports" -- Django applications are simply Python modules, live on the import path like anything else and should be importable like anything else. You *can* stick them elsewhere and do path hacking, but I don't really know of anyone who recommends that (and though the tutorial stuffs an application inside a project directory in order to stay focused on Django and avoid the need to teach people Python basics like the import path, I've been campaigning for a while to change that). Media and templates are harder. The short answer is that I personally don't think there's such a thing as truly portable templates and media for public-facing parts of an application; backend logic is easy, but providing something which A) is good enough for cases where you can make it fit and B) easy enough to override in the majority of cases where you can't is, well, impossible :) The long answer is that you can probably solve this by giving up on Python and instead doing everything through setuptools APIs, but I'm not a big fan of that. Also, you might want to look again at the database API documentation; what you found was simply a shortcut for declaring default ordering for queries on a particular model. The full API documentation lists the "order_by()" method of querysets, which is what you want for per-query ordering: http://docs.djangoproject.com/en/dev/ref/models/querysets/#order-by-fields I’m a bit confused as to your trouble with “imports” — Django applications are simply Python modules, live on the import path like anything else and should be importable like anything else. You *can* stick them elsewhere and do path hacking, but I don’t really know of anyone who recommends that (and though the tutorial stuffs an application inside a project directory in order to stay focused on Django and avoid the need to teach people Python basics like the import path, I’ve been campaigning for a while to change that).

Media and templates are harder. The short answer is that I personally don’t think there’s such a thing as truly portable templates and media for public-facing parts of an application; backend logic is easy, but providing something which A) is good enough for cases where you can make it fit and B) easy enough to override in the majority of cases where you can’t is, well, impossible :)

The long answer is that you can probably solve this by giving up on Python and instead doing everything through setuptools APIs, but I’m not a big fan of that.

Also, you might want to look again at the database API documentation; what you found was simply a shortcut for declaring default ordering for queries on a particular model. The full API documentation lists the “order_by()” method of querysets, which is what you want for per-query ordering:

http://docs.djangoproject.com/en/dev/ref/models/querysets/#order-by-fields

]]>