Web2py-コア

コマンドラインオプション

前の章で、GUIウィジェットを使用してweb2pyサーバーを起動する方法を学びました。

このウィジェットは、サーバーをから起動することでスキップできます command line 促す。

python web2py.py -a 'パスワード' -i 127.0.0.1 -p 8000

web2pyサーバーが起動するたびに、ファイル「parameters_8000.py"すべてのパスワードがハッシュ形式で保存されます。

追加のセキュリティ目的で、次のコマンドラインを使用できます-

python web2py.py -a '<recycle>' -i 127.0.0.1 -p 8000

上記のシナリオでは、web2pyは「」に保存されているハッシュ化されたパスワードを再利用します。parameters_8000.py"。

場合は、ファイル「parameters_8000.py"が誤って、またはその他の理由で削除されたため、web2pyでWebベースの管理インターフェイスが無効になっています。

URLマッピング/ディスパッチ

web2pyの機能は、URLを特定の形式でマップするmodel-view-controllerに基づいています- http://127.0.0.1:8000/a/d/f.html

関数までルーティングします “f()” コントローラに記載されています d.py「a」という名前のアプリケーションの下にあります。コントローラーがアプリケーションに存在しない場合、web2pyは次の名前のデフォルトコントローラーを使用します“default.py”

URLで指定されている関数が存在しない場合、デフォルトの関数は init()使用されている。URLの動作は、次の画像に概略的に示されています。

拡張機能 .htmlURLはオプションです。拡張子はの拡張子を決定しますViewこれは、コントローラーで定義された関数の出力をレンダリングします。同じコンテンツが複数の形式、つまりhtml、xml、json、rssなどで提供されます。

引数を受け入れ、ユーザーに適切な出力を提供する関数に基づいて、要求が渡されます。これは、ユーザーのニーズに応じて出力を提供するために、アプリケーションのモデルおよびビューと対話するコントローラーです。

web2py –ワークフロー

web2pyのワークフローについて以下で説明します-

  • Webサーバーは、独自のスレッドですべてのHTTP要求を同時に管理します。

  • HTTPリクエストヘッダーが解析され、ディスパッチャに渡されます。

  • ディスパッチャは、アプリケーションリクエストを管理し、 PATH_INFO関数呼び出しのURL。すべての関数呼び出しはURLで表されます。

  • 静的フォルダーに含まれるファイルに対するすべての要求は直接管理され、大きなファイルはクライアントにストリーミングされます。

  • 静的ファイル以外のリクエストは、アクションにマップされます。

  • リクエストヘッダーにアプリのセッションCookieが含まれている場合、セッションオブジェクトが取得されます。それ以外の場合は、セッションIDが作成されます。

  • アクションが値を文字列として返す場合、これはクライアントに返されます。

  • アクションがiterableを返す場合、それはデータをループしてクライアントにストリーミングするために使用されます。

条件付きモデル

前の章では、の機能を見ました Controllers。web2pyは、各アプリケーションでモデル、ビュー、コントローラーを使用します。したがって、の機能を理解することも必要です。Model

他のMVCアプリケーションとは異なり、web2pyのモデルは条件付きとして扱われます。サブフォルダー内のモデルは、コントローラーの使用状況に基づいて実行されます。これは、次の例で示すことができます-

URLを検討してください- http://127.0.0.1:8000/a/d/f.html

この場合、 ‘a’ アプリケーションの名前です、 ‘d’ コントローラの名前であり、 f()コントローラに関連付けられている機能です。実行されるモデルのリストは次のとおりです。

applications/a/models/*.py
applications/a/models/d/*.py
applications/a/models/d/f/*.py

ライブラリ

web2pyには、すべてのアプリケーションにオブジェクトとして公開されるライブラリが含まれています。これらのオブジェクトは、「gluon」という名前のディレクトリの下のコアファイル内で定義されています。

DALテンプレートのようなモジュールの多くには依存関係がなく、web2pyのフレームワークの外部で実装できます。また、グッドプラクティスと見なされる単体テストも維持します。

アプリケーション

web2pyアプリケーションを図形式で以下に示します。

ザ・ Applications web2pyで開発されたものは以下の部分で構成されています-

  • Models −データおよびデータベーステーブルを表します。

  • Controllers −アプリケーションロジックとワークフローについて説明します。

  • Views −データの表示のレンダリングに役立ちます。

  • Languages −アプリケーション内の文字列をサポートされているさまざまな言語に翻訳する方法を説明します。

  • Static files −処理を必要としません(画像、CSSスタイルシートなど)。

  • ABOUT そして README −プロジェクトの詳細。

  • Errors −アプリケーションによって生成されたエラーレポートを保存します。

  • Sessions −特定の各ユーザーに関連する情報を格納します。

  • Databases −SQLiteデータベースと追加のテーブル情報を保存します。

  • Cache −キャッシュされたアプリケーションアイテムを保存します。

  • Modules −モジュールは他のオプションのPythonモジュールです。

  • Private −インクルードされたファイルは、コントローラーによってアクセスされますが、開発者によって直接アクセスされることはありません。

  • Uploads −ファイルはモデルによってアクセスされますが、開発者によって直接アクセスされることはありません。

API

web2pyでは、 modelscontrollers そして views 開発者向けに特定のオブジェクトがインポートされる環境で実行されます。

Global Objects −要求、応答、セッション、キャッシュ。

Helpers− web2pyには、プログラムでHTMLを作成するために使用できるヘルパークラスが含まれています。これは、HTMLタグに対応します。“HTML helpers”

たとえば、A、B、FIELDSET、FORMなどです。

セッション

セッションは、サーバー側の情報ストレージとして定義できます。このストレージは、Webアプリケーション全体でのユーザーの操作を通じて保持されます。

web2pyのセッションは、ストレージクラスのインスタンスです。

たとえば、変数は次のようにセッションに格納できます。

session.myvariable = "hello"

この値は次のように取得できます

a = session.myvariable

変数の値は、コードが同じユーザーによって同じセッションで実行されている限り、取得できます。

セッションのためのweb2pyの重要な方法の1つは “forget”

session.forget(response);

セッションを保存しないようにweb2pyに指示します。

バックグラウンドでタスクを実行する

HTTPリクエストがWebサーバーに到着し、Webサーバーは各リクエストを独自のスレッドで並行して処理します。アクティブなタスクはフォアグラウンドで実行され、他のタスクはバックグラウンドで保持されます。バックグラウンドタスクの管理もweb2pyの主な機能の1つです。

時間のかかるタスクは、バックグラウンドで保持することが望ましいです。バックグラウンドタスクを管理するメカニズムのいくつかを以下に示します-

  • CRON

  • Queues

  • Scheduler

CRON

web2pyでは、 CRON指定された時間間隔内でタスクを実行する機能を提供します。各アプリケーションには、その機能を定義するCRONファイルが含まれています。

スケジューラー

組み込みのスケジューラーは、優先順位を設定することにより、バックグラウンドでタスクを実行するのに役立ちます。タスクを作成、スケジュール、および変更するためのメカニズムを提供します。

スケジュールされたイベントは、ファイル名でモデルにリストされます “scheduler.py”

アプリケーションの構築

web2pyでモデルとコントローラーを作成する概要を説明しました。ここでは、という名前のアプリケーションの作成に焦点を当てます“Contacts”。アプリケーションは、会社のリストと、それらの会社で働く人々のリストを維持する必要があります。

モデルの作成

ここでは、データディクショナリのテーブルの識別がモデルです。連絡先アプリケーションのモデルは、「models」フォルダ。ファイルはに保存されますmodels/db_contacts.py

# in file: models/db_custom.py
db.define_table('company', Field('name', notnull = True, unique = True), format = '%(name)s')
db.define_table(
   'contact',
   Field('name', notnull = True),
   Field('company', 'reference company'),
   Field('picture', 'upload'),
   Field('email', requires = IS_EMAIL()),
   Field('phone_number', requires = IS_MATCH('[\d\-\(\) ]+')),
   Field('address'),
   format = '%(name)s'
)

db.define_table(
   'log',
   Field('body', 'text', notnull = True),
   Field('posted_on', 'datetime'),
   Field('contact', 'reference contact')
)

上記のファイルが作成されると、URLを使用してテーブルにアクセスできます http://127.0.0.1:8000/contacts/appadmin

コントローラーの作成

ザ・ Controller 連絡先を一覧表示、編集、削除するためのいくつかの機能が含まれます。

# in file: controllers/default.py
def index():return locals()
def companies():companies = db(db.company).select(orderby = db.company.name)
return locals()

def contacts():company = db.company(request.args(0)) or redirect(URL('companies'))
contacts = db(db.contact.company == company.id).select(orderby = db.contact.name)
return locals()

@auth.requires_login()
def company_create():form = crud.create(db.company, next = 'companies')
return locals()

@auth.requires_login()
def company_edit():company = db.company(request.args(0)) or redirect(URL('companies'))
form = crud.update(db.company, company, next='companies')
return locals()

@auth.requires_login()
def contact_create():db.contact.company.default = request.args(0)
form = crud.create(db.contact, next = 'companies')
return locals()

@auth.requires_login()
def contact_edit():contact = db.contact(request.args(0)) or redirect(URL('companies'))
form = crud.update(db.contact, contact, next = 'companies')
return locals()

def user():return dict(form = auth())

の作成 view その出力とともに、次の章で説明します。