web2py, plugin_wikiのeditor権限

Plugin_wikiははとても便利
サイトのページをサーバー上で直接に編集できる。
通常のページだけでなくメニューやフッターも作れます。
Python codeや{{...}}タグも使えます。ページは様々なWidgetがあってYouTubeやGoogleのchartやmapを埋め込めます。これはvimeoにも載っているのですが。What is going on with web2py?
その使い方はOnline bookに詳しいのですが、ログインしてもPageがなかなか現れませんでした。下の図のPagesというタブです。

確かこのブログで紹介しましたが、editorというgroupのメンバーがログインすると現れます。だがこれは結構に面倒です。よくBookを読んだらmail.setting.senderとログインしたユーザーのメールアドレスが同じならeditorの権限を得ることが書いてあります。
それを記録しておきます。


from gluon.tools import *
mail = Mail()                                  # mailer
auth = Auth(globals(),db)                      # authentication/authorization
crud = Crud(globals(),db)                      # for CRUD helpers using auth
service = Service(globals())                   # for json, xml, jsonrpc, xmlrpc, amfrpc
plugins = PluginManager()

mail.settings.server = 'gae'  # your SMTP server
mail.settings.sender = 'xxxxxxxx@gmail.com'         # your email
mail.settings.login = 'xxxxxxxx@gmail.com:<password>'      # your credentials or None
if auth.user:
    plugins.wiki.editor = auth.user.email == mail.settings.sender

私は一人でページを作っているのでこれで十分です。

web2py , openID,google,Facebookでログイン

非常に強力なwebのフレームです。特にGoogle App Enginesへdeployするには優れています。
Djangoからweb2pyにスイッチしたのはそのためです。

そのusers groupは非常に活発で開発者（Massimo Di Pierro）が直接に回答していること、メンバーに開発者の学生が多いことなどで非常に役に立っています。オンラインドキュメントはよく編集されていて優れています。ドキュメントで分からないこと全部このユーザーグループで検索すればほぼことは足ります。質問しなくても検索すれば大方の問題は解決します。残念ながら英語しかありませんが。

掲題のログインの問題にもどって。

web2pyは完璧な認証システムが備わっています。
さらにjanrain(user management platform for the social web)とのインタフェースがクラス（RPXaccount）として用意されているのでこれをネイティブなログインフォームに代入すればopenID,Google,openIDなどのアカウントでログインできます（janrainは商用サービスですがbasicはfreeです）。
janrainのEngageというプロダクトに好みの名前のドメインを登録するとapi_keyがもらえますから、これをRPXaccountのパラメータにして初期化してネイティブなログインフォームに代入するだけです。

 auth.settings.actions_disabled=['register','change_password','request_reset_password']
auth.settings.login_form = RPXAccount(request, api_key='もらったapi_key',domain='ドメイン',
    url = "http://localhost:8000/%s/default/user/login" % request.application)
最後の行はweb2pyのログインURLです。

これでGoogleやFacebookのアカウントをもった訪問者はログインできます。同時に訪問者の名前やメールアドレスがこちらのサイトのuserテーブルに保存されます。

しかしこのままだと今まで自分のサイトに登録した訪問者がログインできません。
そのためにExtendedLoginFormというクラスが用意されています。
argsにトークンを入れてログインフォームをスイッチできるようにしたものです。
ところがこれがduplicate keywordsになってうまく動きませんでした。
この問題はweb2pyのユーザーグルプに投稿されて解決策がhow to use ExtendedLoginForm ?に掲載されていました。
詳細は省きますが、その結果は次の画面のようになります。
web2pyには幾つかのGoogleなどのログインメソッドが用意されています。まだこれは試していません。janrainは単一のゲートウエイになっているので便利です。

画面の上半分はよそのアカウントでログイン、下半分の会員登録は自分のサイトに登録します。あるいはログインします。

Wweb2py、GAEで公開まで

私は机上のMacで研修のためのアプリケーションを開発しています。
そこでの経験をまとめておくと良いのではとおもって投稿します。 


localhost:8000 => localhost:8080 => Google App Enginesと言う具合に段階を上げています。
ポートの8000はweb2py.py、8080はGAEのシミュレータでgoogle提供のSDKです。ここで開発デバッグ、試験してGoogle App Enginesで公開にアップロードして公開します。


web2py.pyでは完全なデバッグ環境があってDjangoより格段に進歩した環境が提供されます。
トレースバックのコールシーケンスの各段階の変数のスナップショットは当然ですが、adminの画面からviewやcontollerを直接呼び出せま
す。ですから分からないことがあると、k=kという文を入れてトラップさせて自分のプログラムだけでなくweb2pyの中のうごきをトレースバックして
います（本当はもっとスマートな方法があるかもしれませんが）。
非常に便利ですが、この段階では私はデータベースにsqliteを使っていますからアプリケーション間でデータの共有ができません。ログインしても別の
アプリケーションではuserテーブルの値が別々のデータベースになるので、認証関係の設定の確認ができません。これが難点です。しかしsqliteは
SQlite Databaseブラウザーがあるのでこれで個別のデータの確認を簡単にとれます。
データベースはシミュレータで共有できるようになります。アプリケーションで共有するテーブルをそれぞれで定義しておけばOKです。userテーブルも
共有できますから、認証の確認は確実です。
データベースのブラウジングはhttp://localhost:8080/_ah/adminで作成、閲覧して編集削除することができます。
registrationではメールによるverificationをしたいのですが、私のMacのサーバーからメールを発信する方法を知りません（ど
なたかご存知でしたら教えてください）。
いまはauth_userを/_ah/adminで開いて該当するエントリのregistration keyを取り出して、http://
localhost:8080/members/default/user/verify_email/1b0cd09d-1e4c-407a-
ae8a-536ecedd80c5とやっています。
シミュレータで一通りのデータベースアクセスをします。ここでindexテーブルを全部作っておかないとGAEが動作しません。
シミュレータで試験するのはデータが共有されておこる不都合をチェックするくらいでしょうか。
最後にGAEです。
実はGoogleAppEnginesはバージョンがあってDefaultのバージョンはhttps:xxx.appspot.comで公開されます が、それ以外のバージョンは頭にバージョン番号をつけてアクセスします。https:2.xxx.appspot.comという具合です。ここでも公開までのステップが用意されています。まぁアルファバージョン、ベータバージョンということでしょう。

バージョンはapp.yamlで指定します。appspot.comでログインすると自分のGAEのアプリケーションの空間に入れます。アプリケーションのリストがありますから、該当のアプリケーションを選択してそこのversionsでデフォールトのバージョンを設定できます。

デフォールトのアプリケーションとは、私のこのアプリケーションではmaselstyle.appspot.comで呼び出されるアプリケーションです。以前のバージョンや試験中のバージョンは、それがバージョン４とすると、4.masel-style.appspot.comです。
デフォールトは利用者がアクセスしますから、デフォールト以外で試験して、OKならば、そのバージョンをデフォールトにします。これはプログラムコード

プログラムコードのバージョンとは別にデータベースの値をnamespaceでコントロールできます。
アプリケーションのdb.pyで指定します。
if request.env.web2py_runtime_gae:            # if running on Google
App Engine
    db = DAL('gae://mynamespace')             # connect to Google　BigTable
mynamespaceはその名のとおり名前空間ですからデータベースの構造は同じでも違う値を持つことになります。

Google App Engine、アプリケーションでデータベース共有

Web2pyでは、GAEに向けた開発では３つのモードがあります。

1. GAEの本番、いわゆるProduction
2. GAEのサンドボックス
3. web2pyの実行

web2pyの開発環境は至れり尽くせりでViewやControllerを直接実行したり、編集したり、トラップしたときのトレースも不自由なくできます。

わたしはデータベースは面倒なのでsqliteを使っています。SQLite Database Bowser（http://sqlitebrowser.sourceforge.net)などはほとんど必要としません。

全部 この開発環境で開発からデバッグができます。

しかし問題がない訳ではありません。

それは

複数のアプリケーションの間のシェアです。マニュアルにはいろいろ書いてありますが、(http://www.web2py.com/book/default/chapter/04?search=cooperation#Cooperation)私にとっては、一向に要領を得ません。アプリケーションの間でセッションを共有しようとしたいのですが、結局はデータベースが共有できればよいのです。

SQLiteを使うとファイルシステムにストレージができます。web2pyではアプリケーションの下のディレクトリ、databasesです。

シンボリックリンクを使ってシェアしようとしたのですが、うまく行きません。

ところがこの問題はGAEのサンドボックスではないのでした。

GAEのサンドボックス、dev_appserver.pyはGoogleのデータベース、Big Tableをシミュレートしてくれます。

こちらはファイルシステムが使えません。アプリケーションのdb.pyに次のようなラインがあります。ここでmynamespaceがデータベースの名前空間を指定しているようです。

あるアプリケーションで定義したテーブルを別のアプリケーションのdb.pyで定義しておいて、その名前空間が同じならば、そのテーブルを共有できます。

if request.env.web2py_runtime_gae:            # if running on Google App Engine

    db = DAL('gae://mynamespace')             # connect to Google BigTable

    session.connect(request, response, db=db, masterapp=None)

 # and store sessions and tickets there

    ### or use the following lines to store sessions in Memcache

    # from gluon.contrib.memdb import MEMDB

    # from google.appengine.api.memcache import Client

    # session.connect(request, response, db = MEMDB(Client()))

else:                                         # else use a normal relational database

    db = DAL('sqlite://storage.sqlite')       # if not, use SQLite or other DB

データベースを覗くには、このURLでOKです。

 http://localhost:8080/_ah/admin

要するにまとめると、

web2py ---> dev_appserver.py ---> appcfg.pyでアップロードすればよいということでした。

もうひとつ便利なこと。
web2pyはlocalhost:8000でリッスン、サンドボックスは8080でリッスンします。だからブラウザの上で8000を8080とするだけで同じファンクションを２つの環境で試験できます。これは便利でした。

GAEでソーシャル・スタイル、web2pyで開発

アプリケーションをGAEで稼働させました。
URLは
https://masel-style.appspot.com

日本語になり切らない部分（中国語が残っている）もありますが、試しに訪問してみてください。
実はDjangoのregistrationが私にとっては、ひどくややこしくて苦労したのですが、web2pyではいとも簡単にできました。パスワード忘れや会員登録のメールアドレスの実在確認とか結構に面倒くさかったのが、すんなりでした。

アプリケーションはソーシャル・スタイルの学習をWebでやってしまおうという実験室です。
まだ無料ですから、今のうちに。

スタイル調査のサンプルの出力です。

web2py日本語

問題：login, password, emailなどのweb2pyで表示する基本的なフレーズを日本語にしたい。

内容：
基本的にTに渡された文字列は翻訳の対象になって、
各国語の利用ができるようにLanguageファイルが用意されている。
開発コンソールの「language」に各国語がリストされている。残念ながら日本語、ja.pyがない。ja.pyファイルはオリジナル文字列（Tで囲まれた文字列）と翻訳が対になったファイルである。
解決策：
そこでファイルja.pyを作成して、Languagesの下にある「update all languages」をクリックすれば、すべてのTで囲まれた文字列が出てくる想定であった。

想定違いの問題：
、Loginとかregisterのオリジナル文字列がこのファイルに現れない。どういう事の次第か、開発したアプリケーションのTの文字列が出現する。
たとえばコントローラーのdefault/indexで最後に、
return dict(message=T('ソーシャル・スタイル・クラブにようこそ'))
とやるとTの括弧内が言語ファイルに出てくる。ところがweb2pyのパッケージのAuthenticationにある筈のLogin,registerが出ないのである。
解決策：
中国語の言語ファイルを見るとloginなどが中国語になっている。
そこでこのファイルをja.pyに複写して、これを日本語に変換してOKになりました。

この投稿は
http://www.vimeo.com/7520812
が参考になりました。

このビデオのなかのdb.pyの次の２行も気になります。

Deploy 再び

開発中のシステムはソーシャルスタイルの診断システムをスタイルの学習システムです。
スタイル診断までをアカウントの登録、ログイン、質問紙の回答とかの一通りのアプリケーションを開発して、web2pyの開発環境で試験、コマンドライン、python2.5 web2py.pyでサーバーをスタートして滞りなく来ました。
そこでGAEにアップロード、deployしたのですが、internal errorの頻発でticketも閲覧できない。Googleのコンソールからデータベースのチケットを見ても何のことやら皆目分からない。
そこで何処かに書いてあったのはindex.yamlのこと。このファイルはこのアプリケーションが実行したデータベースアクセスを記録して、deployと同時にGAEのデータベースにインデックスを作成するということ。
探したができていない。

inde.yamlはdev_appserverを走らせないと作らない。dev_appserverはGAEの実行環境のサンドボックス(sandbox)であり、データベースをファイルシステムでシミュレートする。

ようするにweb2pyでサーバーを走らせたときはsqliteでデータベースを走らせる。dev_appserverはGAEのデータストレージを仮装してくれるというわけ。

dev_appserverはデバグ用のコンソールがあって
localhost:8080/_ah_adminで開きました。

dev_appserverで、実行してインデックスを作ったら

appcfg.py update_indexes web2py

でインデックスだけアップロードしてくれます。

役にたったURLは
開発については
http://code.google.com/intl/ja/appengine/docs/python/tools/devserver.html

アップロードと管理については
http://code.google.com/intl/ja/appengine/docs/python/tools/uploadinganapp.html
です。


結論
web2py.pyで開発して試験しても、dev_appserverで一通りのデータベースアクセスをしないとGAEでは動かないということ。