自動化無しに生活無し

related_nameを指定せずに逆参照をする 逆参照を使うことで、1側から多側のデータを取り出すことができる。 『Djangoで1対多のリレーションを構築する【カテゴリ指定、コメントの返信などに】【ForeignKey】』から引用した下記モデル。 class Category(models.Model): name = models.CharField(verbose_name="カテゴリ名",max_length=20) def __str__(self): return self.name class Topic(models.Model): category = mod ...

前に作った、jQueryの年月日検索の作りが甘かったので、JavaScriptで作り直した。 JavaScript window.addEventListener("load" , () => { // 日付入力欄の初期化。 const now = new Date(); const range = 10; const now_year = now.getFullYear(); const now_month = now.getMonth() + 1; const now_day = now.getDate(); const years = document.querySelectorAll("[name='year']"); const months = document.querySelectorAll("[name='month']"); const days = document.querySelectorAll("[name='day']"); const ini = '<option value="">--</option>'; // スプレッド構文を使用して配列に直し、イベントをセットする。 // 年月日 全ての要素にオプションを追加している。 for ( elem of years){ elem.innerHTML = ini; for (let i=now_year-range;i<now_year+range;i++){ if (i===now_year){ elem.innerHTML += `<option value="${i}" selected>${i}年</optio ...

views.pyからurls.pyを作る。 URL引数(パスコンバーター)にも対応させる。 これまでと同様、コードは追記する形式ではあるが、実行は自己責任で。 【Django】models.pyとforms.pyからviews.pyを自動的に作る【コマンド1発で生成】 【Django】models.pyからforms.py及びadmin.pyを自動的に作る【コマンド1発で生成】 注意 Viewを継承したビュー ...

以前の自動生成ツール 【Django】models.pyからforms.py及びadmin.pyを自動的に作る【コマンド1発で生成】 この続き。今回はviews.pyを自動的に作る。 いつも同じようなものをimportして、ビュークラスを作り、DB操作とレンダリングしているだけなので。 内容は以前のコードをviews.py仕様にしただけで、特別なものは使っていない。 ソースコード import glob, re, sys ## 引数の指定がある場 ...

以前のページネーションを実装する方法(他パラメータとの両立)は、実装に手間がかかる。 views.pyでPaginatorのオブジェクトを作り bbs/templatetags/param_change.py を作り ↑をsettings.pyに登録 ↑をテンプレートで呼び出し、カスタムテンプレートタグを実行 たかが、検索とページネーションを両立させるためだけに、3工程も4工程もかかってしまう。 もっとシンプルにできないかと模索し、カスタムテンプレートタグの処理をビューで ...

1つのDjangoプロジェクトに複数のアプリを作り、各アプリのリンクをまとめて表示する。 新しいアプリが追加されるたび、そのリンクをテンプレートにて手動で追記しているようではとても手間だ。整合性も取れなくなるだろう。 だから、全てのアプリのトップページのリンクと、アプリ名をまとめて生成。contextに入れ、レンダリングする。 そういう処理を作る。 前提 このコードを実装する前に、以下前提を守る必要がある。 ...

セキュリティ対策の一環として、ログイン時にメールを送信させる。 すでにsettings.pyにメール送信設定を実装済みとする。 【メール認証】Django-allauthの実装方法とテンプレート編集【ID認証】 appname/signals.py を作る。 関数にデコレータを当てて、ログインの信号を受けたら発動する。 from django.contrib.auth.signals import user_logged_in, user_logged_out from django.dispatch import receiver from django.conf import settings from django.core.mail import EmailMessage @receiver(user_logged_in) def user_logged_in_callback(sender, request, user, **kwargs): # ログインをしたときの処理 #送信元のIPアドレスを手に入れる ip_list = request.META.get('HTTP_X_FORWARDED_FOR') if ip_list: ip = ip_list.split(',')[0] else: ...

前置き 最近のDjango-allauthは大きく仕様が変わりつつある。 settings.pyの編集がこれまでのものとは異なる。 ソーシャル認証ができるという強みから、かなり昔から扱ってきたが、APIの仕様が変化し続けている中であえて実装するのはとても手間だ。 故に、本格的にDjangoのデフォルトの認証機能を扱うことにした。 カスタムユーザーモデル実装とメール認証を前提として。 実装にあたって これまでDj ...

これまで、ユーザーモデルをimportする時 from django.contrib.auth.models import User もしくは、カスタムユーザーモデルの場合 from users.models import CustomUser などとしてきたが、これでは通常のユーザーモデルから、カスタムユーザーモデル導入時にimport文をすべて書き換える必要が出てくる。 アプリが複数であれば、それをすべて書き換えていくのはとても面倒。 そこで、get_user_model を使う。これにより、カスタムユーザーモデルの転換時のコード編集の手間を減 ...

Djangoプロジェクトを何度も何度も作っていてふと思う。 models.pyからforms.py、admin.pyを作る時がすごいめんどくさいと。 どれも似たようなコードになるので、これは自動生成してしまったほうが容易いなと。 故に、本記事ではmodels.pyからforms.py及びadmin.pyを自動生成するPythonコードをまとめる。 ※ファイルを読み込んで追記する仕様上、実行は自己責任でお願 ...