ぬきポンのWeb技術関連のメモ

webapp2の公式ドキュメントを読む会もとうとう６回目になりました。

今回で、やっとURL routingが終了です。

■Path prefix routes

何度も同じ記述を避けるための記載方法です。

リクエストをグループ化して定義する事ができるようになります。

app = WSGIApplication([
    Route('/users/<user:\w+>/', UserOverviewHandler, 'user-overview'),
    Route('/users/<user:\w+>/profile', UserProfileHandler, 'user-profile'),
    Route('/users/<user:\w+>/projects', UserProjectsHandler, 'user-projects'),
])



import webapp2
from webapp2_extras import routes

app = WSGIApplication([
    routes.PathPrefixRoute('/users/<user:\w+>', [
        webapp2.Route('/', UserOverviewHandler, 'user-overview'),
        webapp2.Route('/profile', UserProfileHandler, 'user-profile'),
        webapp2.Route('/projects', UserProjectsHandler, 'user-projects'),
    ]),
])

PathPrefixRouteは、記載の仕方だけでなく、処理効率も上がるそうです。

通常は、定義されたRouteを順番にマッチングしながら処理を行うのですが、PathPrefixRouteに一致しなかった場合は、全てスキップするため無駄なマッチングをせずに済むようです。

続きを読む...

今回も、横浜のコワーキングスペース「タネマキ」で、GAE/Pの勉強会を行いました。

その勉強会の中で、webapp2の公式ドキュメントを読み解く会を継続して行なっています。

今回は、URL routingの以下の項目からスタートです。

■The URL template

これを使うと、リクエストURLのパターンマッチングが出来るようになります。

handler側でのパラメータの受け取り。

　handler側では、パラメータとして以下のように受け取ることが出来ます。

　nameありの場合は、**kwargsで受け取る
　nameなしの場合は、*argsで受け取る

※nameありとnameなしの混在について

　name ありとnameなしの混在とした場合は、
　nameを付けた項目のみ、**kwargs で受け取ることが可能。
　nameを付けていない項目は、パターンマッチングには利用できるが、handlerでは受け取ることはできない。

以下は、公式サイトのサンプルソース

Route('/<user_id>/settings', handler=SettingsHandler, name='user-settings')
Route('/<user_id:[^/]+>/settings', handler=SettingsHandler, name='user-settings')

続きを読む...

前回までで、The WSGI applicationが終了し（１ページで３回もかかりましたが。。）今回からは、次の項目の、URI routingに入ります。

■URI routing 

URI routingは、main.pyなどでリクエストに対して、どのhandlerを割り当てるかなどを設定する部分です。

以下の様な記載をする部分です。

app = webapp2.WSGIApplication([
 (r'/', HomeHandler),
])

webapp2では、webapp(python2.5)での記述を引き継ぎつつ、新しい協力な機能が追加されています。

続きを読む...

今週も、横浜のコワーキングスペース「タネマキ」で、 GAE/Pの勉強会を実施しました。

勉強会の中で、webapp2の公式ドキュメントを読み解く会を継続して実施しています。

本日は、こちらから。 

■Debug flag  

debugをFalseに設定すると、500の際にクライアントにstack traceが出なくなる。

Trueに設定すると、stack traceが出る。 

App Engineでは、以下の記載をすることで、開発環境とプロダクション環境を判断することができる。

実際にSDKので起動した場合には、Development/2.0が入っている。 

import os

import webapp2

debug = os.environ.get('SERVER_SOFTWARE', '').startswith('Dev')

app = webapp2.WSGIApplication(routes=[
    (r'/', 'handlers.HelloWorldHandler'),
], debug=debug)

もし、アプリの中でdebugフラグを取得したい場合には、 

app = webapp2.get_app()
debugFlg = app.debug

で取得出来そう。

続きを読む...

今週も横浜のコワーキングスペース「タネマキ」で、GAE/Pを中心とした勉強会を実施しました。今回も２名でした。

先週に引き続き、前半はwebapp2公式ドキュメントを読み解く会を実施しました。

今回は、Config,Registry,Error handlersの部分です。

いつも通り、英語は殆ど分からないので、読解力にはかなりの不安があります。。

1. Config
   Configは、ディクショナリ形式で、モジュール全体で共有できる。
   以下のソースは、公式サイトから転載
   ・configの設定
   

   import webapp2
   
   config = {'foo': 'bar'}
   
   app = webapp2.WSGIApplication(routes=[
       (r'/', 'handlers.MyHandler'),
   ], config=config)
   

   ・configの使用方法
   

   import webapp2
   
   class MyHandler(webapp2.RequestHandler):
       def get(self):
           foo = self.app.config.get('foo')
           self.response.write('foo value is %s' % foo)
   

   僕の場合は、config.pyやcommon.pyを作って共通設定を書いているので、あまり使いドコロが分からなかったのですが、この設定は、「モジュール単位」に設定が出来るようです。当サイトでも、公開画面と管理画面でモジュールを分けていて、管理画面はadmin権限でのアクセスを設定しています。このような場合に、webapp2のconfigを設定しておくと、classを共有していた場合に、configの値を参照することで振る舞いを切り分けることが出来そうです。

2. Registry
   

   インスタンス間を跨った、アプリケーション全体での共有ディクショナリのようです。
   以下のソースは、公式サイトから転載

   import webapp2
   
   def get_parser():
       app = webapp2.get_app()
       # Check if the instance is already registered.
       my_parser = app.registry.get('my_parser')
       if not my_parser:
           # Import the class lazily.
           cls = webapp2.import_string('my.module.MyParser')
           # Instantiate the imported class.
           my_parser = cls()
           # Register the instance in the registry.
           app.registry['my_parser'] = my_parser
   
       return my_parser
   

   シングルトン的な使い方が可能な感じですかね。使い方としては、GAEのmemcacheと同じ考え方のようです。先にRegistryから取得してみて、取得出来ない場合には生成する処理を実施し、Registryにセットする。

   ただ、GAEの場合は、スピンダウンが割りと頻繁に起こると思いますので、memcacheを利用するのが正解の様な気がします。

3. Error handlers

   WISGアプリケーションとしてのエラーハンドリングの方法ですね。httpのresponseを制御する為の方法で、ドキュメントでも、404,500はハンドリングした方が良いと書いてあるようです。

   以下のコードも、公式ドキュメントからの転載です。

   import logging
   
   import webapp2
   
   def handle_404(request, response, exception):
       logging.exception(exception)
       response.write('Oops! I could swear this page was here!')
       response.set_status(404)
   
   def handle_500(request, response, exception):
       logging.exception(exception)
       response.write('A server error occurred!')
       response.set_status(500)
   
   app = webapp2.WSGIApplication([
       webapp2.Route(r'/', handler='handlers.HomeHandler', name='home')
   ])
   app.error_handlers[404] = handle_404
   app.error_handlers[500] = handle_500
   

   使い方は、コードを見ればわかると思いますが、logging.exception(exception)は、loggingの特別な出力方法のようです。これで、stack traceが出力できます。response.set_status(404)は、固定でコードを入れるのがイマイチな場合は、response.set_status(exception.code)とすると、受け取ったレスポンスコードがセットできるようです。僕が使うときは、面倒なので404と403を同じ404の画面を返しているのですが、コードは、403のまま返したい時などに利用できそうです。

１人でやっている時は、なかなか読み切れず、とりあえず動けばよい程度で使っていますが、頑張って呼んでみると色々分かってきて面白いですね。

The WSGI application 

続きを読む...