お気に入りDjangoヒントと機能？
「...の隠された機能」という質問シリーズに触発されて、お気に入りのDjangoヒントまたはあまり知られていないが有用な機能について聞いてみたいです。
- 回答ごとに1つのヒントのみを含めてください。
- Djangoバージョン要件がある場合は追加します。
私は自分自身からのヒントから始めるつもりです:)
settings.pyでos.path.dirname（）を使用して、ハードコードされたディレクトリ名を回避します。
別の場所でプロジェクトを実行する場合は、settings.pyにパスをハードコードしないでください。テンプレートと静的ファイルがDjangoプロジェクトディレクトリ内にある場合は、settings.pyで次のコードを使用します。
# settings.py
import os
PROJECT_DIR = os.path.dirname(__file__)
...
STATIC_DOC_ROOT = os.path.join(PROJECT_DIR, "static")
...
TEMPLATE_DIRS = (
os.path.join(PROJECT_DIR, "templates"),
)
クレジット：このヒントはスクリーンキャスト ' Django From the Ground Up 'から得ました。
Django Command Extensions および pygraphviz をインストールし、次のコマンドを発行して見栄えの良いDjangoモデルの視覚化を取得します。
./manage.py graph_models -a -g -o my_project.png
render_toの代わりに Django-annoying'srender_to_responseデコレーターを使用します。
@render_to('template.html')
def foo(request):
bars = Bar.objects.all()
if request.user.is_authenticated():
return HttpResponseRedirect("/some/url/")
else:
return {'bars': bars}
# equals to
def foo(request):
bars = Bar.objects.all()
if request.user.is_authenticated():
return HttpResponseRedirect("/some/url/")
else:
return render_to_response('template.html',
{'bars': bars},
context_instance=RequestContext(request))
HttpResponse（リダイレクトなど）を返すとデコレータが短絡し、期待どおりに動作することを指摘するように編集されました。
サイトのテンプレート全体で使用するカスタムタグのセットがあります。それを自動ロードする方法を探して（DRY、覚えていますか？）、私は次のことを見つけました：
from Django import template
template.add_to_builtins('project.app.templatetags.custom_tag_module')
これをデフォルトでロードされるモジュール（メインurlconfなど）に配置すると、カスタムタグモジュールのタグとフィルターが、{% load custom_tag_module %}を使用せずに、任意のテンプレートで使用できるようになります。
template.add_to_builtins()に渡される引数には、任意のモジュールパスを指定できます。カスタムタグモジュールは特定のアプリケーションに存在する必要はありません。たとえば、プロジェクトのルートディレクトリにあるモジュール（'project.custom_tag_module'など）にすることもできます。
Virtualenv + Python =複数のDjangoプロジェクトで作業していて、それらがすべて同じバージョンに依存しない可能性がある場合は、命の恩人Django /アプリケーション。
URLをハードコーディングしないでください！
代わりに rl names を使用し、 reverse 関数を使用してURL自体を取得します。
URLマッピングを定義するときは、URLに名前を付けます。
urlpatterns += ('project.application.views'
url( r'^something/$', 'view_function', name="url-name" ),
....
)
名前がURLごとに一意であることを確認してください。
私は通常、一貫した形式の「プロジェクトアプリケーションビュー」を持っています。スレッドビューの場合は「cbx-forum-thread」。
UPDATE（恥知らずに盗む ayazの追加 ）：
この名前は、テンプレートで urlタグ で使用できます。
Djangoデバッグツールバー を使用します。たとえば、ビューのレンダリング中に実行されたすべてのSQLクエリを表示できます。また、それらのスタックトレースを表示することもできます。
独自のログインページを作成しないでください。 Django.contrib.authを使用している場合。
実際の汚い秘密は、Django.contrib.adminも使用していて、Django.template.loaders.app_directories.load_template_sourceがテンプレートローダーにある場合、テンプレートも無料で入手できる！
# somewhere in urls.py
urlpatterns += patterns('Django.contrib.auth',
(r'^accounts/login/$','views.login', {'template_name': 'admin/login.html'}),
(r'^accounts/logout/$','views.logout'),
)
コンテキストプロセッサは素晴らしいです。
別のユーザーモデルがあり、それをすべての応答に含めたいとします。これを行う代わりに：
def myview(request, arg, arg2=None, template='my/template.html'):
''' My view... '''
response = dict()
myuser = MyUser.objects.get(user=request.user)
response['my_user'] = myuser
...
return render_to_response(template,
response,
context_instance=RequestContext(request))
コンテキストプロセスを使用すると、変数をテンプレートに渡すことができます。私は通常'my_project/apps/core/context.pyに私のものを入れます：
def my_context(request):
try:
return dict(my_user=MyUser.objects.get(user=request.user))
except ObjectNotFound:
return dict(my_user='')
settings.pyで、次の行をTEMPLATE_CONTEXT_PROCESSORSに追加します
TEMPLATE_CONTEXT_PROCESSORS = (
'my_project.apps.core.context.my_context',
...
)
これで、リクエストが作成されるたびに、自動的にmy_userキーが含まれます。
また signals win。
数か月前にこれについてブログ記事を書いたので、切り取りと貼り付けを行います。
すぐに使えるDjangoは、信じられないほど便利ないくつかのシグナルを提供します。保存、初期化、削除、またはリクエストの処理中であっても、事前および事後の処理を実行できます。それでは、概念から離れて、これらがどのように使用されるかを示しましょう。ブログがあるとしましょう
from Django.utils.translation import ugettext_lazy as _
class Post(models.Model):
title = models.CharField(_('title'), max_length=255)
body = models.TextField(_('body'))
created = models.DateTimeField(auto_now_add=True)
そのため、どういうわけか、新しい投稿を作成した多くのブログpingサービスの1つに通知し、最新の投稿キャッシュを再構築して、それについてツイートしたいと思います。シグナルを使用すると、Postクラスにメソッドを追加することなく、これらすべてを実行できます。
import Twitter
from Django.core.cache import cache
from Django.db.models.signals import post_save
from Django.conf import settings
def posted_blog(sender, created=None, instance=None, **kwargs):
''' Listens for a blog post to save and alerts some services. '''
if (created and instance is not None):
Tweet = 'New blog post! %s' instance.title
t = Twitter.PostUpdate(settings.Twitter_USER,
settings.Twitter_PASSWD,
Tweet)
cache.set(instance.cache_key, instance, 60*5)
# send pingbacks
# ...
# whatever else
else:
cache.delete(instance.cache_key)
post_save.connect(posted_blog, sender=Post)
その関数を定義し、post_init信号を使用して関数をPostモデルに接続し、保存後に実行します。
私が始めたとき、 Paginator があったことを知りませんでした、その存在を知っていることを確認してください!!
IPython を使用して、任意のレベルでコードにジャンプし、IPythonのパワーを使用してデバッグします。 IPythonをインストールしたら、次のコードをデバッグしたい場所に配置するだけです。
from IPython.Shell import IPShellEmbed; IPShellEmbed()()
次に、ページを更新し、実行サーバーウィンドウに移動すると、インタラクティブなIPythonウィンドウが表示されます。
TextMateにスニペットが設定されているため、ipshellと入力してTabキーを押します。それなしでは生きていけませんでした。
開発用SMTPサーバーを実行します。これは、送信されたものをすべて出力します（開発用サーバーに実際にSMTPをインストールしたくない場合）。
コマンドライン：
python -m smtpd -n -c DebuggingServer localhost:1025
Django-admin documentation から：
Bashシェルを使用する場合は、Djangoディストリビューションのextras/Django_bash_completionにあるDjango bash完了スクリプトのインストールを検討してください。 Django-admin.pyおよびmanage.pyコマンドのタブ補完が可能になるため、たとえば次のことができます...
Django-admin.pyと入力します。- [TAB]を押して、使用可能なすべてのオプションを表示します。
- 名前が
sqlで始まるすべての使用可能なオプションを表示するには、sql、次に[TAB]を入力します。
Django_extensions に付属する./manage.py runserver_plus機能は本当に素晴らしいです。
特に、Werkzeugデバッガーを使用して、スタック内の各ポイントのインタラクティブなデバッグコンソールを作成する拡張デバッグページを作成します（スクリーンショットを参照）。また、オブジェクト/フレームに関する情報を表示するための非常に便利な便利なデバッグ方法dump()も提供します。
インストールするには、pipを使用できます。
pip install Django_extensions
pip install Werkzeug
次に'Django_extensions'をINSTALLED_APPSのsettings.pyタプルに追加し、新しい拡張子で開発サーバーを起動します。
./manage.py runserver_plus
これにより、デバッグ方法が変わります。
Djangoと別のアプリケーションとの間でデータを交換しようとするとき、request.raw_post_dataは良い友達です。これを使用して、XMLデータなどのカスタム処理を行います。
ドキュメント： http://docs.djangoproject.com/en/dev/ref/request-response/
Pythonデバッガーpdbを使用してDjangoプロジェクトをデバッグするのが好きです。
これは、使用方法を学習するのに役立つリンクです。 http://www.ferg.org/papers/debugging_in_python.html
ビューコードにassert Falseを追加して、デバッグ情報をダンプします。
Djangoと一緒に Jinja2 を使用します。
（私のように）Djangoテンプレート言語が非常に制限されている場合は、それにこだわる必要はありません。 Djangoは柔軟性があり、テンプレート言語はシステムの他の部分と疎結合されているため、別のテンプレート言語をプラグインして、それを使用してhttp応答をレンダリングします。
Jinja2 を使用します。これはDjangoテンプレート言語のパワーアップバージョンのようなもので、同じ構文を使用し、ifステートメントで式を使用できます。 if_item_in_listなどのカスタムifタグを作成する必要はありません！単に%{ if item in list %}または{% if object.field < 10 %}と発声できます。
しかし、それだけではありません。テンプレートの作成を容易にするための多くの機能がありますが、それらすべてをここで説明することはできません。
これにより、上記の Django URL名と逆URLディスパッチ に関する返信に追加されます。
URL名は、テンプレート内でも効果的に使用できます。たとえば、特定のURLパターンの場合：
url(r'(?P<project_id>\d+)/team/$', 'project_team', name='project_team')
テンプレートには次のものを含めることができます。
<a href="{% url project_team project.id %}">Team</a>
Djangoの「ビュー」はHttpResponseを返す呼び出し可能オブジェクトである必要があるため、Rubyおよびその他のフレームワーク上のRailsのようなクラスベースのビューを簡単に作成できます。 。
クラスベースのビューを作成するにはいくつかの方法がありますが、私のお気に入りは次のとおりです。
from Django import http
class RestView(object):
methods = ('GET', 'HEAD')
@classmethod
def dispatch(cls, request, *args, **kwargs):
resource = cls()
if request.method.lower() not in (method.lower() for method in resource.methods):
return http.HttpResponseNotAllowed(resource.methods)
try:
method = getattr(resource, request.method.lower())
except AttributeError:
raise Exception("View method `%s` does not exist." % request.method.lower())
if not callable(method):
raise Exception("View method `%s` is not callable." % request.method.lower())
return method(request, *args, **kwargs)
def get(self, request, *args, **kwargs):
return http.HttpResponse()
def head(self, request, *args, **kwargs):
response = self.get(request, *args, **kwargs)
response.content = ''
return response
ベースビューには、条件付きリクエストの処理や承認など、他のあらゆるものを追加できます。
ビューを設定したら、urls.pyは次のようになります。
from Django.conf.urls.defaults import *
from views import MyRestView
urlpatterns = patterns('',
(r'^restview/', MyRestView.dispatch),
)
render_to_responseを使用してコンテキストをテンプレートにバインドしてレンダリングする（Djangoドキュメントで通常表示される）代わりに、汎用ビュー direct_to_template を使用します。 render_to_responseと同じことを行いますが、自動的にRequestContextをテンプレートコンテキストに追加し、暗黙的にコンテキストプロセッサの使用を許可します。 render_to_responseを使用して手動でこれを行うことができますが、なぜ面倒なのですか？覚えておくべきもう1つのステップであり、もう1つのLOCです。コンテキストプロセッサを利用する以外に、テンプレートにRequestContextを含めると、次のようなことができます。
<a href="{{MEDIA_URL}}images/frog.jpg">A frog</a>
これは非常に便利です。実際、一般的なビューでは一般的に+1。 Djangoのドキュメントは、単純なアプリ用のviews.pyファイルさえも持たないためのショートカットとして主にそれらを示していますが、独自のビュー関数内で使用することもできます。
from Django.views.generic import simple
def article_detail(request, slug=None):
article = get_object_or_404(Article, slug=slug)
return simple.direct_to_template(request,
template="articles/article_detail.html",
extra_context={'article': article}
)
問題のコメントに返信するのに十分な評判はありませんが、 Jinja を使用する場合、テンプレートブロック名の '-'文字をサポートしないことに注意することが重要です、Djangoは同じです。これにより、多くの問題が発生し、生成された非常に不明瞭なエラーメッセージを追跡しようとして時間を浪費しました。
webdesign app は、Webサイトの設計を開始するときに非常に便利です。インポートしたら、これを追加してサンプルテキストを生成できます。
{% load webdesign %}
{% lorem 5 p %}
Django.db.models.get_modelを使用すると、モデルをインポートせずに取得できます。
Jamesは、それがどれほど便利かを示しています。 "Djangoのヒント：より良いテンプレートタグの作成—反復4" 。
"manage.py runserver"で実行できる開発サーバーがあることは誰もが知っていますが、静的ファイル（CSS/JS/IMG）を提供するための開発ビューがあることをご存知ですか？
Djangoには静的ファイルを提供する方法がないため、新参者は常に困惑します。これは、開発チームが実際のWebサーバーの仕事だと考えているためです。
しかし、開発時には、Apache + mod_wisgiをセットアップしたくない場合があります。その後、次をurls.pyに追加するだけです。
(r'^site_media/(?P<path>.*)$', 'Django.views.static.serve',
{'document_root': '/path/to/media'}),
CSS/JS/IMGは、www.yoursite.com/site_media /で入手できます。
もちろん、実稼働環境では使用しないでください。
これは sorl-thumbnails アプリのドキュメントから学びました。テンプレートタグで「as」キーワードを使用して、テンプレートの他の場所で呼び出しの結果を使用できます。
例えば：
{% url image-processor uid as img_src %}
<img src="{% thumbnail img_src 100x100 %}"/>
これは、Django templatetagドキュメントを渡す際に言及されていますが、ループのみを参照しています。彼らは、これを他の場所（どこでも）でも使用できるとは言っていません。
PyCharm IDE は、Djangoの組み込みサポートを備えた、コーディング、特にデバッグに適した環境です。
Django.views.generic.list_detail.object_list -ページネーション用のすべてのロジックとテンプレート変数を提供します（私が今までに何度も書いたものの1つ）。 ラッピング は、必要なロジックを許可します。このgemを使用すると、「検索結果」ページでのオフバイワンエラーのデバッグに何時間も費やすことがなくなり、その過程でビューコードがきれいになります。
データベースの移行を使用します。 South を使用します。
xml_models を使用して、（SQLの代わりに）XML Django APIバックエンドを使用するRESTモデルを作成します。これは、特にサードパーティのAPIをモデリングする場合に非常に役立ちます。これまで使用していたQuerySet構文をすべて取得できます。 PyPIからインストールできます。
APIからのXML：
<profile id=4>
<email>[email protected]</email>
<first_name>Joe</first_name>
<last_name>Example</last_name>
<date_of_birth>1975-05-15</date_of_birth>
</profile>
そして今、Pythonで：
class Profile(xml_models.Model):
user_id = xml_models.IntField(xpath='/profile/@id')
email = xml_models.CharField(xpath='/profile/email')
first = xml_models.CharField(xpath='/profile/first_name')
last = xml_models.CharField(xpath='/profile/last_name')
birthday = xml_models.DateField(xpath='/profile/date_of_birth')
finders = {
(user_id,): settings.API_URL +'/api/v1/profile/userid/%s',
(email,): settings.API_URL +'/api/v1/profile/email/%s',
}
profile = Profile.objects.get(user_id=4)
print profile.email
# would print '[email protected]'
また、関係とコレクションも処理できます。頻繁に使用される製品コードで毎日使用しているため、ベータ版でも非常に便利です。また、テストで使用できるスタブの優れたセットもあります。
（免責事項：私はこのライブラリの作成者ではありませんが、いくつかのマイナーなコミットを行ったコミッターです）
次のリンクを見つけました： http://lincolnloop.com/Django-best-practices/#table-of-contents -「Django Best Practices」。
クエリセット全体を評価して結果が返されたかどうかを確認する代わりに、以前のバージョンではDjango 1.2+および.count（）で.exists（）を使用します。
Exists（）とcount（）は両方ともorder by句をクリアし、DBから単一の整数を取得します。ただし、exists（）は常に1を返します。カウントは、制限が手動で適用されるより高い値を返す場合があるためです。 has_result がexists（）で使用され、 get_count がcount（）で好奇心のために使用されるソース。
どちらも単一の整数を返すため、モデルのインスタンス化、メモリ内のモデル属性のロード、およびDBとアプリの間で渡される大きなTextFieldはありません。
すでにクエリを評価している場合、.count（）はlen（cached_result）を計算し、.exists（）はbool（cached_result）を計算します
非効率的-例1
books = Books.objects.filter(author__last_name='Brown')
if books:
# Do something
非効率的-例2
books = Books.objects.filter(author__last_name='Brown')
if len(books):
# Do something
効率的-例1
books = Books.objects.filter(author__last_name='Brown')
if books.count():
# Do something
効率的-例2
books = Books.objects.filter(author__last_name='Brown')
if books.exists():
# Do something
モデルに変更を加えた場合
./manage.py dumpdata appname > appname_data.json
./manage.py reset appname
Django-admin.py loaddata appname_data.json
signals を使用して、オンザフライでアクセサメソッドを追加します。
Django-photologue でこの手法を見ました：追加されたすべてのSizeオブジェクトに対して、post_initシグナルは対応するメソッドをImageモデルに追加します。サイトgiantを追加する場合、巨大な解像度で画像を取得する方法はimage.get_giant_url()になります。
メソッドは、add_accessor_methods信号からpost_initを呼び出すことで生成されます。
def add_accessor_methods(self, *args, **kwargs):
for size in PhotoSizeCache().sizes.keys():
setattr(self, 'get_%s_size' % size,
curry(self._get_SIZE_size, size=size))
setattr(self, 'get_%s_photosize' % size,
curry(self._get_SIZE_photosize, size=size))
setattr(self, 'get_%s_url' % size,
curry(self._get_SIZE_url, size=size))
setattr(self, 'get_%s_filename' % size,
curry(self._get_SIZE_filename, size=size))
実際の使用法については、 photologue.modelsのソースコード を参照してください。
Settings.pyからデータベースアクセス情報を削除します
Djangoサイトのsettings.pyで行ったことの1つは、/etcのファイルからデータベースアクセス情報をロードすることです。このように、アクセスのセットアップ（データベースホスト、ポート、ユーザー名、パスワード）はマシンごとに異なる場合があり、パスワードなどの機密情報は私のプロジェクトのリポジトリにはありません。別のユーザー名で接続することにより、同様の方法でワーカーへのアクセスを制限することができます。
また、環境変数を介してデータベース接続情報、または単にキーまたは設定ファイルへのパスを渡し、settings.pyで処理することもできます。
たとえば、データベース構成ファイルを取り込む方法は次のとおりです。
g = {}
dbSetup = {}
execfile(os.environ['DB_CONFIG'], g, dbSetup)
if 'databases' in dbSetup:
DATABASES = dbSetup['databases']
else:
DATABASES = {
'default': {
'ENGINE': 'Django.db.backends.mysql',
# ...
}
}
言うまでもなく、DB_CONFIG内のファイルは、db adminsおよびDjango自体以外のユーザーがアクセスできないようにする必要があります。デフォルトのケースでは、Djangoを開発者自身のテストデータベースに参照する必要があります。 astの代わりにexecfileモジュールを使用するより良い解決策もありますが、まだ調査していません。
別のことは、DB管理タスクと他のすべてに個別のユーザーを使用することです。 manage.pyに、次のプリアンブルを追加しました。
# Find a database configuration, if there is one, and set it in the environment.
adminDBConfFile = '/etc/Django/db_admin.py'
dbConfFile = '/etc/Django/db_regular.py'
import sys
import os
def goodFile(path):
return os.path.isfile(path) and os.access(path, os.R_OK)
if len(sys.argv) >= 2 and sys.argv[1] in ["syncdb", "dbshell", "migrate"] \
and goodFile(adminDBConfFile):
os.environ['DB_CONFIG'] = adminDBConfFile
Elif goodFile(dbConfFile):
os.environ['DB_CONFIG'] = dbConfFile
/etc/Django/db_regular.pyの設定は、SELECT、INSERT、UPDATE、およびDELETEを使用してDjangoデータベースのみにアクセスするユーザー用であり、/etc/Django/db_admin.pyはこれらの権限に加えて、 CREATE、DROP、INDEX、ALTER、およびLOCK TABLES。 （migrateコマンドは South からのものです。）これにより、実行時にスキーマに干渉するDjangoコードからの保護が得られ、SQLインジェクション攻撃による被害が制限されます。原因となる可能性があります（ただし、すべてのユーザー入力を確認およびフィルターする必要があります）。
（ 別の質問 への回答からコピー）
LocalhostでDjango devサーバーを実行する代わりに、適切なネットワークインターフェイスで実行します。例えば：
python manage.py runserver 192.168.1.110:8000
または
python manage.py runserver 0.0.0.0:8000
次に、Fiddler（ http://www.fiddler2.com/fiddler2/ ）またはHTTP Debugger（ http://www.httpdebugger.com/ ）HTTPヘッダーを検査しますが、テストするためにLAN上の他のマシンから開発サイトにアクセスすることもできます。
ただし、devサーバーは最小限で比較的安全ですが、ファイアウォールで保護されていることを確認してください。
Django Debug Toolbar は本当に素晴らしいです。実際にはツールバーではなく、見ているページをもたらしたものに関するあらゆる種類の情報（DBクエリ、テンプレートに送信されたコンテキスト変数、シグナルなど）を示すサイドペインを実際に表示します。
カスタムビューデコレータでwrapsデコレータを使用して、ビューの名前、モジュール、およびdocstringを保持します。例えば。
try:
from functools import wraps
except ImportError:
from Django.utils.functional import wraps # Python 2.3, 2.4 fallback.
def view_decorator(fun):
@wraps(fun)
def wrapper():
# here goes your decorator's code
return wrapper
注意：作成者が__call__プロパティを定義していない場合、クラスベースのビュー（__name__メソッド定義を持つビュー）では機能しません。回避策として使用：
from Django.utils.decorators import available_attrs
...
@wraps(fun, assigned=available_attrs(fun))
「apps」フォルダーを使用して、PYTHONPATHを編集せずにアプリケーションを整理する
これは、次のようにフォルダを整理するときに便利です。
apps/
foo/
bar/
site/
settings.py
urls.py
pYTHONPATHを上書きしたり、次のようなすべてのインポートにappsを追加する必要はありません。
from apps.foo.model import *
from apps.bar.forms import *
Settings.pyに追加します
import os
import sys
PROJECT_ROOT = os.path.abspath(os.path.dirname(__file__))
sys.path.insert(0, os.path.join(PROJECT_ROOT, "apps"))
これで準備完了です:-)
私はこれを http://codespatter.com/2009/04/10/how-to-add-locations-to-python-path-for-reusable-Django-apps/ で見ました
as_（ul | table | p）（）の代わりにDjangoテンプレートを使用してフォームをレンダリングします 。
この記事では、as_p()、as_table()...の代わりにテンプレートを使用してCusstomFormsをレンダリングする方法を示します。
動作を変更するには
from Django import newforms as formstofrom Django import formsfrom Django.newforms.forms import BoundFieldtofrom Django.forms.forms import BoundField
実稼働環境で「DEBUG」属性を自動的に設定（settings.py）
import socket
if socket.gethostname() == 'productionserver.com':
DEBUG = False
else:
DEBUG = True
djangorecipeを使用してプロジェクトを管理します
- 新しいアプリを作成している場合、このレシピを使用すると、プロジェクト外で簡単にテストできます
- プロジェクトの依存関係を管理できます（例：依存するアプリのバージョン）
始めるために必要なことはこれだけです：
- 新しいWebサイト（またはライブラリ）のフォルダーを作成します
次のコンテンツを含むbuildout.cfgを作成します。
[buildout] parts=Django [Django] recipe=djangorecipe version=1.1.1 project=my_new_site settings=development- Bootstrap.pyを入手してbuildoutのローカルインストールを取得し、ディレクトリ内に配置します。 公式のもの （申し訳ありませんが、Markdownは完全なリンクの一部が好きではありませんでした：-/）、または Reinout vanリース 。
python bootstrap.py（または、distributeを使用する場合はpython bootstrap_dev.py）。./bin/buildout
それでおしまい。これで、新しいDjango 1.1.1プロジェクトである新しいフォルダー「my_new_site」が作成されます。/binには、manage.pyを置き換えるDjango- scriptがあります。通常のインストール。
利点は何ですか？プロジェクトでDjango-comment-spamfighterのようなものを使いたいとしましょう。必要なことは、buildout.cfgを次のように変更することだけです。
[buildout]
parts=Django
[Django]
recipe=djangorecipe
version=1.1.1
project=my_new_site
settings=development
eggs=
Django-comments-spamfighter==0.4
Djangoパートにはバージョン0.4のDjango-comments-spamfighterパッケージも必要であるという最後の2行を追加するだけでした。次回./bin/buildoutを実行すると、buildoutはそのパッケージをダウンロードし、。/ bin/Djangoを変更してPYTHONPATHに追加します。
djangorecipeは、mod_wsgiを使用してプロジェクトをデプロイするのにも適しています。 buildout.cfgのDjango部分にwsgi=true設定を追加するだけで、。/ binフォルダーに「Django.wsgi」が表示されます:-)
testオプションをアプリケーションのリストに設定すると、djangorecipeはプロジェクト内のリストされたアプリケーションのすべてのテストを実行するNice wrapperを作成します。
デバッグなどのためにスタンドアロン環境で単一のアプリを開発したい場合、Jakob Kaplan-Mossには his blog の完全なチュートリアルがあります。
Urlconfでreverseを使用します。
これは、なぜデフォルトではないのかわからないトリックの1つです。
ここに私がそれを選んだ場所へのリンクがあります： http://andr.in/2009/11/21/calling-reverse-in-Django/
コードスニペットは次のとおりです。
from Django.conf.urls.defaults import * from Django.core.urlresolvers import reverse from Django.utils.functional import lazy from Django.http import HttpResponse reverse_lazy = lazy(reverse, str) urlpatterns = patterns('', url(r'^comehere/', lambda request: HttpResponse('Welcome!'), name='comehere'), url(r'^$', 'Django.views.generic.simple.redirect_to', {'url': reverse_lazy('comehere')}, name='root') )
これは、pythonシェルで別のモデルを再度インポートする必要がない、本当に簡単な方法です。
まず、 IPython をインストールします（IPythonを使用しない場合、何が問題になっていますか？）。次に、pythonプロジェクトディレクトリに次のコードを含むDjangoスクリプトipythonrc.pyを作成します。
from Django.db.models.loading import get_models
for m in get_models():
globals()[m.__name__] = m
#NOTE: if you have two models with the same name you'll only end up with one of them
次に、〜/ .ipython/ipythonrcファイルで、「ロードして実行するPythonファイル」セクションに次のコードを追加します。
execfile /path/to/project/ipythonrc.py
これで、IPythonを起動するたび、または./manage.py Shellを実行するたびに、すべてのモデルが既にインポートされ、使用できる状態になります。別のモデルを再度インポートする必要はありません。
Ipythonrc.pyファイルに他の多くのコードを実行して、時間を節約することもできます。
initのDjangoフォームフィールドプロパティの変更
Formクラスに追加の引数を渡すと便利な場合があります。
from Django import forms
from mymodels import Group
class MyForm(forms.Form):
group=forms.ModelChoiceField(queryset=None)
email=forms.EmailField()
some_choices=forms.ChoiceField()
def __init__(self,my_var,*args,**kwrds):
super(MyForm,self).__init__(*args,**kwrds)
self.fields['group'].queryset=Group.objects.filter(...)
self.fields['email'].widget.attrs['size']='50'
self.fields['some_choices']=[[x,x] for x in list_of_stuff]
ソース： Dzoneスニペット
Django_extensions from https://github.com/Django-extensions/Django-extensions は素晴らしいです。
いくつかの素敵な./manage.pyコマンド：
Shell_plus-すべてのINSTALLED_APPSからモデルを自動インポートしますshow_urls-プロジェクトのすべてのアプリで定義されているすべてのURLを出力しますrunscript-プロジェクトコンテキストでスクリプトを実行します（モデルおよびその他のDjango関連モジュールを使用できます）
非同期タスクを使用します。 Celery を使用します
nbreaking Django をまだ読んでいない場合は読んでください。 Django落とし穴に関する有用な情報のlotsが含まれています。
同じ構造を持つレガシーテーブルのセットの動的モデルを作成します。
class BaseStructure(models.Model):
name = models.CharField(max_length=100)
address = models.CharField(max_length=100)
class Meta:
abstract=True
class DynamicTable(models.Model):
table_name = models.CharField(max_length=20)
def get_model(self):
class Meta:
managed=False
table_name=self.table_name
attrs = {}
attrs['Meta'] = Meta
# type(new_class_name, (base,classes), {extra: attributes})
dynamic_class = type(self.table_name, (BaseStructure,), attrs)
return dynamic_class
customers = DynamicTable.objects.get(table_name='Customers').get_model()
me = customers.objects.get(name='Josh Smeaton')
me.address = 'Over the Rainbow'
me.save()
これは、同じ構造のレガシーテーブルがあることを前提としています。各テーブルをラップするモデルを作成する代わりに、1つのベースモデルを定義し、特定のテーブルと対話するために必要なクラスを動的に構築します。
isapi-wsgi および Django-pyodbc を使用して、DjangoおよびSQL Serverを使用してWindowsでIISを実行します。
パーティーに少し遅れました。しかし、最近Django Canvasが登場し、ここにふさわしい場所になりました。
Django-admin.py startprojectでプロジェクトを開始しないでください。代わりに Django Canvas のようなものを使用して、空のプロジェクトを必要なモジュールにまとめることができます。
そのサイトにアクセスし、いくつかのオプションにチェックを入れて、空のプロジェクトをダウンロードします。とても簡単です。
ここには、Southスキーマの移行やコマンド拡張などの一般的なものだけでなく、他の多くのベストプラクティスも含まれています。さらに、Python、virtualenv、pip、Django、およびWindows、osx、またはlinuxの新しいコピーから起動するために必要なものをインストールする優れたstart.sh/shart.batスクリプトがあります。
Djangoにはアプリの設定がないため、独自のapp_settings.pyを検出しました。 settings.pyの下部にこのコードを追加しました：
import sys, os
# Append application settings without triggering the __init__.
for installed_app in INSTALLED_APPS:
# Ignore Django applications
if not installed_app.startswith('Django.'):
# Find the app (and the settings file)
for path in sys.path:
path = os.path.join(path, installed_app, 'app_settings.py')
if os.path.isfile(path):
# Application settings found
exec open(path).read()
すべてのINSTALLED_APPSでapp_settings.pyを検出します。インポートする代わりに、app_settingsファイルの内容を読み取り、インラインで実行します。 app_settingsを直接インポートすると、すべての種類のDjangoインポートエラーが発生します（Djangoはまだ初期化されていないため）。
したがって、私のapp/app_settings.pyは次のようになります。
MIDDLEWARE_CLASSES += (
'app.middleware.FancyMiddleware',
)
これで、すべてのアプリケーション設定を見つけてそれらをsettings.py（ミドルウェア、URL ...）に追加する代わりに、アプリケーションをINSTALLED_APPSに追加するだけで済みます。
注：Djangoに追加の設定を追加するフックがあれば、起動時（または実行時）にアプリケーション設定を追加できます。
ビューからテンプレートに変数を渡すと、応答辞書を入力するのが面倒になります。 locals()を使用してすべてのローカル変数を一度に渡すだけでいいと思います。
def show_thing(request, thing_id):
thing = Thing.objects.get(pk=thing_id)
return render_to_response('templates/things/show.html', locals())
（それ自体は隠された機能ではありませんが、PythonやDjangoを初めて使用するときに役立ちます。）
編集：明らかに、暗黙的よりも明示的である方が良いのですが、このアプローチは開発中に役立ちます。
dir（）＆ValueError（）を上げる
開発中に物事の状態をデバッグ/調査するには、次のトリックを使用します。
...
to_see = dir(inspect_this_thing)
to_see2 = inspect_this_thing.some_attribute
raise ValueError("Debugging")
...
これは、特によく文書化されていないDjangoの部分で作業しているときに特に役立ちます（form.changed_fieldsは最近使用したものです）。
locals（）。
テンプレートコンテキストのすべての変数を書き出す代わりに、python builtin locals（）コマンドを使用して、辞書を作成します。
#This is tedious and not very DRY
return render_to_response('template.html', {"var1": var1, "var2":var2}, context_instance=RequestContext(request))
#95% of the time this works perfectly
return render_to_response('template.html', locals(), context_instance=RequestContext(request))
#The other 4.99%
render_dict = locals()
render_dict['also_needs'] = "this value"
return render_to_response('template.html', render_dict, context_instance=RequestContext(request))