(57)【要約】  【課題】  表示画面が小さい等の能力の低い端末にフォームを提供するに際して、ユーザが操作し易く、また入力エラーが起きたときにエラー修正がし易いようなフォームに分割する自動分割アルゴリズムを提供する。  【解決手段】  ユーザが使用するクライアントデバイス５０に適合した形態でフォームの分割表示を行うように表示制御情報を生成するＷｅｂサーバ１０であって、クライアントデバイス５０からのフォーム要求を受信するＨＴＴＰ要求受付部１２と、フォーム要求のあったフォームの画面定義およびフォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを格納するアプリケーションコードＤＢ３１と、取得された端末能力に合わせ、読み出されたフォームの画面定義および検証器のコードを用いてフォームを分割するフォーム分割部２１と、クライアントデバイス５０に表示される画面情報を分割結果から生成する画面生成部２２とを有する。  【選択図】  図１
2005259039.tif 000002
【特許請求の範囲】
【請求項１】
ユーザが使用する端末に適合した形態でフォームの分割表示を行うように表示制御情報を生成する方法であって、
前記端末からフォーム要求を受信するステップと、
前記フォーム要求のあった前記端末の端末能力を取得するステップと、
記憶装置から前記フォーム要求のあったフォームの画面定義および当該フォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを読み出すステップと、
取得された前記端末能力に合わせ、読み出された前記フォームの画面定義および前記検証器を用いて前記フォームを分割するステップと、
分割して得られたサブフォームを前記端末に送信するステップと
を含む表示制御情報生成方法。
【請求項２】
前記分割するステップは、前記検証器と前記入力項目との参照関係を導出し、同一の検証器から参照されている入力項目は同一グループとなるように当該入力項目のグループ分けが行われることを特徴とする請求項１記載の表示制御情報生成方法。
【請求項３】
前記分割するステップは、グループ分けがなされたグループが前記端末能力に基づくサイズ以下か否かを判断し、当該サイズを超えるグループの中で異なる２つ以上の検証器により参照される入力項目をコピーして前記参照関係が修正されることを特徴とする請求項２記載の表示制御情報生成方法。
【請求項４】
前記分割するステップによりグループ分けがなされたグループについて、全ての隣り合うグループを併合した併合結果が前記端末能力を超えるように、当該グループを調整する分割調整ステップを更に備えたことを特徴とする請求項１記載の表示制御情報生成方法。
【請求項５】
前記サブフォームの入力項目に対するユーザの入力を取得し、当該入力項目と参照関係にある前記検証器の状態をユーザに伝達するためのユーザインタフェースを生成するステップを更に備えたことを特徴とする請求項１記載の表示制御情報生成方法。
【請求項６】
ユーザが使用する端末に適合した形態でフォームの分割表示を行うように表示制御情報を生成する方法であって、
記憶装置からフォームの画面定義および当該フォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを読み出し、前記端末の端末能力に合わせて当該フォームを分割するステップと、
分割して得られたサブフォームと共に、前記フォームの各入力項目に対する状態および前記検証器の状態を含む内部状態を表示するための表示ユーザインタフェースを生成するステップと、
生成された前記表示ユーザインタフェースを前記端末に提供するステップと
を含む表示制御情報生成方法。
【請求項７】
前記表示ユーザインタフェースは、分割して得られた特定のサブフォームと前記検証器との対応関係を表示することを特徴とする請求項６記載の表示制御情報生成方法。
【請求項８】
前記表示ユーザインタフェースは、現在表示しているサブフォームの全体に対する位置付けを明示的に表示することを特徴とする請求項６記載の表示制御情報生成方法。
【請求項９】
分割して得られたサブフォームの中で、該当するサブフォームに別のサブフォームへのハイパーリンクを作成するステップを更に備えたことを特徴とする請求項６記載の表示制御情報生成方法。
【請求項１０】
ユーザが使用する端末に適合した形態でフォームの分割表示を行うように表示制御情報を生成するコンピュータであって、
前記端末からのフォーム要求を受信する要求受信手段と、
前記フォーム要求のあったフォームの画面定義および当該フォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを格納する格納手段と、
前記端末のフォーム表示に関する端末能力を取得する端末能力取得手段と、
前記端末能力取得手段により取得された前記端末能力に合わせ、前記格納手段から読み出された前記フォームの画面定義および前記検証器のコードを用いて当該フォームを分割する分割手段と、
前記分割手段による分割結果を用いて前記端末に表示される画面情報を生成する画面生成手段と
を有するコンピュータ。
【請求項１１】
前記分割手段は、分割後の１ページのサイズが前記端末の画面サイズおよび当該端末の受信バッファの制限による上限を超えないように前記フォームを分割することを特徴とする請求項１０記載のコンピュータ。
【請求項１２】
前記分割手段は、１つの検証器が参照する入力項目は２つ以上の分割フォームに属しないように前記フォームを分割することを特徴とする請求項１０記載のコンピュータ。
【請求項１３】
前記分割手段は、前記フォームの分割個数が最小となるように当該フォームを分割することを特徴とする請求項１２記載のコンピュータ。
【請求項１４】
前記分割手段は、前記フォームを分割してサイズが最大となるページについて分割方法ごとにサイズを比較し、当該ページのサイズが最小となる分割方法にて当該フォームを分割することを特徴とする請求項１２記載のコンピュータ。
【請求項１５】
前記画面生成手段は、前記分割手段により分割して得られたサブフォームと共に、前記フォームの各入力項目の状態、および前記検証器の状態を含む内部状態を表示する画面情報を生成することを特徴とする請求項１０記載のコンピュータ。
【請求項１６】
コンピュータに、
フォーム要求のあった端末の端末能力を取得する機能と、
記憶装置から前記フォーム要求のあったフォームの画面定義および当該フォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを読み出す機能と、
取得された前記端末能力に合わせ、読み出された前記フォームの画面定義および前記検証器を用いて前記フォームを分割する機能と
を実現させ、ユーザが使用する端末に適合した形態でフォームの分割表示を行うように前記コンピュータを機能させるプログラム。
【請求項１７】
前記フォームを分割する機能は、前記検証器と前記入力項目との参照関係を導出し、同一の検証器から参照されている入力項目は同一グループとなるように当該入力項目のグループ分けが行われることを特徴とする請求項１６記載のプログラム。
【請求項１８】
前記フォームを分割する機能は、グループ分けがなされたグループが前記端末能力に基づくサイズ以下か否かを判断し、当該サイズを超えるグループの中で異なる２つ以上の検証器により参照される入力項目をコピーして前記参照関係が修正されることを特徴とする請求項１７記載のプログラム。
【請求項１９】
コンピュータに、
記憶装置からフォームの画面定義および当該フォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを読み出し、フォーム内容を出力する端末の端末能力に合わせて当該フォームを分割する機能と、
分割して得られたサブフォームと共に、前記フォームの各入力項目に対する状態および前記検証器の状態を含む内部状態を表示するための表示ユーザインタフェースを生成する機能と
を実現させ、ユーザが使用する端末に適合した形態でフォームの分割表示を行うように前記コンピュータを機能させるプログラム。
【請求項２０】
分割して得られたサブフォームの中で、該当するサブフォームに別のサブフォームへのハイパーリンクを作成する機能を更に備え、
前記表示ユーザインタフェースを生成する機能は、作成された前記ハイパーリンクを前記内部状態の表示に適用させることを特徴とする請求項１９記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザが使用する端末に適合した形態で文書等の表示を行うための制御命令を生成する方法及び機構に関する。
【背景技術】
【０００２】
Ｗｅｂベース技術の浸透に伴い、ユーザインタフェースとしてＷｅｂブラウザを用い、アプリケーション本体はＷｅｂサーバ(アプリケーション・サーバ)で稼働させるような、いわゆるシン(thin)クライアント型のシステムが利用されている。このとき、サーバからクライアントに送られる情報はフォームを含むＨＴＭＬ文書、ＯＭＡ(Open Moblie Aliece; http://www.openmobilealliance.org/)が標準と定めるＷＭＬ、ＨＴＭＬのサブセットとなる言語であるCompactＨＴＭＬ等であり、クライアントの端末では、Ｗｅｂブラウザさえ動けば、実行に先立ってアプリケーションの配布・インストール等の作業を特に行うことなく、アプリケーションを実行させることができるようになる。また、一般的には、クライアント側でアプリケーションを実行するのに比して、クライアント側はより処理能力の低いハードウェアで運用することができる。
【０００３】
かかるクライアント端末には、従来、ローエンドのＰＣが用いられてきた。しかし、最近では、更に処理能力の低く且つ低コストであるＰＤＡ(Personal Digital Assistants)、ハンドヘルドＰＣ、セット・トップ・ボックス、カーナビゲーション・システム等でもＷｅｂブラウザが動くようになってきている。また、Ｗｅｂブラウザ機能を有する携帯電話のような新しい端末機器も開発されている。そのため、例えば、広い表示領域を有するＰＣではうまく表示されていたＷｅｂページが、より狭い表示領域を有するＰＤＡでは頻繁なスクローリング操作を必要とする等、使い勝手が非常に悪くなってしまう。そこで、従来技術として、フォームを含むＷｅｂ画面をデバイスに依存しない階層構造記述から各種端末画面に最適化するデータ構造と、そのアルゴリズムを提供する技術が存在する(例えば、特許文献１、特許文献２、および特許文献３参照。)。
【０００４】
また、他の従来技術として、制約記述システムを用いることにより入力フィールドの一部が入力された時点(分割フォームのページが切り替わった時点)で、対応する検証器を動作させるものが存在する(例えば、特許文献４参照。)。
【０００５】
【特許文献１】特許第３２０２９６８号公報
【特許文献２】特開２０００−１９４６１２号公報
【特許文献３】特開２０００−７６４７３号公報
【特許文献４】特開平９−２０４２８５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
この特許文献１、特許文献２、および特許文献３などに記載の従来の方法は、アプリケーション作成時にデバイス非依存の記述として画面の論理的構造が適切に指示されていれば、フォームも適切な構造に変換することができる。しかしながら、アプリケーションに存在する検証器に関しては考慮されていない。そのために、分割ページ間の遷移時にサーバとの通信をするにもかかわらず、サブミット(Submit)ボタンを最後に押すまではフォームの検証器が作動せず、使い勝手の点で問題が残る。また、検証器がエラーを発見したとしても分割画面の最初から(あるいはインデックスページから)表示を行うため、エラーの発生した箇所を直ぐに表示することができず、修正に手間取り、使い勝手が悪くなる。更に、画面作成においてグループ化などの構造が記述されていなければ，当然に適切な分割をすることができない。
【０００７】
また、上記特許文献４では、分割フォームのページが切り替わった時点で対応する検証器を動作させることができる。しかしながら、フォームの分割の仕方に関して、入力フィールド間の関係や検証器のことは全く考慮されておらず、例えば、州・県、都市、町名入力フィールドのように、意味的につながり(あるいは、同時に検証器で検証されるようなもの)がある場合であっても、別の画面に分割されてしまう可能性がある。このため、これらのページでフォームデータを入力して画面を遷移しても検証器が作動しない。更に、一時に関係する入力データが全部は見えないので、入力時にユーザが戸惑い、また、検証器によりエラーが発見されたときに修正画面が分割されて使い難くなる。
【０００８】
ここで、入力値の検証器を持つＷｅｂフォームとは、Ｗｅｂアプリケーションにおける処理を伴う入力画面で、入力項目(入力フィールド)に対して各種の検証器を持ち、ユーザがSubmitボタンで処理を要求し、かつ、全ての検証が完了した場合(全ての検証器がＯＫという返事を返す場合)、フォームに用意された処理を実行するというものである。これらの検証器が１つでもＮＧを返した場合、フォームの処理は行われずユーザに適切なエラーが返され、ユーザに修正を求める。
例えば検証器としては、各入力フィールドの値のタイプ(数値やe-mailアドレス形式)をチェックするような単一フィールドを調べるものや、複数の値の間の制約をチェックするようなもの、更には、ユーザの入力が行われたかどうかをチェックするものなどがある。検証器は、サーバで実行されるプログラムコードや、端末上で実行されるＷｅｂ文書上のスクリプトプログラムとして与えられる。
【０００９】
このようなフォーム(Ｗｅｂフォーム)で特に複雑な入力画面を画面サイズの異なる端末に表示する場合、適切に分割する必要がある。ここで、適切な分割としては、まず、ユーザの入力時に端末の画面サイズやユーザインタフェースに合わせて操作し易い分割であること、また、入力エラーが起きたときにエラー修正がし易いような分割にすることが挙げられる。より具体的には、分割された画面間を移動した時点で検証器が作動しその画面で入力した情報が直ぐに検証されること、検証器によりエラーが発見された場合は対応するページにアクセスし易いこと、更には、検証が通る可能性があるときのみフォーム入力のSubmitボタンが押せるように、検証器で必ずエラーになると解っているときは押せないようすることが挙げられる。
【００１０】
例えば、ユーザＩＤとパスワードとのフィールドを持つようなログイン画面を考えると、ユーザＩＤとパスワードとのフィールドが別々の画面に分割された場合には、明らかにユーザは戸惑うことになる。パスワードを入力しているときに、別の画面で入力したユーザＩＤをその場で確認することができないからである。また、ログインがエラーになった場合、ユーザＩＤが間違っている場合とパスワードが間違っている場合の２通りが考えられるが、これらのフィールドが分割された画面に存在すると、エラー時にはどちらかのページしか表示できないのでユーザに余計なページめくりをさせることになる。別の例としては、住所(県・州、都市名、町名)、電話番号、会社名など、非常に多くの入力項目を持つフォームを分割する場合を考えると、このような多様な情報の入力において、ユーザは自由に入力項目の間を行き来して入力していくのが自然と思われる。このとき、入力が完了してSubmitする場合に、必ずしもSubmitボタンがある最後のページにいるとは限らず、ユーザにとっての使い勝手が悪い。また、全てのページにSubmitボタンを付けてしまうと、全ての入力が終わってないのにSubmitが行われる可能性があり、不要なエラー処理の実行やエラー画面をユーザに見せることになり好ましくない。
【００１１】
ここで、互いに関係を持つような複雑で入力項目の多いＷｅｂフォームを携帯電話のような小画面に分割する場合、上述した使い勝手を考えると、次のような条件を満たす必要がある(分割の必要条件)。
(条件１)
分割後の１ページのサイズは、端末の画面サイズ・受信バッファの制限による上限を超えることができない。
(条件２)
１つの検証器が参照する入力フィールドは２つ以上の分割フォームに属しない。
【００１２】
更に、ユーザにとって好ましい状況を考えると、次の２条件も満たすことが望ましい。
(条件３)
条件２を満たす分割のうち分割の個数が最小になる。
(条件４)
条件２を満たす分割のうちサイズが最大となるページを比較し、そのサイズが最小になる。即ち、分割されたグループ同士の大きさのバランスがとれている。
【００１３】
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的とするところは、互いに関係を持つような複雑で入力項目の多いＷｅｂフォームを例えば携帯電話のような小画面に分割して提供する際に、フォーム要素の分割に合わせた検証コードの分割とその実行を可能とすることにある。
また他の目的は、様々な能力を持つ任意の端末に対して柔軟に対応できるように、例えば上記の４条件を満たすような自動分割アルゴリズムを提供することにある。即ち、フォームをこのように分割したり、例えば分割フォームのページテンプレートをデザイン時に予め生成したりする場合に、実行時のフィールドの入力状況や各検証器の完了状態の表示、Submitボタンの自動配置を動的に行うことが望ましい。
更に他の目的は、端末の画面サイズやユーザインタフェースに合わせ、ユーザが操作し易く、および入力エラーが起きたときにエラー修正がし易いようなフォームに分割する自動分割アルゴリズムを提供することにある。
また更に他の目的は、検証器の状態表示やSubmitボタンを付加するような分割フォーム画面の自動生成方法を提供することにある。
【課題を解決するための手段】
【００１４】
かかる目的のもと、本発明は、分割された画面間を移動した時点で可能な限り検証器が作動し、その画面で入力した情報が直ぐに検証されること、検証器によりエラーが発見された場合は対応するページにアクセスし易いこと、更には、検証が通る可能性があるときにフォーム入力のSubmitボタンが押せるようになっていること等、各種端末画面に応じて最適化するデータ構造とアルゴリズムを提供している。即ち、本発明は、ユーザが使用する端末に適合した形態でフォームの分割表示を行うように表示制御情報を生成する方法であって、端末からフォーム要求を受信するステップと、フォーム要求のあった端末の端末能力を取得するステップと、記憶装置からフォーム要求のあったフォームの画面定義およびフォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを読み出すステップと、取得された端末能力に合わせ、読み出されたフォームの画面定義および検証器を用いてフォームを分割するステップと、分割して得られたサブフォームを端末に送信するステップとを含む。
【００１５】
ここで、この分割するステップは、検証器と入力項目との参照関係を導出し、同一の検証器から参照されている入力項目は同一グループとなるように入力項目のグループ分けが行われることを特徴とすることができる。また、この分割するステップは、グループ分けがなされたグループが端末能力に基づくサイズ以下か否かを判断し、このサイズを超えるグループの中で異なる２つ以上の検証器により参照される入力項目をコピーして参照関係が修正されることを特徴とすることができる。
【００１６】
ここで、この分割するステップによりグループ分けがなされたグループについて、全ての隣り合うグループを併合した併合結果が端末能力を超えるように、グループを調整する分割調整ステップを更に備えたことを特徴とすれば、分割の個数を最小にすることができる点で好ましい。また、このサブフォームの入力項目に対するユーザの入力を取得し、入力項目と参照関係にある検証器の状態をユーザに伝達するためのユーザインタフェースを生成するステップを更に備えたことを特徴とすれば、ユーザの操作性を更に向上させることができる点で優れている。
【００１７】
他の観点から捉えると、本発明が適用される表示制御情報生成方法は、記憶装置からフォームの画面定義およびフォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを読み出し、端末の端末能力に合わせてフォームを分割するステップと、分割して得られたサブフォームと共に、フォームの各入力項目に対する状態および検証器の状態を含む内部状態を表示するための表示ユーザインタフェースを生成するステップと、生成された表示ユーザインタフェースを端末に提供するステップとを含む。
【００１８】
ここで、この表示ユーザインタフェースは、分割して得られた特定のサブフォームと検証器との対応関係を表示することを特徴とすることができる。例えば、対応関係がわかるように各検証器を関係のあるサブフォームに対応する領域に分けて表現する等である。また、現在表示しているサブフォームの全体に対する位置付けを明示的に表示することを特徴とすることができる。更に、分割して得られたサブフォームの中で、該当するサブフォームに別のサブフォームへのハイパーリンクを作成するステップを備えたことを特徴とすれば、分割された画面に対してユーザが直接的に操作できる点からも好ましい。
【００１９】
一方、本発明は、ユーザが使用する端末に適合した形態でフォームの分割表示を行うように表示制御情報を生成するコンピュータであって、端末からのフォーム要求を受信する要求受信手段と、フォーム要求のあったフォームの画面定義およびフォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを格納する格納手段と、端末のフォーム表示に関する端末能力を取得する端末能力取得手段と、この端末能力取得手段により取得された端末能力に合わせ、格納手段から読み出されたフォームの画面定義および検証器のコードを用いてフォームを分割する分割手段と、この分割手段による分割結果を用いて端末に表示される画面情報を生成する画面生成手段とを有する。
【００２０】
ここで、この分割手段は、分割後の１ページのサイズが端末の画面サイズおよび端末の受信バッファの制限による上限を超えないようにフォームを分割すること、または、１つの検証器が参照する入力項目は２つ以上の分割フォームに属しないようにフォームを分割することを特徴とすることができる。加えて、フォームの分割個数が最小となるようにフォームを分割すること、フォームを分割してサイズが最大となるページについて分割方法ごとにサイズを比較しページのサイズが最小となる分割方法にてフォームを分割すること、を特徴とすることができる。
更に、この画面生成手段は、分割手段により分割して得られたサブフォームと共に、フォームの各入力項目の状態、および検証器の状態を含む内部状態を表示する画面情報を生成することを特徴とすることができる。
【００２１】
また本発明は、Ｗｅｂサーバ等の各種コンピュータにて実行されるプログラムとして把握することができる。このプログラムは、コンピュータに、フォーム要求のあった端末の端末能力を取得する機能と、記憶装置からフォーム要求のあったフォームの画面定義およびフォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを読み出す機能と、取得された端末能力に合わせ、読み出されたフォームの画面定義および検証器を用いてフォームを分割する機能とを実現させ、ユーザが使用する端末に適合した形態でフォームの分割表示を行うようにコンピュータを機能させる。
【００２２】
ここで、このフォームを分割する機能は、検証器と入力項目との参照関係を導出し、同一の検証器から参照されている入力項目は同一グループとなるように入力項目のグループ分けが行われることを特徴とすることができる。また、このフォームを分割する機能は、グループ分けがなされたグループが端末能力に基づくサイズ以下か否かを判断し、サイズを超えるグループの中で異なる２つ以上の検証器により参照される入力項目をコピーして参照関係が修正されることを特徴とすることができる。
【００２３】
他の観点から捉えると、本発明が適用されるプログラムは、コンピュータに、記憶装置からフォームの画面定義およびフォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを読み出し、フォーム内容を出力する端末の端末能力に合わせてフォームを分割する機能と、分割して得られたサブフォームと共にフォームの各入力項目に対する状態および検証器の状態を含む内部状態を表示するための表示ユーザインタフェースを生成する機能とを実現させ、ユーザが使用する端末に適合した形態でフォームの分割表示を行うようにコンピュータを機能させる。
ここで、分割して得られたサブフォームの中で、該当するサブフォームに別のサブフォームへのハイパーリンクを作成する機能を更に備え、表示ユーザインタフェースを生成する機能は、作成されたハイパーリンクを内部状態の表示に適用させることを特徴とすることができる。
【発明の効果】
【００２４】
本発明によれば、表示画面が小さい等の能力の低い端末にフォームを提供するに際して、ユーザが操作し易く、また入力エラーが起きたときにエラー修正がし易いようなフォームに分割するための自動分割アルゴリズムを提供することができる。
【発明を実施するための最良の形態】
【００２５】
以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
図１は、本実施の形態が適用されるフォーム自動分割システムの構成を示した図である。アプリケーション実行時のシステム構成は、ネットワーク４０で接続されたＷｅｂサーバ１０と端末である各種のクライアントデバイス５０からなる。
クライアントデバイス５０は、画面サイズやメモリ容量など能力が様々に異なるが、Ｗｅｂサーバ１０にＷＷＷ文書を要求しそれを受け取って処理をすることのできるＷＷＷブラウザ５１を内蔵している。
ネットワーク４０は、インターネットなど、公的、広域的なネットワークでもローカルなネットワークでもよい。
【００２６】
一方、Ｗｅｂサーバ１０は、分割フォーム実行制御部１１とＨＴＴＰ要求受付部１２とを備えている。また、ハードディスクドライブ(ＨＤＤ)等の記憶装置に格納される各種データベース(ＤＢ)として、アプリケーションコードＤＢ３１、デバイス情報ＤＢ３２、分割フォームＤＢ３３を備えている。また、分割フォーム実行制御部１１の作業用メモリとして、ＲＡＭ等から構成されるワーキングメモリ３４を備えている。
ＨＴＴＰ要求受付部１２は、分割フォーム(サブフォーム)に関する以外の要求の処理コード(標準的Ｗｅｂサーバの機能やアプリケーションのロジック実行など)も含む。一方、分割フォーム実行制御部１１は、フォーム分割・生成部２０をサブシステムとして備え、アプリケーション実行コードや分割済みフォーム(分割フォーム)を入力として、クライアントデバイス５０からの要求に応じて分割されたフォームの実行を制御している。その際、フォームおよびその各入力フィールドや検証器の状態を一時的に保存するためにワーキングメモリ３４を使用している。
【００２７】
Ｗｅｂサーバ１０にて実行されるＷｅｂアプリケーションは、画面定義と処理コードとの集まりからなる。特にフォーム処理に関しては、フォーム画面定義、入力の検証器コード(検証器)、およびフォーム処理コードから構成される。これらは、Ｗｅｂアプリケーション開発者によって作成され、図１に示すフォーム自動分割システムに入力されるものである。尚、例えば、未入力チェック、文字列の長さ、入力値のタイプチェック等、明示的に検証器のコードが与えられていない場合もあるが、本実施の形態では、そのような場合も明示的なコードが利用可能として考えている。
尚、本実施の形態において、入力値の検証器を持つフォーム(Ｗｅｂフォーム)とは、Ｗｅｂアプリケーションにおける処理を伴う入力画面で、入力項目(入力フィールド)に対して各種の検証器を持ち、クライアントデバイス５０のユーザがSubmitボタンで処理を要求し、かつ、全ての検証が完了した場合(全ての検証器がＯＫという返事を返す場合)、フォームに用意された処理を実行するというものである。これらの検証器が１つでもＮＧを返した場合、フォームの処理は行われずユーザに適切なエラーが返され、ユーザに修正を求める。
また、検証器(検証器コード)は、各入力フィールドの値のタイプ(数値やe-mailアドレス形式)をチェックするような単一フィールドのチェック、複数の値の間の制約チェック、ユーザの入力が行われたかどうかのチェック等を行う。これらの検証器は、Ｗｅｂサーバ１０で実行されるプログラムコードやクライアントデバイス５０上で実行されるＷｅｂ文書上のスクリプトプログラムとして与えられる。
【００２８】
フォーム分割・生成部２０は、分割フォーム実行制御部１１によって制御され、必要な場合は、記憶装置であるアプリケーションコードＤＢ３１から(分割前の)フォーム定義(フォーム画面定義)、検証器コード、およびフォーム処理コードを読み込み、分割されたフォームを分割フォームＤＢ３３に出力している。その際、ターゲットとなるデバイス情報をデバイス情報ＤＢ３２から読み出して使用し、端末の能力に合わせて分割を行っている。フォーム分割・生成部２０の更なるサブシステムとして、フォーム内の項目を分割するフォーム分割部２１と、分割されたフォームからページを生成する画面生成部２２が存在する。尚、このフォーム分割・生成部２０は、実行時のみならず、アプリケーション開発時に動作して予め分割済みフォームを生成しておくように構成することもできる。
【００２９】
フォーム分割部２１は、各フォームの画面定義、フォーム内のフィールド(入力フィールド)に入力された入力値の検証を実行する検証器(例えば，Ｊａｖａ言語で記述される)を入力として、対象とする端末(クライアントデバイス５０)の能力に合わせて、与えられたフォームを分割している。フォームの画面定義は、例えば、XForms (http://www.w3c.org/TR/xforms)のようなＸＭＬ言語で記述されてもよいし、端末で直接実行可能なＨＴＭＬのようなマークアップ言語で記述されていてもよい。尚、「Ｊａｖａ」およびそれに関連する名称は商標または登録商標である。本明細書において、個別の記載は省略する。
【００３０】
画面生成部２２は、フォーム分割部２１の分割結果(後で述べるように入力項目のグループとして表現される)を入力として、対象とする端末(クライアントデバイス５０)のＷｅｂページテンプレート(例えば、ＪＳＰ(Java Server Pages)ファイル)を生成する。フォーム分割部２１と画面生成部２２は、端末の能力が予め判っていれば、Ｗｅｂアプリケーションの設計・開発時に動作してもよく、またアプリケーション実行時に動的に動作しても構わない。
【００３１】
分割フォーム実行制御部１１は、分割されたフォームのＷｅｂページテンプレートと検証器のコード、およびフォーム処理コードを入力として、アプリケーション実行時にユーザ(クライアントデバイス５０)との対話処理を行い、必要なコードを呼び出している。この分割フォーム実行制御部１１およびサブシステムであるフォーム分割・生成部２０は、Ｗｅｂサーバ１０上で動作するプログラム(例えば、Ｊ２ＥＥ(Java2 Enterprise Edition)のServletコード)である。また、フォームの分割を実際に要求が行われた時点で動作させるようにする場合は、フォーム分割部２１および画面生成部２２も同様にＷｅｂサーバ１０上で動作する。
【００３２】
ここで、Ｗｅｂサーバ１０のハードウェア構成について説明する。
図２は、本実施の形態が適用されるＷｅｂサーバ１０や各種クライアントデバイス５０を実現するのに好適なコンピュータ装置のハードウェア構成例を模式的に示した図である。但し、クライアントデバイス５０として携帯電話等の簡易なコンピュータ装置を使用する場合には、適宜、構成要素が省略される。
図２に示すコンピュータ装置は、演算手段であるＣＰＵ(Central Processing Unit：中央処理装置)１０１と、Ｍ/Ｂ(マザーボード)チップセット１０２およびＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ/Ｂチップセット１０２およびＡＧＰ(Accelerated Graphics Port)を介してＣＰＵ１０１に接続されたビデオカード１０４とを備えている。また、ＰＣＩ(Peripheral Component Interconnect)バスを介してＭ/Ｂチップセット１０２に接続された磁気ディスク装置(ＨＤＤ)１０５、ネットワークインタフェース１０６と、更にこのＰＣＩバスからブリッジ回路１０７およびＩＳＡ(Industry Standard Architecture)バスなどの低速なバスを介してＭ/Ｂチップセット１０２に接続されたフレキシブルディスクドライブ１０８およびキーボード/マウス１０９とを備える。
【００３３】
尚、図２は、本実施の形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としてもよいし、外部記憶装置として、ＡＴＡ(AT Attachment)やＳＣＳＩ(Small Computer System Interface)などのインタフェースを介してＣＤ−Ｒ(Compact Disc Recordable)やＤＶＤ−ＲＡＭ(Digital Versatile Disc Random Access Memory)などのドライブを設けてもよい。
【００３４】
次に、ＣＰＵ１０１にて実行される機能である、分割フォーム実行制御部１１、フォーム分割・生成部２０、およびフォーム分割部２１および画面生成部２２の処理動作について詳述する。
まず、分割の前提として、本実施の形態では４つからなる「分割の必要条件」に基づいて処理が実行される。前述の記載と重複するが、ここに記載する。
「条件１」
分割後の１ページのサイズは、端末(クライアントデバイス５０)の画面サイズ・受信バッファの制限による上限を超えることができない(物理的な制限。必ず満たす必要がある強い制約)。
「条件２」
１つの検証器が参照する入力フィールドは２つ以上の分割フォームに属しない(条件１によりそのままではこの条件を満たせない場合があるが、入力項目や検証器をコピーして置き換えることにより解決する)。
「条件３」
条件２を満たす分割のうち分割の個数が最小になる(実用上は最小の近似でもよい)。
「条件４」
条件２を満たす分割結果が複数ある中で、その分割結果ごとにサイズが最大となるページのサイズ同士を比較し、そのサイズが最小となる分割結果を選ぶ。即ち、分割されたグループ同士の大きさのバランスがとれている(実用上は最小の近似でもよい)。
【００３５】
ここで、フォーム内の入力項目(入力フィールド)は、各々独立とは限らず意味的なつながりを持っていることが多いことから、そのつながりを反映した分割にすることが望ましい。また、これらの意味的なつながりは、ある一つの検証器がその関係する入力値を参照することで推定する。更に、検証器に対応した形でフォームを分割しておくと、エラーが発生した場合に、（１）ユーザにとってどこでエラーが起きたのかが判りやすい。（２）エラーが起きた場所にユーザをナビゲートし易い。という利点がある。また更に、各検証器に対応して検証結果を分割された画面上に表示し、更に直接的な操作が可能なように結果表示をハイパーリンクにすることも可能である。これにより、ユーザの操作性を向上させることができる。
Submitボタンは、そのページの入力完了により全ての検証器の検証が完了する可能性があるときのみ自動的に配置することが好ましい。このSubmitボタンが配置できるのは、そのページに関係しない検証器が完了しており、そのページに関係する検証器がそのページの入力により動作可能であることが条件になる。検証器が動作可能とは、その入力項目の値が参照可能(ユーザによる入力済み、または事前設定済み)になっていることである。
【００３６】
図３は、フォーム分割から、分割されたフォームの実行制御をするまでの全体のフローチャートを示した図である。フォーム処理として、まずステップ１では、対象とする端末(クライアントデバイス５０)からのフォーム要求を受け付ける。また、端末能力が取得され、特定される。この端末能力の取得・特定は、実行時に動的に行う場合は、端末からの識別情報(例えばＨＴＴＰのUser-Agentヘッダ情報)を用いてリポジトリを検索するなどして行われる。または、ＯＭＡ(Open Mobile Alliance)のＵＡＰｒｏｆ(User Agent Profile)などの標準規格によって端末から直接端末能力を取得する場合もある。更に、Ｗｅｂサーバ１０では、内部状態の初期化が行われる。
【００３７】
次に、ステップ２ではフォームの分割とサブフォームページ(Ｗｅｂページテンプレート)の生成が行われる。このステップ２の処理は、設計開発時に予め実行しておくこともできる。このステップ２の処理は、図４以降にて詳述する。
その後、ステップ３では、生成されたサブフォームページ(Ｗｅｂページテンプレート)から実際の画面文書(該当ページ(サブフォーム)、例えば、対象とする端末で扱えるＨＴＭＬ文書やＷＭＬ文書などのマークアップ言語による文書)を生成して端末(クライアントデバイス５０)に返信する。そして、サブフォームを取得した端末(クライアントデバイス５０)のユーザによって、各種のフォーム入力作業が実行される。例えば、分割されたフォームを受け取り、入力処理を行って別のページにジャンプしたり、可能な場合はSubmitボタンを押してフォーム処理を要求したりする。
【００３８】
ステップ４では、ユーザからの処理要求を端末(クライアントデバイス５０)から受け取る。ここで受け取る処理要求は、主としてフォームの入力項目の値を取得することと、サブミット(Submit)や別ページへのナビゲーション処理の判別である。また、セキュリティや認証などの必要な処理もここに含まれる。
ステップ５では、対応する検証器の呼び出しがなされ、内部状態が更新される。この内部状態とは、例えば、フォームの各入力項目に対する状態(未入力、入力済み、事前指定済み)と、実際に入力された値、各検証器の状態(ＯＫかＮＧ、または未検証)、および現在実行中の分割フォームページである。これらの内部状態はステップ１にて初期化されている。内部状態の更新では、入力された項目に対応する入力項目の内部状態が変更される。更に、各検証器の参照する全ての入力項目が参照可能(未入力でない状態)になったら検証器を動作させ、それぞれの検証器状態が更新される。更に、画面ナビゲーションの要求があれば、現在ページも指定されたとおりに更新される。
【００３９】
ステップ６では、ステップ５にて更新された内部状態をユーザに適切に伝達するためのユーザインタフェースを動的に生成する。このステップの処理は、図７にて詳述する。
その後ステップ７で、全ての必須入力項目が入力されかつ検証されたか否かが判断される。即ち、Submitボタンが押された場合に、全ての必須入力項目が入力され検証器の状態がＯＫになったか否かを調べ、条件を満たした場合にステップ８に進む。条件を満たしていない場合には、ステップ３へ戻り、ユーザとの対話処理が繰り返される。
ステップ８では、与えられたフォーム処理が実行される。図３に示すこのフローチャートでは省略されているが、ここでエラーが出た場合にエラー処理としてステップ３に戻ることも考えられる。正常に処理が終了した場合、与えられたフォームの処理を終了する。尚、Ｗｅｂアプリケーションの場合、複数のフォーム処理が組み合わされて実行される場合も多く、かかる場合には図３に示す処理全体を繰り返すことになる。
【００４０】
次に、ステップ２に示したフォームの分割・生成処理について説明する。
図４は、フォームの分割・生成処理の全体の流れを示したフローチャートである。
ここでは、まず、検証器(検証器コード)と入力項目(入力フィールド)との参照関係が導出される(ステップ２.１)。即ち、検証器のプログラムコードが解析され、検証器から参照される入力項目フィールドが明らかにされる。このような参照関係は、コンパイラ技術(コード分析、データフロー分析)、プログラムスライシングなどの従来技術を用いて求めることができる。実用上、プログラム文字列のパターンマッチで近似的に解析するだけでも問題ないことが多い。尚、検証器と入力項目フィールドの参照関係は、アプリケーション実行前に事前に求めておくことも可能である。
【００４１】
その後、フォーム分割・生成部２０のフォーム分割部２１にて、入力項目の分割がなされる(ステップ２.２)。ここでは、画面サイズ等で決まる所定の大きさ以下になるように入力項目グループの分割がなされる。この分割処理は図５を用いて詳述する。
また、フォーム分割部では、ステップ２.２の分割結果が適切になるように、更に調整がなされる(ステップ２.３)。具体的には、必要に応じて、適切な画面の大きさになるように小グループ同士が併合され、かつ、ステップ２.２で分割ができなかったグループについて、物理的制約による画面サイズを超えるものが分割される。この分割調整は図６を用いて詳述する。尚、与えられた端末(クライアントデバイス５０)の画面サイズは、画面の表示能力(表示内容のレンダリング後の縦・横ピクセルサイズ)や送信文書の文字数による受信バッファの最大容量などで定義される。実際は、レンダリング結果をＷｅｂサーバ１０側で知ることが困難であったり、動的な結果を返信文書に含むため、送信文書の正確な文字数を知ることが困難であったりする場合がある。このために、これらの近似となるような別の評価基準を用いることもできる。例えば、分割後のページに含まれる入力項目の個数(更に、入力フィールドのタイプによって重みを付けることもできる)を、このようなサイズとして使用することも有効である。
【００４２】
そして最後に、サブフォームの生成がなされる(ステップ２.４)。即ち、得られた分割結果を端末(クライアントデバイス５０)で表示できるような表現形式の文書に変換する作業がなされる。かかる作業では、端末に合わせてコンテンツの適切なコーディング変換が実行され、クライアントデバイス５０のＷＷＷブラウザ５１にて解釈できるマークアップ言語の文書に分割結果が変換される。
このステップ２.３やステップ２.４で行われる分割や変換などの端末適応処理は、上述した特許文献１などの既存技術で実行することができる。尚、これらの変換文書は、実行処理時の動的な情報(エラー情報や入力状態の表示、動的に表示されるSubmitボタン)を含むことから、最終的な画面文書ではなく動的な情報を含むことのできるテンプレート文書である。このようなテンプレート文書としてＪＳＰ(Java Server Pages)やＡＳＰ(Active Server Pages)、ＰＨＰ(Hypertext Preprocessor)などがある。
【００４３】
図５は、図４のステップ２.２による入力項目の分割処理を詳述したフローチャートであり、検証器(検証器コード)から入力項目(入力フィールド)への参照情報を用いたフォーム入力項目グループの分割アルゴリズムを示している。
ここでは、まず、同一の検証器から参照されている入力項目は同一グループとなるように入力項目のグループ分けがなされる(ステップ２.２.１)。即ち、任意の入力項目ＡとＢに対しＡとＢの両方を参照するような検証器Ｖが１つでも存在するときはＡとＢは同じグループに入れる。かかるアルゴリズムの例としては、最初は１項目１グループとし、全ての検証器を順に調べ、上記の条件を満たす場合(２つ以上のグループを参照する場合)は、参照するグループを合わせて１つのグループにしていくようなものが考えられる。
【００４４】
ここで、全てのグループが端末能力に基づくサイズ以下になったか否か、または、これ以上分割不可か否かが判断される(ステップ２.２.２）。即ち、ステップ２.２.１で作成されたグループ(先に述べた「分割の必要条件」の「条件２」を満たすもの)が、先に述べた「条件１」も満たしているか否かがチェックされる。もしも満たされていれば、ステップ２.２における入力項目の分割を行うサブルーチンは終了する。ここで、端末によって決定されるサイズを超えるようなものがあれば、まずサイズを超えるようなグループが１つ選択され(ステップ２.２.３）、更にそのグループの中から、異なる２つ以上の検証器から参照されるような入力項目からできるだけ最適なものが１つ選択される(ステップ２.２.４）。尚、最適なものを選択する方法については後述する。
【００４５】
次に、選択した入力項目(入力フィールド)を２つにコピーする。このとき、コピー元のフィールドとコピー先のフィールドとは異なる検証器から独立して参照されるように参照関係が付け直される。即ち、選択された入力項目を、参照する検証器から共有されないように２つにコピーし、参照関係が修正される(ステップ２.２.５）。３つ以上の検証器から参照されている場合は、このコピーの方法も複数考えられるが、かかる選択方法についても後述する。その後、選択されたグループのサブグループへの分割が行われる。即ち、この入力項目がコピーされたグループを新たな入力として、ステップ２.２が再帰的に呼び出される(ステップ２.２.６）。そして、選択されたグループのサブグループへの分割を、与えられたグループの分割として適用し、即ち、出力結果の分割を現在の分割に適用して(ステップ.２.７）、ステップ２.２.１に戻る。但し、分割するためにコピーできる入力項目がこれ以上なくなった場合もループを終了する(ステップ２.２.２）。
【００４６】
また、ステップ２.２.４における選択において、最適なものが１つ選択されるが、これは、先に述べた「分割の必要条件」に示す「条件３」と「条件４」とを満たすことである。そこで、正確に求めるには、全ての複数の検証器から参照される入力項目に対し、ステップ２.２.５およびステップ２.２.６の処理(コピーと参照関係の修正方法)を試行して、分割個数とそのときのサブグループの最大サイズを記録する。また次の試行をする前にコピーや参照関係の変更を元に戻しておく。そして全ての試行が終了した際に、最小の分割数になるもの(入力項目とコピーの仕方)を選択する。この最小の分割数になる場合が複数ある場合には、更にサブグループの最大サイズが最小のものを選択する。それも複数ある場合には、任意の１つを選べばよい。例えば、最初に出てくる入力項目を無条件に選ぶ等である。より実用的には、ステップ２.２.３で最大のサイズのグループを選択する(複数ある場合は任意のものでよい)。その中で最も多くの検証器から参照されている入力項目を選ぶ(同様に複数ある場合は任意のものでよい)だけでも、よい結果を得ることができる。
【００４７】
図６は、図４のステップ２.３に示す分割調整の処理を詳述したフローチャートである。ここでは、分割されたグループが必要以上に細かい場合や、「分割の必要条件」に示す「条件２」だけではどうしても「条件１」が満たされない場合に、分割の調整を行うものである。ここではまず、分割の個数を最小にするために、全ての隣り合うグループによる併合結果を観察し、どの併合結果においてもクライアントデバイス５０の端末能力に基づくサイズを超えるか否かが判断される(ステップ２.３.１)。これは、「分割の必要条件」に示す「条件３」が満たされているか否かを調べるものである。ここで「全ての隣り合うグループ」は、内容が順番に連続するフォームを分割して生成したグループの前後に隣り合うグループである。このステップ２.３.１で端末能力に基づくサイズを超える場合、即ち、これ以上併合するものがなくなれば、ステップ２.３.４にジャンプする。端末能力に基づくサイズを超えない場合には、併合結果がサイズを超えない、隣り合う２つのグループが選択される(ステップ２.３.２)。そして、このようにして選択された２グループを連結して、改めて１グループとして(ステップ２.３.３)、ステップ２.３.１に戻る。尚、「分割の必要条件」に示す「条件４」を満たすようにするには、ステップ２.３.２の選択順を与える必要があるが、正確に求めるには、全ての選択順を試行し、「条件４」(グループの最大サイズが最小となる)を満たす選択順を実行する。より実用的には、併合結果のグループサイズが最も小さい２グループを選択していく(同じサイズのものがあるときはその中から任意のものを選択する)ことだけでもよい結果が得られることが多い。
【００４８】
ステップ２.３.４〜ステップ２.３.６では、ここまでで「分割の必要条件」に示す「条件１」を満たすことができないときに調整を行うものである。基本的な考え方は、サブフォームを必要な大きさに分割し、必要条件２を満たすように検証器を仮想的にコピーして参照関係も修正している。まず、どのグループも端末能力に基づくサイズ以下か否かが判断される(ステップ２.３.４)。全てのグループがサイズ以下である条件を満たしていれば、分割調整処理のサブルーチンは終了する。サイズ以下ではないグループが存在する場合には、サイズを超えるグループを一つ選び、必要なサイズになるように分割する(ステップ２.３.５)。尚、この処理部分は上記特許文献１などの従来技術で実行することができる。その後、分割に合わせて、この分割されたグループを２つ以上同時に参照しないように、もとのグループを参照する検証器をコピーする(ステップ２.３.６)。即ち、例えば、Ｖという検証器がＧというグループの入力項目を参照しており、ＧをＧ１とＧ２に分割したときにＶがＧ１とＧ２の両方を参照していれば、Ｇ１だけを参照するＶ１とＧ２だけを参照するＶ２にＶをコピーして置き換える。その後、ステップ２.３.４に戻り、サブルーチンを繰り返す。尚、この検証器のコピーは、後述する図７のステップ６.６およびステップ６.７におけるSubmitボタンの自動付加アルゴリズムでは無効にする必要がある。即ち、ステップ２.３.６で検証器がコピーされたとしても、ステップ６.６およびステップ６.７で使われる検証器はコピーする前のものでなければならない。
【００４９】
次に、フォーム分割・生成部２０の画面生成部２２にて主に実行されるページＵＩの作成について、図７〜図９を用いて説明する。
図７は、ページＵＩの作成処理を示したフローチャートである。ここでは、図３に示すステップ２で分割されたフォームに、検証器や入力状態の表示ユーザインタフェースやエラー修正のためのハイパーリンクを動的に生成するものである。動的に生成するためには、図４に示すステップ２.４でのページ生成時に、動的な情報を表示するような仕組みを入れておくことが必要である。これは、ＪＳＰのような動的なページ記述技術を使用することで実現できる。
図８は、生成されるＪＳＰコードの一例を示した図である。この図８の例では、Apache Strutsを利用している。これは、あるフォームを３つに分割したページ（divPage1.jsp, divPage2.jsp, divPage3.jsp ）の２番目のＪＳＰの内容を示している。
また、図９は、分割フォームを携帯電話でレンダリングされたイメージ例を示している。
【００５０】
図８の６行目から９行目に、各ページに属する検証器の実行状態を表示するためのbean出力文がある。検証器状態の出力の一方法として、各ページの検証器の状態からページの状態を計算して、例えば、全ての検証器がＯＫならページの検証状態がＯＫ、それ以外はページの検証状態はＮＧである等、各ページ１個の状態表示をするものがある。例えば、状態表示グラフィックス上のmouse overによる吹出しで検証器の説明が表示できるなど、対象端末に高度なＵＩがある場合には、ページ単位ではなく検証器単位で表示を行い、より詳細な情報を提示することもできる。かかる場合には、例えば、文字「｜」がページ間に挿入されるなど、ページの切れ目が判りやすいように表示される。ユーザはどのページにエラーがあるか判るようになっている。
更に、表示部分そのものがハイパーリンクになっており、ユーザの直接操作により該当ページを素早く表示することができる(<ａ>タグ)。また、強調表示(<ｅｍ>タグ)によりユーザに現在のページを意識させるようになっている。
【００５１】
これらの出力は、３行目と４行目のuseBeanによって指定されるJava Beanを制御することによって行われる。図７のステップ６.１、ステップ６.２、およびステップ６.３は、行３から行８までの出力を行っている。即ち、ページＵＩの作成では、まず、該当サブページに別のサブフォームへのハイパーリンクを作成する(ステップ６.１)。自分自身のサブフォーム(該当サブフォーム)はそのまま表示する。また、各サブフォーム内の入力項目を参照する検証器の表示ＵＩを、そのハイパーリンクと対応させて配置する(ステップ６.２)。そして、内部状態から各検証器の状態を表示する(ステップ６.３)。ここでは、各検証器の状態(ＯＫかＮＧ、または未検証)をdivform.ValidatorStatusクラスのstatus1, status2, …プロパティにセットしている。実際にセットする値は、ＨＴＭＬ画面でも表示されるように、例えば、”OK”(検証ＯＫの場合)、”<em>ERR</em>”(検証ＮＧの場合)であり、これらを出力している。可能であれば、この部分は<img>タグなどを用いたグラフィックス（ボックス表示）やカラーを用いることができ、よりユーザの視認性を高めることもできる。更に、未入力チェックのような特別の検証器は、異なる表示をすることにより更に使い勝手を向上させることもできる。例えば、検証がＮＧの場合は赤色で表示するが、未入力の場合はより小さなボックスの薄い赤色にする等といったことが考えられる。未入力は未だ入力していないだけで、必ずしもエラーとは言えないためである。
【００５２】
図７のステップ６.４およびステップ６.５は、図８の行９から行１４の生成を行っている。即ち、入力項目フィールドを表示し(ステップ６.４)、前後のサブフォームやエラーのあるサブフォームへのナビゲーションリンクを作成する(ステップ６.５)。ここでは、行１０のように入力項目の初期値も入力される。既にusername項目の値が別のページ(自分自身の前回の入力も含む)で入力されている場合には、ValidateStatusクラスのbeanに各入力済みの値をセットしておき、valueメソッドで呼び出せるようにしておく。このとき、入力項目グループの分割でコピーされた入力項目は、同一の値となるようにする。
尚、上記の例では、前頁と次ページへのリンクしかないが、エラーがあるページのみを選択して移動できるようなナビゲーションリンクを作成することも可能である。
【００５３】
図７のステップ６.６、ステップ６.７、およびステップ６.８は、図８の行１２にあるbean出力文によるSubmitボタンの自動付加を実現している。まず、ステップ６.６では、図６に示したステップ２.３.６にてコピーする前の検証器で該当サブフォームを参照しないものが検証ＯＫであるか否かが調べられる。検証ＯＫでない場合には、ページＵＩ作成処理が終了する。検証ＯＫである場合には、ステップ６.７へ移行する。このステップ６.７では、自分自身を参照する検証器で、該当サブフォーム以外に未入力の必須入力項目がないか否かが調べられる。必須入力項目がページ外にある場合には、ページＵＩ作成処理が終了する。このステップ６.６およびステップ６.７の２つの条件を満たした場合には、Submitボタンを該当ページに作成する(ステップ６.８)。即ち、Divform.SubmitMakerクラスのbeanに対し、Submitボタン作成を指示する。これは、例えば、makeSubmit()のようなメソッドを呼び出すことによって指示する。SubmitMakerクラスのbeanは、指示されると内部状態を変更してSubmitボタンを出力するようにする。実際には、ＪＳＰの出力を行う時点でrenderButtonプロパティが呼ばれ、内部状態をチェックしてSubmitボタンを出力する場合は、”<input type=”submit” value=”Login”/>”のような文字列を出力する。Submitボタンを出力できない場合は、空文字列を返し、結果的に他の分割ページへの移動だけしかできないようする。以上のようにして、ページＵＩの作成処理が終了する。
【００５４】
このようにして作成される携帯電話の画面例は、図９に示すようになる。図９に示す検証器の状態表示を伴う分割フォームのユーザインタフェースでは、携帯電話２００の画面２１０に、検証器ごとに設けられる複数のボックスを表示するサブフォーム状態表示２１１、検証器に対応してどこで区切れているかを線「｜」で区切って示す分割表示２１２、画面２１０上にて現在フォームを表示している検証器のボックスを下線で示し、フォームの全体に対する分割フォームの位置づけを明らかにする現在フォーム表示２１３、状態表示グラフィックス上のmouse overによる吹出しで検証器の説明を行う吹き出し表示２１４、サブフォーム内にて各項目を入力するための入力項目２１５、および必要なときに自動付加されるサブミットボタン２１７、ポップアップボタン２１８が生成されている。サブフォーム状態表示２１１では、１つの四角は検証器が示されており、各検証器の状態を把握することができる。各検証器の状態を例えば色を変えて表示することで、各分割サブフォームにて入力がされているか否か、検証されているか否か等の状態を認識することができる。また、サブフォーム状態表示２１１にてハイパーリンク機能を使えば、ユーザは所定のボックスを指定することで該当するサブフォーム画面を直ぐに表示することが可能となる。
【００５５】
次に、多くの入力フィールドを持つＨＴＭＬフォーム入力画面を小画面端末(Ｗｅｂアクセス可能な携帯電話)用に分割する例について説明する。
図１０は、出願人が提供するＷｅｂサイト内の求職者応募フォームのページの一部を示した図である。ここでは、互いに関連し合った２９もの入力フィールドが存在し、入力が必ず要求されているフィールドなど、幾つかの検証器を有している。携帯電話のような小画面で一度に表示するのは明らかに困難であり、仮に表示できたとしてもユーザの使い勝手はよくないと考えられる。
【００５６】
フォームの入力として、このＨＴＭＬ文書、検証器としてＪａｖａで記述された各フィールドの検証器プログラムが与えられているとする。このフォームには各種の検証器が存在すると考えられる。例えば、図１０にて、Requiredとしてフィールドに「＊」マークで印がついているものは、ユーザが必ず入力しなければいけない必須入力フィールドであるが、かかる必須入力フィールドが入力されたかどうかを調べるのも検証器の一つである。
【００５７】
First Nameが入力されたかどうかの検証は次のようなJavaプログラムで記述される：
boolean requiredValidator(HttpServletRequest request) {
String fieldValue = request.getParameter(“First name”);
If(fieldValue != null && fieldValue.length() > 0) return true;
else return false;
}
ユーザからの入力はrequestというＪａｖａ オブジェクトからgetParameterメソッドで得ることができる。引数は、フィールド固有の識別文字列(上述の例では“First name”)を与える。もしも、この文字列が空文字列(nullまたは長さが０)ならば、入力が未だなされていないということで、この検証器(requiredValidatorというメソッド)はfalseを返す（すなわち検証がＮＧ）。それ以外はtrueを返す(検証済み)。この例の場合は、参照する入力項目はrequestオブジェクトのgetParameterの引数を見れば判る。明らかにFirst nameという入力項目はこの検証器(Required)から参照されていることが判る。
【００５８】
同様に、Last nameも同様なプログラムで与えられ、別のRequired検証器はLast nameを参照していることが判る。実際にはJavaプログラムの別のメソッドで入力フィールド名を参照することもあるので、より正確にはＪａｖａコードのデータフロー分析が必要である。このような必須入力フィールドは、同様に各々のRequired検証器と関連付けることができる。また同様に、名前が正しく入力されているかの検証器(Person Name)は、First name、Middle name、Last nameの３つの入力フィールドを見ており、人の名前として正しい入力がされたか(即ち、First nameとLast nameが空でなく正しい文字が使われているかどうかなど)をチェックする。かかる場合、Person Name検証器が参照するフィールドはFirst name、Last name、Middle nameの３つである。
【００５９】
図１１は、以上のようにして得られた、全ての検証器と入力フィールドの参照関係の解析結果を示した図である。四角形がフィールドを、楕円が検証器を、矢印が参照関係を表している。この図１１に示すようなフォーム検証器と入力項目の参照関係から、図４のステップ２.２に示した入力項目(これらの入力フィールドグループ)の分割が行われる。ここでは、実用上正確な画面サイズの最大値を使用するのではなく、以下に示すような近似式が用いられる。この近似式は、経験上ユーザにとって使いやすいと思われる関数を決めたもので、その一例である。全ての端末で当てはまりそうな関数を保守的に決めればよい。近似式として、フォームの入力フィールドの１ページあたりの個数が、
（画面の表示可能行数）/２ 〜(画面表示可能行数)＊１.５
になっているとものとする。ここでは、例えば１画面に６行表示できる携帯電話を考えると、１画面に置く望ましいフィールド個数は３〜９個となる。厳密な最大サイズではなく幅があるのは、例えば、図５に示すステップ２.２.２や図６に示すステップ２.３.４などの分割の判別では大きいほうの９を、図６に示すステップ２.３.１などの併合の判別では小さいほうの３を用いるといったように、より現実的な適用を行うためである。
【００６０】
ここで、Country Phone CodeフィールドがHome Phone、School Phone、Work Phoneの各電話番号検証器と共有されており、図５に示すステップ２.２.１の結果では１１個の入力項目グループになってしまう。そこで、このCountry Phone Codeフィールドを３つにコピーすることにより、３〜４個のフィールドからなる各電話番号入力画面に分割することができる。同様に、How should we contact you?フィールドについても、選択されたコンタクト方法に対応する入力フィールド(電子メール、住所、各電話番号)が正しく入力されているか否かを検証する必要がある。このままでは１０個を超えるフィールドを含むようなグループになる。そこで、コンタクト方法の各入力フィールドをコピーすることにより、この検証器のグループを独立させることができる。
【００６１】
図１２は、検証器と入力フィールドの参照関係に対して、図１１に示す図４のステップ２.２による分割を施した結果を示した図である。黒地に白抜き文字で示すフィールドはコピーされたものである。次に、図４のステップ２.３を実行すると、Non US PhoneとBest days/timesのフィールドを含むページがそれぞれ１つしかフィールドを含まないので、併合されて一つのグループとなる。以上のような結果として、９グループのフィールドグループに分割できる。この分割結果を反映するように、もとのＨＴＭＬを分割してそれぞれの分割フォーム画面を作成する。各端末(クライアントデバイス５０)の能力が近いものや扱えるマークアップ言語によるグループ毎に、先に例として挙げたような９つのＪＳＰファイルとして作成することができる。実行時には、各フィールド(２３個)の内部状態と、２７個の検証器の内部状態をＪ２ＥＥのServletプログラムで管理してユーザからの入力を受け取ることができる。
【００６２】
図１３は、Work Phoneのサブフォーム画面の出力結果例を示した図である。図９と同様の機能については同様の符号を用いており、説明を省略する。この例では、画面上段に１３個の検証器の状態がボックス表示されている。残り１４個の必須入力の検証器はここでは省略したが、更に小さなボックスを用いて表示することもできる。また、縦棒である線「｜」(分割表示２１２)でページの区切りを表し、全部で９ページのサブフォームが表示されている。但し、図４に示すステップ２.１の処理で、Contact先の選択と実際のContact先(電子メール，住所，各電話番号)が入力されているかの検証器が、入力項目のコピーにより重複されて表示されている。このため、図１３では全部で１８個のボックスが見える。例えば、電子メールの入力画面は２ページ目であるが、電子メール入力チェック、電子メールアドレスの形式チェックに加えてContact先のチェックの３つのボックス(上段左から３〜５個目のボックス)が表示されており、一つの検証器がＮＧであることが判る(ここでは、電子メールの形式がＮＧということがmouse overによる吹出し(吹き出し表示２１４)で説明されている)。また、現在処理中の画面は、対応するボックスの下にアンダーライン(現在フォーム表示２１３)で示している。Work Phone入力画面は５ページ目である。１〜４ページ目で未検証の検証器があるのは、Contact先が未だ指定されていないためこの検証器が作動していないためである。６ページ目以降は未入力であるため、Submitボタンは処理可能ではないと判別され、表示されていない。
【００６３】
ここで、検証器のコードや参照関係は、Ｗｅｂアプリケーションの各種定義ファイルからも容易に取り出すことができる。例えば、ApacheのStruts (http://jakarta.apache.org/struts/)のValidator Frameworkを利用すると、本実施の形態における入力として必要とする検証器とフィールドの参照関係を求めることができる。Strutsアプリケーションの検証器の定義ファイル(validation.xml)から、図１０以下の例に示すフォームに含まれる電子メール入力フィールドの検証器コードの定義は、以下の通りである。
<form-validation>
<formset>
<form name="IBMJobsForm">
…
<field property="EmailAddress" depends="required, email"> 
<arg0 key="prompt.EmailAddress" /> 
</field>
…
</form>
</formset>
</form-validation>
【００６４】
ここでは、<form-validation>タグで検証が必要なフォームを全て定義している。また、<form>タグで各フォームの全てのフィールドと検証器を記述し、その中の<field>タグでそのフィールドにマップされる検証器を定義している。<field>タグのproperty属性で、該当するフィールドのプロパティ名を指定している。実際のＪＳＰファイル中の<text>タグ(Strutsにおける文字列入力用カスタムタグ)などについているプロパティ属性の値と一致させることにより、特定のフィールドを指し示している。そして、depends属性により、このフィールドが関係する検証器が列挙されている。この例では、requiredという入力をしたことの検証器と、emailという電子メール形式の検証器が指定されている。また、<field>タグ内の<arg〜>タグは、検証器のコード中で使われる各種値を指定する。ここでは、エラーメッセージ用のフィールドのＧＵＩ用文字列を間接的に定義している。これらの記述を用いると、email 検証器はEmailAddressフィールドを参照し、同じくrequired検証器はEmailAddressフィールドを参照することが判る。他のフィールドや検証器も同様にして、参照関係をこのvalidation.xmlから求めることができる。
【００６５】
以上、詳述したように、本実施の形態によれば、複雑なフォームを任意の端末の能力に合わせて自動的に分割し、エラー表示やエラー画面のナビゲーション、およびSubmitボタンを適切にかつ自動的に表示することが可能となる。より具体的には、「分割の必要条件」に示す「条件１」に反しない範囲内で、意味的につながりのある入力項目は１ページに同時に表示されるので、ユーザにとって入力がし易く、検証器の報告するエラーの修正がし易い。また、画面上にエラーの状態が表示され直接操作によりエラーのあるページに簡単にジャンプできること、また、フォームのSubmitボタンは入力が完了する可能性があるときだけ、かつ自動的に出てくるので、例えばサブミット(submit)するために最後のページまで無駄にページをめくる必要がなくなる。または、Submitボタンが全ての分割ページに付いていて無駄なフォーム処理の起動やエラー処理が行われなくなる。更に、このような効果的な分割をデバイスごとに手動で行う必要がなく、自動で生成されるので、マルチデバイス向けＷｅｂアプリケーション開発を効率化することができる。
【００６６】
尚、本実施の形態は、コンピュータであるＷｅｂサーバ１０やアプリケーション開発時の開発マシン等に各種処理を実行させるためのプログラムとして提供される。これらのプログラムをコンピュータに対して提供する際に、例えばサーバにインストールされた状態にて提供される場合の他、コンピュータに実行させるプログラムをコンピュータが読取可能に記憶した記憶媒体にて提供する形態が考えられる。この記憶媒体としては、例えば各種ＤＶＤやＣＤ−ＲＯＭ媒体等が該当し、各種ＤＶＤやＣＤ−ＲＯＭ読取装置等によってプログラムが読み取られ、フラッシュＲＯＭ等にこのプログラムが格納されて実行される。また、これらのプログラムは、例えば、プログラム伝送装置によってネットワークを介して提供される形態がある。
【００６７】
ここで、本件を上記のような記憶媒体の発明として捉えると、以下のようになる。即ち、「コンピュータを、フォーム要求のあった端末の端末能力を取得する手段と、記憶装置からフォーム要求のあったフォームの画面定義およびフォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを読み出す手段と、取得された端末能力に合わせ、読み出されたフォームの画面定義および検証器を用いてフォームを分割する手段として機能させ、ユーザが使用する端末に適合した形態でフォームの分割表示を行うようにコンピュータを機能させるプログラムを記憶した記憶媒体。」である。
また、「コンピュータを、記憶装置からフォームの画面定義およびフォーム内の入力項目に入力された入力値の検証を実行する検証器のコードを読み出し、フォーム内容を出力する端末の端末能力に合わせてフォームを分割する手段と、分割して得られたサブフォームと共にフォームの各入力項目に対する状態および検証器の状態を含む内部状態を表示するための表示ユーザインタフェースを生成する手段として機能させ、ユーザが使用する端末に適合した形態でフォームの分割表示を行うようにコンピュータを機能させるプログラムを記憶した記憶媒体。」である。
【産業上の利用可能性】
【００６８】
本発明の活用例としては、主にＷｅｂフォームを提供するサーバとしてのコンピュータや、これらのコンピュータにて実行されるプログラムが活用例として挙げられる。また、このプログラムとしては、コンピュータにインストールされた形式の他、ＣＤ−ＲＯＭ等の各種記録媒体に格納される形式、インターネット等のネットワークを介して伝送される形式等がある。
【図面の簡単な説明】
【００６９】
【図１】本実施の形態が適用されるフォーム自動分割システムの構成を示した図である。
【図２】本実施の形態が適用されるＷｅｂサーバや各種クライアントデバイスを実現するのに好適なコンピュータ装置のハードウェア構成例を模式的に示した図である。
【図３】フォーム分割から、分割されたフォームの実行制御をするまでの全体のフローチャートを示した図である。
【図４】フォームの分割・生成処理の全体の流れを示したフローチャートである。
【図５】図４のステップ２.２による入力項目の分割処理を詳述したフローチャートである。
【図６】図４のステップ２.３に示す分割調整の処理を詳述したフローチャートである。
【図７】ページＵＩの作成処理を示したフローチャートである。
【図８】生成されるＪＳＰコードの一例を示した図である。
【図９】分割フォームを携帯電話でレンダリングされたイメージ例を示した図である。
【図１０】出願人が提供するＷｅｂサイト内の求職者応募フォームのページの一部を示した図である。
【図１１】全ての検証器と入力フィールドの参照関係の解析結果を示した図である。
【図１２】検証器と入力フィールドの参照関係に対してステップ２.２による分割を施した結果を示した図である。
【図１３】Work Phoneのサブフォーム画面の出力結果例を示した図である。
【符号の説明】
【００７０】
１０…Ｗｅｂサーバ、１１…分割フォーム実行制御部、１２…ＨＴＴＰ要求受付部、２０…フォーム分割・生成部、２１…フォーム分割部、２２…画面生成部、３１…アプリケーションコードＤＢ、３２…デバイス情報ＤＢ、３３…分割フォームＤＢ、３４…ワーキングメモリ、４０…ネットワーク、５０…クライアントデバイス、５１…ＷＷＷブラウザ
【図１】
2005259039.tif 000003
【図２】
2005259039.tif 000004
【図３】
2005259039.tif 000005
【図４】
2005259039.tif 000006
【図５】
2005259039.tif 000007
【図６】
2005259039.tif 000008
【図７】
2005259039.tif 000009
【図８】
2005259039.tif 000010
【図９】
2005259039.tif 000011
【図１０】
2005259039.tif 000012
【図１１】
2005259039.tif 000013
【図１２】
2005259039.tif 000014
【図１３】
2005259039.tif 000015