|
||||||
|
Written By:
川俣 晶 |
||||||
|
ModulaF: Simple Modulalized Web Application Framework アイデアメモ1 2004年5月16日 株式会社ピーデー 川俣晶 (autumn@piedey.co.jp) ● 大目的 ・Webアプリケーションにおいて、高機能、カスタマイズ可能、個別デバイス対応、コスト低減を実現するフレームワークを作成する ・デバイスごとにページ内に含める情報量を適切に自動増減できる ・長いページはヘッダーやフッターなど、適切なレイアウトを維持したまま自動的に複数分割する ● 小目的 ・MagSite1とりすと亭のプレゼンテーションレイヤーをカスタマイズ可能にし、カスタマイズ可能な拡張性を与える。1ページ上に、MagSite1とりすと亭の機能が混在するような使い方もサポートする ● 目的としないもの ・パーツをフォーム上に並べるようなオーサリングスタイルは基本的に対応しない。シンプルなルールからレイアウトは自動的に生成される。つまり、いわゆるWebデザイナーと呼ばれる人達のかなりの割合は、想定利用者に含まれない。この条件は、コスト低減を実現するために必須要請されるものである。仮に、n個のデバイスとm個のページがあるとき、手動で並べるオーサリングを行うと、最悪n×m個のフォームをデザインしなければならない。これは非現実的な時間とコストを要する可能性が高く、採用することは不可能である。 ・上記の条件から必然的に導かれるものとして、1ピクセルの場所にまでこだわって手動配置された美麗なレイアウトは目的対象外とする ● 実行環境 ・既存Webサーバの管理下にて動作する。Webサーバの種類には、基本的に依存しないが、具体的な個々の実装がどこまで環境に依存するかは不明。とりあえずIISを前提に進めるが、最終的にはApacheでも利用可能であることを実現したい。(実装するかどうかは別として、実装できるようにしたい) ・中間コンテンツ記述言語や、XSLT+CSSによるスタイル記述は、いかなる環境にも中立であり、それを活用する環境の種類は制約されない。 ・プログラムを実行する環境として、.NET Frameworkを想定するが、Unix系OS+Apache+Monoによる実行も可能としたい。また別実行環境(Java等)を想定した実装もあり得るようにしたい。 ● アーキテクチャの概要 ・フレームワーク 全体を統括するプログラム。 主な処理の流れは以下の通り。 1) Webサーバのリクエスト対応して処理を開始する。 2) リクエストされたページのページ構成記述ファイルを読み込む 3) そこに記述されたモジュール群を呼び出し、その結果から中間コンテンツ記述言語の文書を得る 4) リクエスト元デバイスの種類を判別する 5) 判別したデバイスのデバイス定義ファイルを読み込む 6) デバイス定義ファイルに指定された長さを超える場合はコンテンツの分割を行う 7) 中間コンテンツ文書をデバイス定義ファイルが指定するスタイルシート変換に適用し、返送する 8) 終了 ・モジュール リクエストに含まれるパラメータ等を受け取り、中間コンテンツ文書フラグメントを返すプログラム。 当面は、.NET Framework上のアセンブリ(クラスライブラリ)を想定するが、以下の拡張も考えられる。 1) Webサービスによる外部呼び出し (速度的に大丈夫か?) 2) 外部実行プログラム 3) 静的なファイル 4) その他 ・ページ構成記述言語 特定URIに対応するページの構成を記述する言語。 そのページが、どのモジュールから構成されるか。また、それぞれのモジュールの役割(主なコンテンツ、表示できれば良いが無くても良い情報、必須ではあるが別ページに置いても良い情報、等)が記述される。 ・中間コンテンツ記述言語 XHTML Basic+αとして中間コンテンツを記述する。 XHTML Basicから当然求められることではあるが、この言語にプレゼンテーション情報は一切含まれない。 ある一群の要素の役割(主なコンテンツ、表示できれば良いが無くても良い情報、必須ではあるが別ページに置いても良い情報、等)を指定することができる。 ページ分割を行うためのヒントを記述できる。(ここからここまでは分割禁止であるとか、このページはできる限り分割してはならないとか) ・デバイス定義ファイル そのデバイスが1ページあたり受け付けるデータ量について記述できる。物理的な制限について記述する。 そのデバイスが1ページに含めるべき望ましいデータ量について記述できる。PCのWebブラウザなどはかなり大きいデータも受け付けるが、大きすぎるデータを読ませても非現実的なほど重くなる。適切なサイズで切りたい。 そのデバイスに出力するためのスタイルシート変換について指定を行う。(XSLTのファイルのURIを指定?) ● プレゼンテーションのカスタマイズ ・スタイルシート(XSLTとCSS)を書いてデバイス定義ファイルに指定すれば、自由にプレゼンテーションをカスタマイズできる ・1つのModulaF用スタイルシートを記述すると、(それが最善であるかは別として)、全てのModulaFアプリケーションに利用できる ● コンテンツのカスタマイズ ・1つのページに含める情報は、ページ構成記述言語を書き換えることで容易に増減できる ・たとえば、リンク集モジュールがある場合、リンク集はページ内に不用だと思えば、これを取り除くことができる。また、複数のリンク集を持ちたい場合は、リンク集モジュールの異なるインスタンスを指定することができる。 ・モジュールを増減しても、プレゼンテーションのカスタマイズを行う必要はない ● パラメタの疑似名前空間 ・URIのパラメタは1つの名前空間に属する名前で識別されるので、互いに無関係に開発されたモジュールが偶然に同じ名前を参照する可能性があり得る。そこで、疑似名前空間を導入する必要がある ・疑似名前空間は、名前空間識別URI+区切り記号+名前のような形式かなぁ ・しかし、これだとあまりに長すぎて泣けちゃいます。もっと短く一意な名前を得られる手順を用意すべきかも。名前空間接頭辞の導入? ● フォームを含むモジュールの特異性 ・フォームを含むモジュールは、フォームの提示と、それに対するリアクションを、同じモジュールで担当することが望ましいので、それを可能としたい ・フォームを含むページと、フォームからのPOST等を処理するページは、同じではないのだが、そこを関連付ける方法を用意して、上手く連携させたい ・同じページにポストバックすると確実に同じモジュールで処理できるが、1ページ上に複数のモジュールが複数のフォームを提供しているケースがあるので、できれば避けたい。(それとも、そこを上手くハンドリングすれば良いのか?) ・生のフォームをハンドリングするのも面倒なので、そこをラクチンにするための簡単な追加仕様があっても良いのか? (りすと亭をインストールしている人は、拡張子uischemaのファイルを見るとヒントになる?) ● RDBとの自動連係 そういう機能を持ったモジュールを書けばできるでしょう。 ModulaFはXML技術で攻めてみるのが目的なので、RDB対応はその意図に合いません。ですので、こちらではそのようなモジュールを書く予定はありません。 ● オブジェクトとの自動連係 WebとXMLは非オブジェクト指向の世界だと思うので、それをストレートにオブジェクトと連携させることは不可能だと思います。なので、想定外です。 ちなみに、ModulaFという名前は、モジュールである(オブジェクトではない)という意図を明示するためにあえて採用した天の邪鬼なネーミングです。 なお、モジュールが、オブジェクト指向プログラミングで作成されることは何の問題もありません。実際、そう書かれるでしょう。モジュールは、ModulaFアーキテクチャ的にはブラックボックスとして扱われ、中身の構造にまでは関与しません。 ● ライセンス ・詳細未定 ・言語や仕様は自由な利用を解放して、金を取らない方針? ・非商用目的ではフレームワークの実装も無料開放するか? ・いわゆるオープンソースにはしない。GPLにもしない。多少は美味いものが食えるぐらい、こっちにも収入を寄越してもバチは当たらないでしょう。多少美味いものぐらい食えてこそ、良いものを作れます。 ● 課題 ・このアーキテクチャでは、適切なサイズにコンテンツを切ることができない。サイズ判定は、中間コンテンツ文書の段階で行われてしまい、出力文書のサイズで判定されない。 ・生成後に指定サイズを超えていたら、もっと小さなサイズで作り直せ、と指示を出す直す必要があるだろうか ・その場合、ページを切る位置が一意に決まらないので、2ページ目を得るために、1ページ目も生成しないとならないか? もし、100ページ目を得たい時、99ページまで全て生成する必要があるとしたら、現実的な性能が出るのか? 以上 Copyright (C) 2004 Pie Dey Co.,Ltd. |
