Djangoのヒントとコツ

ご挨拶！



この投稿では-Djangoでの作業に関する小さなヒントが初心者デベロッパーに役立つかもしれません。 Djangoをマスターする旅の最初にこれを知りたいので！..

これらのヒントはある程度の批判を伴うべきだと考えてください。 あなたが不正確/最良の解決策を見つけた場合、またはドキュメントにないdjangoの独自の「チップ」を提案した場合、私は喜んでいます。



それでは、遠くから始めて、詳細に移りましょう。

仮想環境

djangoアプリケーションにvirtualenvを使用していない場合は、 ぜひ試してみてください。



すでにvirtualenvを使用している場合は、-no-site-packagesが必要かどうか答えてください。 このフラグはデフォルトで有効になっており、仮想環境を作成するときに使用されます。 「内部」プログラムのフラグがオンの場合、環境はプログラムを「外部」に表示しません。 パッケージマネージャーをグローバルにパッケージ化する場合、たとえばpython2-djangoの場合、環境の「内部」にpip install djangoをインストールする必要があります。



virtualenvからのグローバルプログラムの可視性/非可視性は、ファイル[virtualenv] / lib / python *。* / No-global-site-packages.txtの不在/存在によって設定されます。 とても簡単です。



ちなみに、virtualenvの「分離」に関する記事をみんなにお勧めします。virtualenvとpipが嫌いな理由 （サイトが遅くなり、 web.archive.orgからしか開けませんでした）。 それは、実際にvirtualenvが「外部」環境からどのように隔離されているかを調べます-つまり、部分的な隔離にすぎません。

ipython

Pip install ipythonは、標準のPythonシェルを、カラーリング、オートコンプリート、イントロスペクション、便利な複数行入力、コピーアンドペーストなどの高度なシェルに置き換えます。 Djangoがインストールされている場合、ipythonを自動的に選択します。

ところで、これらの利点はすべて./manage.pyシェルだけでなく、デバッグでも使用でき、import i pdbを使用してデバッグできます。 i pdb.set_trace（）。

プロジェクト構造

プロジェクトまたはアプリケーションの作成時にデフォルトでDjangoが必要なディレクトリを作成します。 しかし、あなた自身が考える必要があります。

プロジェクトに名前を付けると、インポートします

プロジェクトプロジェクト（django-admin.py startproject project）に名前を付けます-まあまあですが、すべてのプロジェクトに同じ名前を付けます。 以前は、ドメインに従ってプロジェクトを呼び出しましたが、他のプロジェクトでアプリケーションを再利用する場合、インポートパスを変更する必要がありました-スーパーサイトインポートユーティリティから、ニューサイトインポートユーティリティから。 これは混乱を招き、気が散ります。 このアドバイスを展開する場合は、すべてのプロジェクトのディレクトリ構造を自分で修正（統合）し、厳密にそれに従ってください。



ライブの例：

--site.ru |--static |--media |--project (  ) |--manage.py |--project (   ) | |--settings.py | |--urls.py | |-- ... |--app1 |--app2 |--...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

HTMLテンプレートを保存する場所

テンプレート（.html）をアプリケーションのテンプレートフォルダーにドロップしないでください。 アプリケーションの名前と一致する名前の追加ディレクトリを常に作成します。

これは悪いです、なぜなら たとえば、{％include 'main.html'％}を使用して、テンプレートの衝突を作成します。

 /gallery/templates/main.html /reviews/templates/main.html
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは良いです。{％include 'reviews / main.html'％}を使用できます：

 /gallery/templates/gallery/main.html /reviews/templates/reviews/main.html
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

{％include％}

ちなみに、{％include 'some_template.html'％}を使用する場合、何かが間違っている可能性があります。 なんで？

例：

 def view(request): return render( request, 'master.html', {'var': 'Some text'} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 <!-- master.html --> Value of variable var: {{ var }}. {% include 'slave.html' %} <!-- slave.html --> Again, value of variable var: {{ var }}.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1）KISSは森に乗ります。 一方で、ページコードはいくつかに分割されます-master.htmlとプラグインslave.html。これは大きなhtmlページをパーツに分割するのに便利です。 ただし、この場合、var変数は暗黙的にslave.htmlテンプレートに渡されます。varはmaster.htmlに渡され、slave.htmlはマスターコンテキストを「フック」するだけです。 したがって、{％include％}内のテンプレートはメインテンプレートのコンテキストに依存することがわかります。 親テンプレートのコンテキストを監視する必要があります。そうしないと、子テンプレートで何か問題が発生する可能性があります。

2）私の観察によると、{％include％}はレンダリングの点で高価です。 それを避ける方が良い。



どうする 一部のテンプレートを本当に他のテンプレートに含めたい場合は、包含タグを使用します（それらについては以下をお読みください）。 しかし、それは簡単です-すべてを1つのファイルに書き込むだけです：

 <!-- master.html --> Value of variable var: {{ var }}. Again, value of variable var: {{ var }}.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

settings.py

テストサーバーと展開サーバーに2つの異なるsettings.pyがありませんか？

追加のlocal_settings.pyおよびdeployment_settings.pyを作成し、対応するサーバーにのみ適用されるすべてをドロップします。





settings.pyでは、冒頭に次のように記述しています。

 # Load local settings if available try: from local_settings import * except ImportError: from deployment_settings import *
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、デプロイ時にlocal_settings.pyを削除します。 干渉しないように、.gitignoreに追加できます。

プロジェクトルート

settings.pyでプロジェクトルートを設定します。これにより、後で作業が楽になります。

 from os import path BASE = path.dirname(path.dirname(path.dirname(path.abspath(__file__)))) MEDIA_ROOT = BASE + '/media/' STATIC_ROOT = BASE + '/static/'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテキストプロセッサ（context_processors.py）、{％include％}および包含タグ

コンテキストプロセッサは、サイトの各ページのコンテキストに変数を追加する必要がある場合にのみ使用してください。結果を使用しない場合でも、コンテキストプロセッサはすべてのページで呼び出されます。 個人的に、私はそれらを使用して電話番号をテンプレートのコンテキストに転送します-この番号は実際にはすべてのページに複数回表示されます。 別の例は、サイトメニューです。 ヘッダーとリンクをコンテキストプロセッサに登録しました。メニューに新しいセクションを追加する必要がある場合は、コンテキストプロセッサに追加するだけで、サイトのどこにでも自動的に追加されます。



1つの間違いがあります-ウィジェットにコンテキストプロセッサを使用する。 たとえば、サイトに常に表示されるニュース列があります。 すべてのページに。 news / context_processors.pyを作成し、newsを含むニュース変数をコンテキストに追加し、テンプレートに{％include 'news / news_widget.html'％}、または{％load news_widget％} {％news_widget news％} ...



これは機能しますが、コンテキストが乱雑になり、さらに、この列があるかどうかを誰が知っているかわかりません。 包含タグを使用する方法があります。 テンプレート{％news％}に書き込むだけで、このテンプレートタグはすでにニュースを検索し、ニュース列を挿入します。 そして、それはあなたが本当にそれを実行したときにのみ機能します-つまり テンプレートに{％news％}を記述します。

電池

django-debug-toolbar-template-timings

誰もが彼を知っており、おそらく彼を使用しています。 しかし、 django-debug-toolbar-template-timings-テンプレートのレンダリング時間を測定するデバッグツールバープラグインがあります。 また、djangoテンプレートは非常に「高価」である（長い間レンダリングする）ことを考えると、このプラグインは医師がサイトを高速化するために命じたものです。

adv_cache_tag

django-adv-cache-tagを使用すると、テンプレートの非常に柔軟なキャッシュ制御（バージョン管理、圧縮、部分キャッシュ）が可能になります。 ちょうど評価：

 {% load adv_cache %} {% cache 0 object_cache_name object.pk obj.date_last_updated %} <!--   ,     obj.date_last_updated --> {{ obj }} {% nocache %} {{ now }} <!--      --> {% endnocache %} {{ obj.date_last_updated }} {% endcache %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

django-mail-templated

djangoにはメールテンプレートがありません。 django-mail-templated

django-ipware

django-ipwareはユーザーのIPを決定し、改善します。

美しいスープ

htmlパーサーを作成しないでください。 HTMLを自分で解析しないでください。 すべてがすでにそこにあります。

役に立つかもしれないテンプレートタグ

add_class

フォームを作成し、各入力にスタイル、クラス、またはプレースホルダーを設定する場合、djangoは原則に違反することを強制し、すべてのスタイルをforms.pyに直接記述します。

 class SomeForm(ModelForm): class Meta: model = SomeModel fields = ('field1', 'field2') widgets = { 'field1': Textarea(attrs={'rows': '2', 'class': 'field1_class'}), }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.htmlファイルにないhtmlテキストが表示されると、耳障りになります。 これは、MVTアーキテクチャに違反します。 したがって、私は自分用のフィルターを作成しました。

 {% load add_class %} {{ form.field1|add_class:'field1_class' }}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このフィルターはクラスをタグに追加しますが、任意のプロパティを書き換えて追加できます。

is_current_page

特定のページが開いている場合、テンプレートに何かを表示する必要がある場合があります。 たとえば、ユーザーがストアセクションにいる場合は、メニューの[ストア]ボタンを強調表示します。 次のオプションをお勧めします。

 from django import template from django.core.urlresolvers import resolve from project.utils import parse_args register = template.Library() @register.filter def is_current_page(request, param): return resolve(request.path).view_name == param
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはタグではなくフィルターであり、その理由は同じです。{％if％}を使用すると、完全にワイルドな構造を構築できます。 たとえば、現在のページが製品カードであり、ユーザーが承認されている場合：

 {% if request|is_current_page:'shop/product' and user.is_authenticated %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

引数（argsまたはkwargs）を使用して正確なページ（つまり、「製品のページ」だけでなく、「id = 36の製品ページ」）を決定する、より正確な代替実装があります。

 {% if request|is_current_page:'shop/product,id=36' %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 @register.filter def is_current_page(request, param): params = param.split(',') name = params[0] args, kwargs = parse_args(params[1:]) # Do not mix args and kwargs in reverse() - it is forbidden! if args: return request.path == reverse(name, args=args) elif kwargs: return request.path == reverse(name, kwargs=kwargs) else: return request.path == reverse(name)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

モデル

空の

モデルが空の場合があります。 このように：

 class Phrase(models.Model): pass class PhraseRu(models.Model): phrase = models.ForeignKey(Phrase, verbose_name='', related_name='ru') class PhraseEn(models.Model): phrase = models.ForeignKey(Phrase, verbose_name='', related_name='en')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、PhraseはPhraseEnとPhraseRuの間のリンクですが、それ自体には何も含まれていません。 2つのモデルが同等であり、1つの全体に接続する必要がある場合に役立ちます。

ジェネリックリレーションミックスイン

GenericRelationオブジェクトは、オブジェクトが1つしかないことが確実にわかっている場合でも、常にQuerySetによって返されます。

 class Token(models.Model): content_type = models.ForeignKey(ContentType) object_id = models.PositiveIntegerField() content_object = generic.GenericForeignKey() class Registration(models.Model): tokens = generic.GenericRelation(Token)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

トークンにアクセスする必要がある場合、registration.tokens.first（）を記述します。 しかし、トークンが1つしかないことを知っているので、registration.tokenを記述して、大切なトークンをすぐに取得したいだけです。 これはmixinで可能です：

 class Token(models.Model): content_type = models.ForeignKey(ContentType) object_id = models.PositiveIntegerField() content_object = generic.GenericForeignKey() class TokenMixin(object): @property def token(self): content_type = ContentType.objects.get_for_model(self.__class__) try: return Token.objects.get(content_type__pk=content_type.pk, object_id=self.id) except Token.DoesNotExist: return None class Registration(models.Model, TokenMixin): tokens = generic.GenericRelation(Token)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これでregistration.tokenは機能します！

get_absolute_url

{％url 'shop / product' id = product.id％}を記述しないようにしてください。

モデルごとに、get_absolute_url（）メソッドを設定し、{{object.get_absolute_url}}を使用します。 同時に、管理パネルに「サイトを見る」リンクが表示されます。

pre_save

pre_saveでは、保存後にモデルが変更されるかどうかを確認できます。 価格-データベースから古いレコードを取得するためのデータベースへのリクエスト。

 @receiver(pre_save, sender=SomeModel) def process_signal(sender, instance, **kwargs): old_model = get_object_or_None(SomeModel, pk=instance.pk) if not old_model: # Created old_value = None ... else: old_value = old_model.field new_value = instance.field if new_value != old_value: # field changed!
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フォーム

このパターンはすでにハブ上にありましたが、言うまでもありません。

 form = SomeForm(request.POST or None) if form.is_valid(): # ... actions ... return HttpResponseRedirect(...) return render( request, {'form': form} )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それだけです ご清聴ありがとうございました。



UPD。 Habréのいつものように、コメントで行商人は意見を述べ、記事にたくさんの素晴らしいアイデア、追加、コメントを提供しました。 私はそれらを記事に含めませんでしたが、代わりに、記事に関するコメントを読むことを強くお勧めします。