BPStudy#30( http://atnd.org/events/3015 )のまとめ ■MCとテーマ 第1部 渋川よしき氏(twitter:@shibukawa) テーマ:ドキュメント生成ツール「Sphinx」 続きを読む
Django を使う理由がもうひとつ増えました。@whosaysni (Yasushi Masuda) さんが、template2pdf というテンプレートから簡単に PDF を生成する Django アプリケーションを公開されています。主な特徴は以下の通りです。 ReportLab がオープンソースで公開している PDF ライブラリーを利用 同 ReportLab が作成した Report Markup Language (略: rml) (仕様: PDF ) により、PDF ファイルを XML で定義 XML で定義できるので、Django の強力なテンプレートシステムが使える rml -> pdf 変換は Rohit Sankaran 氏が公開している trml2pdf を利用 インストール すべて setuptools でインストール可能です http://pypi.python.
Djangoのモデルに定義されたいろいろな情報を列挙するには、 _meta を使うことでできます。 >>> from django.contrib.auth.models import User >>> for f in User._meta.fields: ... print f ... <django.db.models.fields.AutoField object at 0x01400290> <django.db.models.fields.CharField object at 0x013FBA50> <django.db.models.fields.CharField object at 0x013FBAB0> <django.db.models.fields.CharField object at 0x013FBB10> <django.db.models.fields.E
実践的な DJango テクニック集として、凄くいい記事だったので、勝手に超訳してみました。 http://zeroandone.posterous.com/top-10-tips-to-a-new-django-developer 1. import にプロジェクト名を書かないこと 例えば "project3" というプロジェクトに "xyz" アプリケーションがある場合、次のようにはしないこと。 from project3.xyz.models import Author これではプロジェクトとアプリケーションの結びつきが強すぎて、以下の弊害がおこる。 アプリケーションの再利用がしづらい 将来プロジェクト名を変えたくなっても変更が難しい なので、このようにしよう。 from xyz.models import Author python パス上にある django プロジェクトならば、
織田信長 ぼちぼち、元気にやっています。少し薬にも慣れた...んかなぁ。相変わらず食べられないけど。朝、指がこわばって文字なんて入力できなかったけど、それはほぼなくなった。関節もどこも痛くない。薬効いてきたんやろな。 で、ブログを書こうと言う気がまた起きてきた。 …
アプリケーションを作るさいにユーザ管理が面倒。またユーザにとっても一々サイト毎にユーザ名とパスワードを管理するのも面倒。OpenIDを使うとユーザ認証をgoogleなどの大手に任せられて、作る方も使う方も便利になる。常にスパマーとイタチごっこをして鍛えられているシステムに検証を任せられるってのは大きなメリットだ。django-authopenidを使うと比較的簡単にDjangoのアプリケーションをOpenID化してくれる。 ホームページはこれ。 http://bitbucket.org/benoitc/django-authopenid/ code.googleからbitbucketに移った。 インストール http://bitbucket.org/benoitc/django-authopenid/wiki/Installation 二三方法があるが、これが簡単: sudo apt-ge
mod_wsgiで開発を行うようになって困るのは、標準の状態ではsys.stdoutへの書き込みがmod_wsgiによって制限されるので、printデバッグが使えなくなってしまうことです。より正確にいうと、mod_wsgiのWSGIRestrictStdoutディレクティブをOnにすると、printでstdoutに書き込んだ内容がstderr(Apacheのエラーログ)に出力されるのでprintデバッグもできなくはないのですが、print文を使っていると10年後くらいにPython3.0系に移行する際手間がかかるかもしれない*1ので別の手段を使うのが大人の流儀というものでしょう。*2そんなわけでloggingモジュールを使うわけですが、どこでloggingモジュールの初期設定を行うかという問題が残ります。一番簡単なのは、myproject.logのようなモジュールを用意して、 # mypr
djangoのようなフレームワークは開発者の生産性を劇的に向上させてくれる。しかしそのためにパフォーマンスは犠牲にされる。djangoのORMなんか非常に便利だが、そのまま使っていると非効率なことがRDB層で起きる羽目になる。でもこれは殆んどのアプリケーション開発において賢いトレードオフだと思う。だって、作って公開してみなければそのアプリが最適化するに値するものかどうかは別らないでしょ。 という具合でとりあえず作ってみたサイトがめでたくトラクションを得るとパフォーマンスが問題になってくる。今作っているサイトは日2万ページビューぐらいでピーク時にアップアップ状態。同じページを作るのに毎回SQLからオブジェクトを作ってレンダリングしているんだから無理ない。ホスティングは月20ドルのVPS。趣味のサイトなので、これ以上の予算はない。そこでキャシュの出番だ。 サーバ構成はnginxの後ろにfast
このドキュメントについて このドキュメントでは、 Django のフォーム API の細かい部分を解説していま す。まずは フォーム処理入門 を先に読んでく ださい。 束縛フォームと非束縛フォーム¶ フォームのインスタンスには、何らかのデータの集まりが結び付いた 束縛 (bound) フォーム と、そうでない 非束縛 (unbound) フォーム があ ります。 データと 結び付いている フォームは、データを検証機能する機能と、 フォームを HTML にレンダリングするときにデータを HTML 形式で表示する 機能をあわせ持っています。 データと 結び付いていない フォームには検証機能はありません (検証 すべきデータがないから当然ですね!) が、空のフォームを HTML としてレン ダリングする機能は備えています。 非束縛フォームのインスタンスを生成するには、単にフォームクラスのインスタ
DjangoのJSONデータ生成処理も、jQueryのタグ生成処理もなかなか使いやすい。 jQueryでサーバサイドを呼びだし、サーバサイドでDjangoでModelのリストをJSON化してクライアントに返し、それをselectタグ内のoptionタグとして生成する。 views.py from django.core import serializers from django.http import HttpResponse from testapp.main.models import * ... def models_reload(request): model_list = Model.objects.all() data = serializers.serialize("json", model_list[:30], ensure_ascii=False) return Htt
ModelForm¶ データベース駆動のアプリケーションを構築しているのなら、 Django のモデルに 対応したフォームが必要な場合があるでしょう。例えば、 BlogComment モデル を作っていて、読者がコメントを入力できるようなフォームを作成したいような場 合です。こうしたケースでは、すでにモデルにフィールドを定義しているので、新 たにフォームクラス用にフィールドを定義するのは無駄な作業でしかありません。 この理由から、 Django はモデルからフォームクラスを生成するためのヘルパクラ スを提供しています。 以下に例を示します: >>> from django.forms import ModelForm # フォームクラスを生成 >>> class ArticleForm(ModelForm): ... class Meta: ... model = Article # 記事
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く