一連の質問「... の隠された機能」に触発されて、お気に入りの Django のヒントや、あまり知られていないが便利な機能について知りたいと思っています。
- 回答ごとに 1 つのヒントのみを含めてください。
- Django のバージョン要件がある場合は追加します。
一連の質問「... の隠された機能」に触発されて、お気に入りの 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
の代わりにdjango-annoying の render_to
デコレータを使用してくださいrender_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 をハードコーディングしないでください。
代わりにURL 名を使用し、reverse
関数を使用して URL 自体を取得します。
URL マッピングを定義するときは、URL に名前を付けます。
urlpatterns += ('project.application.views'
url( r'^something/$', 'view_function', name="url-name" ),
....
)
名前が URL ごとに一意であることを確認してください。
私は通常、一貫した形式の「プロジェクト アプリケーション ビュー」を使用しています。たとえば、スレッド ビューには「cbx-forum-thread」などがあります。
更新(恥知らずに ayaz の追加を盗む):
url
この名前は、タグ付きのテンプレートで使用できます。
django デバッグ ツールバーを使用します。たとえば、ビューのレンダリング中に実行されたすべての SQL クエリを表示でき、それらのスタック トレースを表示することもできます。
別のユーザー モデルがあり、それをすべての応答に含めたいとします。これを行う代わりに:
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
キーが自動的に含まれるようになりました。
これについて数か月前にブログ記事を書いたので、カット アンド ペーストします。
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()()
次に、ページを更新し、runserver ウィンドウに移動すると、インタラクティブな IPython ウィンドウが表示されます。
TextMate にスニペットを設定しているので、ipshell と入力してタブを押すだけです。私はそれなしでは生きられませんでした。
送信されたものを出力するだけの開発 SMTP サーバーを実行します (開発サーバーに SMTP を実際にインストールしたくない場合)。
コマンドライン:
python -m smtpd -n -c DebuggingServer localhost:1025
Bash シェルを使用する場合はextras/django_bash_completion
、Django ディストリビューションに含まれている Django bash 補完スクリプトのインストールを検討してください。django-admin.py
およびコマンドのタブ補完が有効になるmanage.py
ため、たとえば...
django-admin.py
ます。sql
してから [TAB] を入力すると、名前が で始まるすべての使用可能なオプションが表示されますsql
。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
Djangoと一緒にJinja2を使用します。
Djangoテンプレート言語が非常に制限されていることに気付いた場合(私のように!)、それに固執する必要はありません。Djangoは柔軟性があり、テンプレート言語はシステムの他の部分と緩く結合されているため、別のテンプレート言語をプラグインして、それを使用してhttp応答をレンダリングするだけです。
私はJinja2を使用しています。これは、djangoテンプレート言語のパワーアップバージョンのようなもので、同じ構文を使用し、ifステートメントで式を使用できます。if_item_in_list
!などのカスタムifタグを作成する必要はもうありません。%{ if item in list %}
、、またはと簡単に言うことができます{% if object.field < 10 %}
。
しかし、それだけではありません。テンプレートの作成を容易にする多くの機能がありますが、ここではそれらすべてを説明することはできません。
ビュー コードを追加assert False
して、デバッグ情報をダンプします。
これにより、 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 を返す callable である必要があるだけなので、Ruby on 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 ではサポートされているのに対し、テンプレート ブロック名で「-」文字がサポートされていないことに注意してください。これにより、多くの問題が発生し、生成された非常にあいまいなエラーメッセージを追跡しようとして時間を無駄にしました.
「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/ で入手できます。
もちろん、本番環境では使用しないでください。
ウェブデザインアプリは、ウェブサイトのデザインを開始するときに非常に便利です。インポートしたら、これを追加してサンプル テキストを生成できます。
{% load webdesign %}
{% lorem 5 p %}
django.db.models.get_model
モデルをインポートせずに取得できます。
James は、 「Django のヒント: より良いテンプレート タグを書く — 反復 4」で、それがいかに便利であるかを示しています。
これは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 つです)。 それをラップすると、必要なロジックが可能になります。この宝石のおかげで、「検索結果」ページでオフバイワン エラーをデバッグする時間を何時間も節約でき、その過程でビュー コードがよりきれいになりました。
xml_modelsを使用して、(SQL の代わりに) XML REST API バックエンドを使用する Django モデルを作成します。これは、特にサード パーティの API をモデル化する場合に非常に便利です。使い慣れた QuerySet 構文をすべて取得できます。PyPI からインストールできます。
API からの XML:
<profile id=4>
<email>joe@example.com</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 'joe@example.com'
リレーションシップとコレクションも処理できます。使用頻度の高い本番コードで毎日使用しているため、ベータ版とはいえ非常に使いやすいです。また、テストで使用できる優れたスタブのセットもあります。
(免責事項: 私はこのライブラリの作成者ではありませんが、いくつかのマイナーなコミットを行った後、現在はコミッターです)
データベースの移行を使用します。南を使用します。
このリンクを見つけました: http://lincolnloop.com/django-best-practices/#table-of-contents - "Django Best Practices"。
クエリセット全体を評価して結果が返されるかどうかを確認する代わりに、Django 1.2以降では.exists()を使用し、以前のバージョンでは.count()を使用します。
presents()とcount()はどちらも、order by句をクリアし、DBから単一の整数を取得します。ただし、exists()は常に1を返しますが、countは、制限が手動で適用されるより高い値を返す場合があります。好奇心旺盛な人のために、exists()で使用されるhas_resultとcount()で使用されるget_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
私の Django サイトで行ったことの 1 つは、.xmlsettings.py
ファイルからデータベース アクセス情報をロードすることです/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
、データベース管理者と Django 自体以外のユーザーがファイルにアクセスできないようにする必要があります。デフォルトのケースでは、Django は開発者自身のテスト データベースを参照する必要があります。ast
の代わりにモジュールを使用するより良い解決策もあるかもしれexecfile
ませんが、まだ調査していません。
私が行うもう 1 つのことは、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 インジェクション攻撃が引き起こす可能性のある損害を制限できます (ただし、すべてのユーザー入力をチェックしてフィルタリングする必要があります)。
(別の質問への私の回答からコピー)
シグナルを使用して、オンザフライでアクセサ メソッドを追加します。
私はdjango-photologueでこのテクニックを見ました: 追加された任意の Size オブジェクトに対して、post_init シグナルは対応するメソッドを Image モデルに追加します。サイトの巨人を追加した場合、巨大な解像度で画像を取得する方法は次のようになります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のソース コードを参照してください。
Django dev サーバーを localhost で実行する代わりに、適切なネットワーク インターフェイスで実行します。例えば:
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 上の他のマシンから開発サイトにアクセスしてテストします。
ただし、開発サーバーは最小限で比較的安全ですが、ファイアウォールで保護されていることを確認してください。
Django Debug Toolbarは本当に素晴らしいです。実際にはツールバーではありませんが、実際にはサイドペインが表示され、DB クエリ、テンプレートに送信されたコンテキスト変数、シグナルなど、見ているページが表示された理由に関するあらゆる種類の情報が表示されます。
wraps
カスタム ビュー デコレータでデコレータを使用して、ビューの名前、モジュール、およびドキュメント文字列を保持します。例えば
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 を上書きしたり、次のようにすべてのインポートにアプリを追加したりする必要はありません。
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/で見ました
djangorecipeを使用してプロジェクトを管理します
始めるためにあなたがしなければならないすべてはこれです:
次のコンテンツを含むbuildout.cfgを作成します。
[buildout]
parts=django
[django]
recipe=djangorecipe
version=1.1.1
project=my_new_site
settings=development
python bootstrap.py
(またはpython bootstrap_dev.py
、配布を使用する場合)。./bin/buildout
それでおしまい。これで、新しいdjango1.1.1プロジェクトである新しいフォルダー「my_new_site」が作成されます。./binにはdjango
、通常のインストールでmanage.pyを置き換える-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
最後の2行を追加するだけで、バージョン0.4ではdjango-partにもdjango-comments-spamfighterパッケージが含まれている必要があることに注意してください。次回実行する./bin/buildout
と、buildoutはそのパッケージをダウンロードし、。/ bin/djangoを変更してPYTHONPATHに追加します。
djangorecipeは、mod_wsgiを使用してプロジェクトをデプロイするのにも適しています。buildout.cfgのdjango-partに設定を追加するだけwsgi=true
で、「django.wsgi」が./binフォルダーに表示されます:-)
また、test
オプションをアプリケーションのリストに設定すると、djangorecipeは、プロジェクト内のリストされたアプリケーションのすべてのテストを実行する優れたラッパーを作成します。
デバッグなどのためにスタンドアロン環境で単一のアプリを開発したい場合は、JakobKaplan-Mossのブログに非常に完全なチュートリアルがあります。
as_(ul|table|p)() の代わりに django テンプレートを介してフォームをレンダリングします。
as_p()
この記事では、テンプレートを使用して、代わりに CusstomForms をレンダリングする方法を示しますas_table()
...
変更を機能させるには
from django import newforms as forms
に from django import forms
from django.newforms.forms import BoundField
に from django.forms.forms import BoundField
本番環境で「DEBUG」属性を自動的に設定 (settings.py)
import socket
if socket.gethostname() == 'productionserver.com':
DEBUG = False
else:
DEBUG = True
urlconf で逆を使用します。
これは、なぜデフォルトでないのか理解できないトリックの 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') )
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スニペット
これは、Python シェルで別のモデルを再度インポートする必要がないための非常に簡単な方法です。
まず、IPythonをインストールします (IPython を使用しない場合、何が問題なのですか?)。次に、次のコードを含む Python スクリプト ipythonrc.py を django プロジェクト ディレクトリに作成します。
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 ファイルに入れることもできます。
isapi -wsgiとdjango-pyodbcを使用して、IISとSQLServerを使用してWindowsでDjangoを実行します。
まだ読んでいない場合は、Unbreaking Djangoを読んでください。django の落とし穴に関する有益な情報がたくさん含まれています。
パーティーには少し遅れました。しかし、最近 Django Canvas が出てきたので、ここに置く価値があります。
でプロジェクトを開始しないでくださいdjango-admin.py startproject
。代わりに、Django Canvasなどを使用して、空白のプロジェクトと必要なモジュールを組み合わせることができます。
そのサイトにアクセスし、いくつかのオプションにチェックマークを付けてから、空のプロジェクトをダウンロードします。とても簡単です。
ここには、South スキーマの移行やコマンド拡張機能などの一般的なものがすべて含まれているほか、ここで言及されている他の多くのベスト プラクティスも含まれています。start.sh/shart.bat
さらに、python、virtualenv、pip、django、および windows、osx、または linux の新しいコピーから開始するために必要なものをインストールする優れたスクリプトがあります。
同じ構造を持つ一連のレガシー テーブルの動的モデルを作成します。
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 つの基本モデルを定義し、特定のテーブルと対話するために必要なクラスを動的に構築します。
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 に追加の設定を追加するためのフックがあれば、アプリケーションの設定を起動時 (または実行時) に追加できるとよいでしょう。
dir() & レイズ ValueError()
開発中の状態をデバッグ/調査するために、次のトリックを使用します。
...
to_see = dir(inspect_this_thing)
to_see2 = inspect_this_thing.some_attribute
raise ValueError("Debugging")
...
これは、特に十分に文書化されていない django の部分で作業している場合に特に役立ちます (form.changed_fields は、私が最近これを使用したものです)。
ローカル()。
テンプレート コンテキストのすべての変数を書き出す代わりに、辞書を作成する 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))
ビューからテンプレートに変数を渡すとき、応答ディクショナリを入力するのが面倒になることがあります。を使用してすべてのローカル変数を一度に渡すだけでいいと思います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 を初めて使用する場合に役立ちます。)
編集:明らかに、明示的である方が暗黙的であるよりも優れていますが、このアプローチは開発中に役立ちます。