イキナリ関係無い話ですが、フォームセットの事を最初は「複数種類の」フォームをまとめて扱えるものと思い込んでいました。 本当は「1種類のフォームを複数」まとめて扱えるものです。 これでちょっと時間を無駄にしました。みなさんもお気をつけ下さい。（そんな勘違いする人はいないかw） さて本題です。 フォームセットは例えば以下のように生成できます。 from django import forms from django.forms.formsets import formset_factory class TestForm(forms.Form): title = forms.CharField(label = u'タイトル') TestFormSet = formset_factory(TestForm) TestFormSetはクラスなので、ビューのコードとかでTestFormSet()とやる
今日の Web 開発者にとって、自動化されたテストはバグ潰しの工程で極めて有用な ツールです。複数のテストを集めた テストスイート を使えば、Web開発におけ るいくつもの問題を解決したり回避したりできます: 新たなコードを書く際、コードが期待通りに動作するかテストできます。 以前のコードを修正したりリファクタする場合、テストによって、コードの変 更がアプリケーションに意図しない影響を及ぼさないか調べられます。 Web アプリケーションは、 HTTP レベルのリクエスト処理、フォームの検証と処理、 そしてテンプレートレンダリングまで、複数のロジックレイヤから構成されていま す。そのため、Webアプリケーションのテストは複雑なタスクです。 Django のテス ト実行フレームワークと関連ユーティリティを使えば、仮想的なリクエストを発行 したり、テストデータを挿入したり、アプリケーションの出力
Web アプリケーションの作成は、同じパターンを何度も何度も繰り返し書くことに なるため、退屈なものです。 Django では、そんなパターンに共通する部分のほと んどを「汎用ビュー (generic view) 」という形で抽象化し、オブジェクトに対し てよく定義されるビューを、 Python コードを一切書かずに作成できるようにして います。 Django の汎用ビューには以下のようなものがあります: list/detail インタフェースを実現するビューのセット。 アーカイブに入っているページ群に対する年/月/日のビューと、各ページの 詳細、そして「新着 (latest)」のページ (例えば Django weblog の year, month, day, detail, latest といったページ)。 オブジェクトの生成、編集、削除を行うためのビュー。 これらのビューは全て、U
適当にアプリを作っていると modelの変更が頻繁に出てきます。 駄目人間の証ですね＞＜ でも、そんな駄目人間にも優しいDjangoです。 後からカラム追加したり、ユニークにしたかったりインデックス貼りたかったりして models.pyを変更した後、絶望にくれてませんか？ 更にその後、 >python manage.py reset appNameとか打っちゃってadminにすらログインできなくなって 泣きそうになっていませんか？ 俺は両方経験しました。 おっぱいマニア*1を目指す人間として軸がぶれている気がします＞＜ さて、そんな時ですが、実は便利なコマンドがあります。 >python manage.py sqlreset appName | mysql -D dbName -u user -p もちろん大事なデータが入っているときにはやってはいけませんが 作成途中の時はこんな感じでガン
ページ番号などの情報を URL に持たせる時の話。 Django 的には /something/?page=7 のようにクエリ要素を使うのと /something/7/ のような URL はどちらが便利なのか考えてみた。 今の時点での結論は「URL ディスパッチャが強力なので /something/7/ でよい」かな。 Django 使いはじめたばかりなのですぐに意見が変わる可能性は大。 /somethig/7/ だけでなく /something7/, /something/page7/, /something/page/7/ など、正規表現しだいでいろいろやりようがあるのもメリット。 以下比較。 URL ディスパッチャの記述 ここだけはクエリ要素使用のほうが楽。 クエリ要素に情報を持たせる場合 URL ディスパッチャはクエリを無視するのでやることがない。以下の記述で /something
モデルとは、サイトを構成するデータの、ただ一つかつ最終的なデータソースを指 します。モデルには、保存したいデータに不可欠なデータフィールドと、その振舞 いが収められています。一般的に、各モデルは単一のデータベーステーブルに対応 づけられています。 基本として、まず以下のことを知っておきましょう: 各モデルは Python のクラスで、 django.db.models.Model のサブ クラスです。 モデルの各属性値は、データベース上のあるフィールドを表現します。 これらの情報をもとに、 Django はデータベース API を自動生成します。 API の詳細は クエリを生成する で解説します。 See also このドキュメントを理解する上で、 モデル例の公式リポジトリ が参考になるでしょう。 (Django のソース配布物中では、これらの例は tests/modeltests ディレ
null¶ Field.null¶ True にすると、 Django は空の値を NULL としてデータベースに入れます。 デフォルト値は False です。 空の文字列値は NULL ではなく空文字列として保存されることに注意して下さ い。 null=True が使えるのは、整数型やブール型、日付のような、文字列では ないフィールド型の場合だけです。 null はデータベースでの記録 操作にのみかかわるパラメタなので、フォーム上で空の値を入力できるようにした ければ blank=True も指定する必要があるでしょう (blank も 参照してください)。 特別な理由のない限り、 CharField や TextField のような、 文字列ベースのフィールドには null を指定しないでください。 文字列ベースのフィールドが nill=True であるということは、「データがない」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く