次世代フレームワーク Sencha Touch

ExtJSというJavascriptフレームワークをご存知だろうか？

非常に優れたUIを提供するJavascriptのクロスプラットフォームフレームワークで、私もよくお世話になっている。（DEMO)

ExtJSは彼らの商品名でもありブランド名でもあったが、次世代フレームワークの投入とともに「Sencha」という名前に変更された。もちろん、語源は日本語の「煎茶」である。名前の良し悪しは個人の意見に任せるとして、彼らが今回投入した「Sencha Touch」は注目に値するフレームワークだ。

一言で言えば「iPadやiPhoneそっくりのUIをもつWebアプリが作れるフレームワーク」である。もちろんAndroidもサポートされている。このSencha TouchはExtJSにjQueryのプラグインである「jQtouch」、ベクターグラフィックライブラリである「Raphael」を融合し、HTML5及びCSS3ベースで再構築を行った「スマートフォン専用フレームワーク」である。

UIの素晴らしさは説明するよりデモを見るほうが早いだろう。UIだけでなく特筆すべき機能が「タッチパネルへのタッチイベントが利用できる」という点だ。これはHTML５ならではの拡張イベントで、あのiPadやiPhoneの拡大操作（両指で広げるやつ）なんかもUIとして取り入れられる。これはWeb用フレームワークとしてはかつてないもので、非常に画期的だ。その他の機能としては「ローカルストレージ」へも対応しているようだ。APIを眺めてみたがExtJSを使っていた方ならすんなり行けるはずだ。

問題はライセンスだ。ExtJSは途中でライセンスを「LGPL」から「GPL V3」へ変更したためエンジニアからブーイングが続出、エンジニアチームが分断したり、プロジェクトが枝分かれしたりと何かと物議をかもしだした。GPLとはいえデュアルライセンス形式で、無料のパブリックライセンス（GPL）と有料のコマーシャルライセンスで、要は数万円のライセンスを払えばGPLは免責されますよというものだった。

「Sencha Touch」は現在ベータ版なのでコマーシャルライセンスが準備中となっているが、原則これまでと同じ方式を採用するようだ。しかしながら数多くの批判に対応するためか、パブリックライセンスの場合でも例外事項が新たに設置された。パッケージへSenchaTouchを包括しないこと、SenchaTouchの組み込み方を提示するなどの条件と、配布するパッケージが彼らが提示するオープンソースライセンス（有名なものはほとんど含まれている）で提供する場合に限りGPLの処理（ソースコードにライセンスを書く等）を免責するというものだ。より詳細な説明は彼らのライセンスページ」を参照されたい。

iPadやスマートフォンが大ヒット中のなか、「スマートフォン対応アプリ」のニーズは確実に高まっている。これからの技術的な幅を広げるためにも、ぜひチェックしておきたいフレームワークである。

Ext JS - kurz & gut

• 作者: Aron Homberg



• 出版社/メーカー: O'Reilly Vlg. Gmbh & Co.



• 発売日: 2011/06


• メディア: Perfect


• クリック: 50回


• この商品を含むブログ (1件) を見る

Ext JS入門―リッチUIなWebサイトをつくるAjaxフレームワーク

• 作者: 古籏一浩,石丸健太郎



• 出版社/メーカー: 秀和システム



• 発売日: 2009/07


• メディア: 単行本


• 購入: 5人 クリック: 131回


• この商品を含むブログ (16件) を見る

Google Apps + Federated Login

Google Apps SDK 1.3.4から、OpenIDによる認証がサポートされるようになった。

最近はKayFrameworkでアプリを作っているのだが、Kayは早くからOpenIDに対応してGoogle Marketplace用のアプリもサポートしていた。今回のSDKのバージョンアップでKayの独自実装は延期となり、新たな統合方法が検討されている。

現在開発しているアプリではGoogle Appsによるアカウント認証を行うためいろいろと調査した。認証方法にさほど変更はなく、create_user_loginメソッドに以下のパラメータが追加されている。

Function

The google.appengine.api.users package provides the following functions:

create_login_url(dest_url=None, _auth_domain=None, federated_identity=None)

_auth_domainとfederated_identityパラメータだ。(Federated Login周りの情報は現在英語版でしか提供されていない）

Google Appsでログインするには_auth_domain=None, federated_identity='Google Appsのドメイン’でOKだ。（このあたりの情報はあまり出揃っていないようだ）

実際稼働させてみるとGoogleApssアカウントへの認証へ飛ばされる。もしAppsのロゴなども変更していればそれらも反映されている。

Kayにどうやって組み込もうかとあれこれ考えたが、やっぱり手っ取り早く@apps_login_requiredデコレータを自作することにした。

もともとのkay.auth.decorators.login_requiredのcreate_login_urlの部分を変更してOK。

さて、この時に認証先のドメインをどうやって取得するかが問題となった。

Google Market PlaceであればManifestのURLにドメインを組み込んでセットアップを行うのでその時に情報はあれこれ取得できるだろう。

今回開発しているアプリはMarketplace用ではなく、Google Appsへドメイン追加でアプリを追加している。また独自ドメインでエイリアスを設定している。

独自ドメインでAppsへ登録したなら、その情報を使えばいいじゃないかということでいろいろと調べた。環境変数のSERVER_NAMEでホスト名は取得できるが、そこからドメインを推測するのは避けたい。AUTH_DOMAINかと思って試したが、gmail.comからかわらず・・。

いろいろ試してようやく見つけることができた。

Google Apps Engineで作ったアプリを、Google Appsへドメイン許可して登録すると以下の環境変数が追加される。

・HTTP_X_ZOO: 'app-id=アプリケーションID,domain=GoogleAppsドメイン'

・HTTP_X_GOOGLE_APPS_METADATA: 'domain=GoogleAppsドメイン’

これらの環境変数は独自ドメインでアプリにエイリアスを登録した時にのみ付与される。（appspot.comの場合は付与されない）

Federated Loginを使用した場合はその他にもFEDERATED_IDENTITYやFEDERATED_PROVIDERなども追加される。（DATACENTERなんていう変数も・・）

また、もうひとつの注意点としてFederated LoginでGooleAppsの管理者アカウントへログインした場合でも、is_current_user_admin()がTrueにはならない。あくまでアプリの管理者リストに登録されている場合にのみTrueが返される。（appspot.comの管理サイトで管理者リストにメールアドレスを登録する必要がある）

これで、AppsEngineで作ったアプリをドメイン追加でApps認証させることができるようになった。