14/02/27 01:08:04.43
単純なデータ取得、たとえば pkを指定してレコード取得や一覧取得はView
ビジネスロジックと言われるような中枢を成す処理はmodelまたはlogics.pyとか別ファイルにする
Djangoのポリシーではテンプレート内でデータは加工しない
テンプレートはデザイナーが触るものでプログラマーが触るものではない
よってデータの加工はviewでやる
getメソッド?なにそれ
294:nobodyさん
14/02/27 05:14:32.62
>>291
俺ならインタフェースだけ合わせて、template内で同じように見えるようにしてiteration。
295:nobodyさん
14/02/27 06:00:14.57
<select><option value="foo">bar</option></select>
のような形を作るにはどのようにすればいいのでしょうか？
class yes(forms.Form):
bar = forms.ChoiceField(
widget = forms.Select()
)
で、セレクトバーは出たんですが、その後の<option>の指定方法がわかりません
自分はHTMLで{{form.bar}}のようにしています
296:nobodyさん
14/02/27 06:01:32.60
すみません、barじゃなくfooでした
297:nobodyさん
14/02/27 10:04:22.81
>>296
choices
298:nobodyさん
14/02/27 17:19:30.62
フォームでPOST値を送信する場合って、
PHPの場合は、送った先が$_POST['foo']とかを処理するけど、
Djangoの場合は、処理するページ(<form>のあるページ)がPOST値を処理してから次のページへリダイレクトって仕組みだよね?
送った先(次のページ)がPOST値を取得したり表示する場合はセッションを使わないといけないんだよね？
299:nobodyさん
14/02/27 20:08:10.07
>>298
そんなことない。作り方次第。
ただ自然に作ると、
300:nobodyさん
14/02/27 20:09:28.52
>>299 続き
そうなる。
301:nobodyさん
14/03/01 00:04:24.54
>>292
getはクラスベース汎用ビューにあるgetのオーバーライドです
ネットの参考サイトがそのような書き方をしていましたので
requestからURLパラメータ欲しいから・・・と思いましたがView.requestでどこからでも取得出来るんですね
となるとコンテキストに追加するのはget_context_dataがいいのかな
あとテーブル操作はカスタムManager、レコード操作はModelと意識してます
>>294
フォームで言う、form.messageみたいなのを作るって事でしょうか？
ネットでもいろんなやり方があって、もう設計に拘らず適当でもいい気がしてきました・・・ｗ
しかし関数ベースとクラスベースの情報があってぐぐり難いですね
302:nobodyさん
14/03/01 02:11:13.60
>>301
>>294だが違う。
モデルで吸収するってこと。
303:nobodyさん
14/03/02 09:36:50.36
>>1
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
ｽﾚﾘﾝｸ(tech板:85番)
304:nobodyさん
14/04/08 07:57:45.66 Gp3QMMMl
request.session['hoge'] = 0
sqlite使用で上のコードを書いただけで 200msくらいブラウザの反応が遅くなるから、
なんとなくmysqlに変えてみたらなぜか早くなりました(300ms→100ms)
※他にも簡単なSQLありますが、上のコードが無い場合は両者反応速度一緒ぐらいです
しかしdebug_toolbarで見るSQLの実行時間は常に変わらず0or1ms
あとtime.clockでもコードの実行時間見てるけど、なんか変です
上のコードがあるメソッドを、clockで囲ってコード有無・DB変更して計測しても、常に30ms未満
なぜでしょうか・・・orz
django1.6.2 python2.7 windows7
305:nobodyさん
14/04/08 19:30:15.43
計測何回やったんだ
sqliteはファイルだからIOがとかなんとか
mysqlもファイルですよ
306:nobodyさん
14/04/08 23:51:56.94
>>305
ついでにtimeitとやらで計測してみました
t = timeit.Timer("""s = SessionStore('key')
s.save()""", 'from django.contrib.sessions.backends.db import SessionStore')
logging.debug(t.timeit(10))
[ sqlite3.8.3.1 ] 約2800ms VACUUMすると遅くなって3800ms・・・
QUERY = u'SELECT "django_session"."session_key", "django_session"."session_data", "django_session"."expire_date"
FROM "django_session" WHERE ("django_session"."session_key" = %s AND "django_session"."expire_date" > %s )' -
PARAMS = (u"'z9q43506rahjmcheld9e0m9p4motsbwa'", u"'2014-04-08 13:53:36.183000'")
QUERY = u'BEGIN' - PARAMS = ()
QUERY = u'UPDATE "django_session" SET "session_data" = %s, "expire_date" = %s
WHERE "django_session"."session_key" = %s ' - PARAMS = (u"'NDFkMjdiMjI5NWUzYjliZWIzNGQwMGI1YzA1ZDcwMWQ5MjNmZWVlNDp7fQ=='",
u"'2014-04-22 13:53:36.190000'", u"'z9q43506rahjmcheld9e0m9p4motsbwa'")
UPDATEはdebug_toolbar上では1or2ms。トランザクションの関係で計測上手く出来ないのかも？
UPDATEをSQLiteManagerから直接実行しても300msかかってました
[ mysql5.6.17 ] 約140ms
SELECT ??? FROM `django_session` WHERE (`django_session`.`session_key` = 'z9q43506rahjmcheld9e0m9p4motsbwa'
AND `django_session`.`expire_date` > '2014-04-08 13:59:03' )
UPDATE `django_session` SET `session_data` = 'NDFkMjdiMjI5NWUzYjliZWIzNGQwMGI1YzA1ZDcwMWQ5MjNmZWVlNDp7fQ==',
`expire_date` = '2014-04-22 13:59:03' WHERE `django_session`.`session_key` = 'z9q43506rahjmcheld9e0m9p4motsbwa'
しかしsqliteのアダプタって無駄が多いんですね
さすがに差が開きすぎな気もするので、単に私の環境のsqliteがおかしいのかも・・・
307:306
14/04/09 06:33:27.18
すみません、どうやら単純にデータがSSDにあるかどうかの問題でした…
sqliteファイルをSSDへ移したところ、2800ms→230msまで縮まりました
しかしHDDとSSDでここまで違うとは…
308:nobodyさん
14/05/22 16:31:45.79
馬鹿には無理
309:nobodyさん
14/05/24 02:57:47.14
nginxで使う場合uwsgiとgunicornでは、どちらがオススメでしょうか？
310:nobodyさん
14/05/24 03:17:53.06
そんな質問してるようじゃおまえにはまだはやい
311:nobodyさん
14/05/24 12:31:13.12
uWSGIの方が色々出来て便利だけどドキュメント読めないと詰むかもわからん。
Emperor + Zerg で Graceful reload とか。
312:nobodyさん
14/05/24 13:50:56.96
バカげた質問である
313:nobodyさん
14/05/24 14:09:01.28
Djangoに入ってるsimplejsonってUNICODEを期待してるの？