Djangoを使ってみたい気がする
Sumiya Sakoda
長文失礼します。
先週末RoRのセミナーに行ってきました。(というよりスタッフですが)
講師の増井さんは今年はRoR以外の仕事はやってないそうです。
ただ、なんでもRoRで実装するのがいいかというと(今までやってきた)PHPが向
いている部分があり、特に既存のものつまりスクラッチから作成しないもので
あればそうだとのことでした。
Rubyはまったくさわったこともありませんが、セミナー内容はかなり興味を惹
きました。Djangoに関しては個人的にチュートリアルを試したりする程度で、
本来の好奇心旺盛の性からか(節操がないともいふ)別にどっちでもいいかなと
も思ってた矢先、仕事でちょっとしたウェブアプリケーションを組むことにな
りました。そこでふと「どうせならDjangoで」と頭をよぎりました。
サイトはおおざっぱにいって以下のような構成になります。
+ トップページ (サイトの紹介、最新リスト表示など)
+-- 商品リスト (発注フォームも含む)
+-- 製造元紹介
+-- ブログ(担当者のコメント、お知らせなど)
時間をかければそれなりに実装できそうですが、まあ来月半ばくらいまでにお
おまかなものを作るといった手前、このままDjangoに突き進もうかとりあえず
Zopeでさくっとやっておこうか葛藤しております。
(社内の案件なので多少の、いやかなりの融通はききます)
悩む理由はDjangoの流儀やAPIがわかっていないということです。
そこで次の質問があります。
・既存のデータベースを流用したいけどDjangoの持つO/Rマッピング機能を活
かせるのかよくわからない。
・管理画面(admin)のインターフェースは強力だけど公開ページで一般ユーザ
に入力してもらう際に同じような仕組みはあるのか。
・コンテンツのツリー構造に対するアプリケーションの位置づけ。
最後に関しては単にアプリケーションはプロジェクト内に並列に存在し、公開
ウェブ上での親子関係というのはただURLConfでマッピングするだけでしょう
か。
もっとよくわかってないこともありますが、なにがわからないかがわからない
状態でもありましてそこはまたこれからということにします。
(おそらく質問の意味もわからないところもあるかと思います。)
- sS
tsuyuki makoto
06/10/28 に Sumiya Sakoda<hige...@buta7.com> さんは書きました:
> 佐古田と申します。こんばんは。
>
> ただ、なんでもRoRで実装するのがいいかというと(今までやってきた)PHPが向
> いている部分があり、特に既存のものつまりスクラッチから作成しないもので
> あればそうだとのことでした。
ほんとかうそか、RailsのDHHは80%をカバーすると言い、DjangoのAdrianは99%を
カバーすると言っています。
> 悩む理由はDjangoの流儀やAPIがわかっていないということです。
> そこで次の質問があります。
> ・既存のデータベースを流用したいけどDjangoの持つO/Rマッピング機能を活
> かせるのかよくわからない。
既存のデータベースを使うこと自体に問題はありません。
Railsと違い、DjangoはModelの記述でデータベースを表しますが、PostgreSQL・
MySQL・SQLiteであれば簡易リバース機能があります。
ただし、以下のような場合には注意が必要です
・ユーザテーブルをDjangoに持たせたくない場合
認証を別のテーブルで行うことは問題ありませんが、Django上ではDjangoの
ユーザModelを利用しないと、管理画面や汎用ビュー等に問題が発生します
・複合PKを利用している場合
Djangoは複合PKに対応していません
・PostgreSQL/MySQL/SQLite以外の場合
Oracleはパッチを当てる必要があり、また、いくつか制約があります
＃業務で既存Oracleの別スキーマを扱ったことがありますので不可能
＃ではありません
> ・管理画面(admin)のインターフェースは強力だけど公開ページで一般ユーザ
> に入力してもらう際に同じような仕組みはあるのか。
コンテンツタイプの一覧(ページング含む)や、追加・更新については
汎用ビューという仕組みでかなりコードの記述量を軽減可能です。
主に、URLConfとテンプレートを記述する作業になります。
もちろん複雑な入力画面等は(ある程度の)作り込みが必要になってきます。
＃汎用ビューから外れるのは「商品リストの発注フォーム」位かな？
> ・コンテンツのツリー構造に対するアプリケーションの位置づけ。
> 最後に関しては単にアプリケーションはプロジェクト内に並列に存在し、公開
> ウェブ上での親子関係というのはただURLConfでマッピングするだけでしょう
> か。
URLConfのマッピングのみです。コンテンツ間の関連とURLには関係があり
ません。
逆に言えば、Zopeのようにどんどん階層を深くしいくような仕組みはありま
せん。
Zopeにすべきか、Djangoにべきかは・・・はて？
Sumiya Sakoda
>>>>> In <6ade7d740610280923v70b...@mail.gmail.com>
>>>>> "tsuyuki makoto" <mtsu...@gmail.com> wrote:
佐古田> 悩む理由はDjangoの流儀やAPIがわかっていないということです。
佐古田> そこで次の質問があります。
佐古田> ・既存のデータベースを流用したいけどDjangoの持つO/Rマッピング機能を活
佐古田> かせるのかよくわからない。
露木> 既存のデータベースを使うこと自体に問題はありません。
露木> Railsと違い、DjangoはModelの記述でデータベースを表しますが、PostgreSQL・
露木> MySQL・SQLiteであれば簡易リバース機能があります。
露木> ただし、以下のような場合には注意が必要です
露木> ・ユーザテーブルをDjangoに持たせたくない場合
露木> 認証を別のテーブルで行うことは問題ありませんが、Django上ではDjangoの
露木> ユーザModelを利用しないと、管理画面や汎用ビュー等に問題が発生します
そうですか。そこまでは考えていませんでしたが、LDAPのユーザ認証を行うよ
うなハッキングを紹介しているサイトがあったのでそのあたりは克服できそう
です。
佐古田> ・管理画面(admin)のインターフェースは強力だけど公開ページで一般ユーザ
佐古田> に入力してもらう際に同じような仕組みはあるのか。
露木> コンテンツタイプの一覧(ページング含む)や、追加・更新については
露木> 汎用ビューという仕組みでかなりコードの記述量を軽減可能です。
露木> 主に、URLConfとテンプレートを記述する作業になります。
露木> もちろん複雑な入力画面等は(ある程度の)作り込みが必要になってきます。
露木> ＃汎用ビューから外れるのは「商品リストの発注フォーム」位かな？
Generic Viewってやつですね。名称だけは聞いてますが、実体がなんなのかは
よくわかっていませんでした。
佐古田> ・コンテンツのツリー構造に対するアプリケーションの位置づけ。
佐古田> 最後に関しては単にアプリケーションはプロジェクト内に並列に存在し、公開
佐古田> ウェブ上での親子関係というのはただURLConfでマッピングするだけでしょう
佐古田> か。
露木> URLConfのマッピングのみです。コンテンツ間の関連とURLには関係があり
露木> ません。
露木> 逆に言えば、Zopeのようにどんどん階層を深くしいくような仕組みはありま
露木> せん。
そうでしたか。
露木> Zopeにすべきか、Djangoにべきかは・・・はて？
ここには正解はないでしょうね。
個人的にZopeは多少なりとも経験があるだけの話で本当に1,2週間って限定さ
れれば私の場合Zopeになりますよ。
ただZopeのきらいなところは、まずZMI、次にExternal MethodやProductを使
わないかぎり制限を受けたPython環境であるということ。
そういう意味で私がDjangoに魅力を感じる点は、*勘違いがなければ*Emacsで
不自由なく開発できる、基本的にpure python環境、対話モードの提供といっ
たところでしょうか。
結論として大きいのから小さいのまでいろいろとウェブアプリケーションはつ
くってきているのでチュートリアルやサンプル試しながらちょっと時間的な余
裕をみて既存のものをDjangoで実装してみようかなと思っています。
またいろいろ質問させていただくかもしれませんがよろしくお願いします。
- sS
Nakane Ryuji
06/10/29 に Sumiya Sakoda<hige...@buta7.com> さんは書きました:
>
> 露木> ・ユーザテーブルをDjangoに持たせたくない場合
> 露木> 認証を別のテーブルで行うことは問題ありませんが、Django上ではDjangoの
> 露木> ユーザModelを利用しないと、管理画面や汎用ビュー等に問題が発生します
>
> そうですか。そこまでは考えていませんでしたが、LDAPのユーザ認証を行うよ
> うなハッキングを紹介しているサイトがあったのでそのあたりは克服できそう
> です。
管理画面(django.contrib.admin) および、汎用ビュー(generic view)
の一部は、Djangoの認証機構(django.contrib.auth) のユーザモデル
を使用しているため、認証機構の組み込みが必須になります
Dnangoの認証機構を使う必要はありませんが、認証機構に含まれるmodel
が必ず参照されますので、ゲスト並のアクセス権下での動きに限定され
ます
また、独自認証機構を組み込んだときに、Djangoの認証機構を外せる
かどうか、Djangoの認証modelを置き換えられるかどうかはまだ試して
いません
--
Nakane Ryuji living at Nagoya
// mailto:ryu...@gmail.com
// business http://www.compnet.jp/
// private http://www.bernese.jp/lux/