(57)【特許請求の範囲】
【請求項１】
アプリケーションを開発する開発者端末と、当該アプリケーションを操作するクライアント装置と、サーバとがネットワークを介して通信可能な情報処理システムであって、
前記クライアント装置は、
前記サーバに処理を指示するユーザの操作を受け付ける指示受付オブジェクトが選択されることで実行されるイベント処理を含む画面データを表示する表示制御手段と、
前記表示制御手段に表示された画面データ上の前記指示受付オブジェクトに関連付けられたイベント処理により生成される、当該指示受付オブジェクトの操作に応じて実行されるクエリを特定するための識別情報を含むアクション要求を、前記サーバに引き渡す要求引渡手段と
を備え、
前記開発者端末は、
前記アプリケーションの画面データを生成するべく、アクション要求に従って得られた値を表示するオブジェクトおよび指示受付オブジェクトを配置するオブジェクト配置手段と、
前記指示受付オブジェクトに対応付く識別情報と関連付けるべく、前記アプリケーションが実行され、前記オブジェクト配置手段により配置された指示受付オブジェクトが操作された場合に、前記サーバに要求するクエリであって、所望の検索サービスに対する検索条件を指定するための当該クエリの設定を受け付ける設定受付手段と
を備え、
前記サーバは、
前記設定受付手段で受け付けた前記クエリと、前記識別情報とを含むアクション定義を記憶するアクション定義記憶手段と、
前記クライアント装置の前記要求引渡手段から引き渡される前記アクション要求を受け付ける要求受付手段と、
前記要求受付手段により受け付けた前記アクション要求に含まれる前記識別情報に基づいて、前記アクション定義記憶手段に記憶されている前記アクション定義を取得するアクション定義取得手段と、
前記アクション定義取得手段により取得した前記アクション定義に含まれる前記クエリに基づいて前記検索サービスから検索結果を取得し、処理結果とする検索実行制御手段と、
前記検索実行制御手段により得られる前記処理結果を、前記クライアント装置へ送信する送信手段と
を備え、
前記表示制御手段は、前記サーバの送信手段により送信された処理結果が、処理結果表示オブジェクトに配置された画面データを表示することを特徴とする情報処理システム。
【請求項２】
前記オブジェクト配置手段により、前記画面データに対してオブジェクトおよび前記指示受付オブジェクトを配置し、更に前記設定受付手段により当該指示受付オブジェクトにクエリを設定するための入力操作を開発者にさせるための設定画面を表示する設定画面表示手段と
を、更に備えることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記クライアント装置の前記表示制御手段は、前記サーバの前記送信手段により送信された前記処理結果を用いて、前記画面データを非同期通信で更新して表示することを特徴とする請求項１または請求項２のいずれかに記載の情報処理システム。
【請求項４】
前記サーバは、
前記検索実行制御手段による前記処理結果を、前記画面データの前記処理結果表示オブジェクトに当てはめる当てはめ手段と、を更に備え、
前記サーバの前記送信手段は、前記当てはめ手段により当てはめられた前記画面データを前記クライアント装置へ送信し、
前記クライアント装置の前記表示制御手段は、前記サーバの前記送信手段により送信された前記画面データを用いて表示することを特徴とする請求項１または請求項２のいずれかに記載の情報処理システム。
【請求項５】
前記アクション定義記憶手段は、
前記クエリと、当該クエリに基づいて得られる前記検索結果に含まれるデータ項目の値を前記画面データ上にレイアウトされる複数の処理結果表示オブジェクトのいずれに表示するかを指定するマッピング情報とを対応付けてクエリ定義とし、１または複数の当該クエリ定義を含むことが可能であるアクション定義を記憶するものであることを特徴とする請求項１乃至請求項４のいずれか１項に記載の情報処理システム。
【請求項６】
前記アクション定義は、
前記クエリ定義を複数含む場合に当該クエリ定義を実行する順番を指定する実行順を含むことを特徴とする請求項５に記載の情報処理システム。
【請求項７】
前記クエリ定義は、
前記クエリがパラメータ部分を含む場合には、前記画面データにおいて条件値を含む条件項目オブジェクトと当該パラメータ部分を対応付けて記憶することが可能であって、
前記イベント処理は、
前記条件項目オブジェクトから条件値を取得し、前記要求引渡手段が前記サーバに引き渡す前記要求に、前記条件項目オブジェクトと前記条件値とを対応付けて含むことが可能であって、
前記検索実行制御手段は、
前記クエリがパラメータ部分を含む場合には、当該パラメータ部分に対応する前記要求に含まれる前記条件項目オブジェクトから取得した前記条件値を、当該クエリのパラメータ部分に代入し、前記検索サービスに対する検索の処理を実行させるものであることを特徴とする請求項５または請求項６のいずれか１項に記載の情報処理システム。
【請求項８】
前記クエリ定義は、
前記処理結果表示オブジェクトが配置された表示グループを含むものであって、
前記表示制御手段は、
前記クエリ定義において指定された前記表示グループに基づいて、処理結果表示オブジェクトが配置された画面データを表示することを特徴とする請求項５乃至請求項７のいずれか１項に記載の情報処理システム。
【請求項９】
前記クエリ定義は、
複数の異なる方式による前記検索サービスに応じて定義をすることが可能であり、
前記クエリ定義が、複数の異なる方式による前記検索サービスのうちいずれの当該検索サービスに対応する前記クエリ定義であるかを判別する検索サービス方式判別手段と、を更に備え、
前記検索実行制御手段は、
前記検索サービス方式判別手段により判別された前記検索サービスの方式に応じて、前記クエリ定義に基づいて、当該検索サービスの検索が実行されることによって前記検索結果を取得するものであることを特徴とする請求項５乃至請求項８のいずれか１項に記載の情報処理システム。
【請求項１０】
前記サーバは、
前記イベント処理を、前記アクション定義記憶手段に記憶された前記アクション定義に基づいて生成する指示引渡処理生成手段と、
を備えることを特徴とする請求項１乃至請求項９のいずれか１項に記載の情報処理システム。
【請求項１１】
前記検索サービスは、ＳＱＬ文によるデータベースの検索として実装されるものであって、
前記アクション定義における前記クエリは、
前記データベースへ発行する前記ＳＱＬ文であることを特徴とする請求項１乃至請求項１０のいずれか１項に記載の情報処理システム。
【請求項１２】
前記アクション定義は、
前記ＳＱＬ文と、当該ＳＱＬ文に基づいて得られる前記検索結果に含まれるデータ項目の値を前記画面データ上にレイアウトされる複数の処理結果表示オブジェクトのいずれに表示するかを指定するマッピング情報と、を対応付けてクエリ定義とし、１または複数の当該クエリ定義を含むことが可能であることを特徴とする請求項１１に記載の情報処理システム。
【請求項１３】
前記検索サービスは、ウェブサービスに対してＵＲＬを検索条件として指定し、ＲＥＳＴ方式のレスポンスデータを結果として取得する方式により実装されるものであって、
前記アクション定義における前記クエリは、
前記ウェブサービスに発行される前記ＵＲＬであることを特徴とする請求項１乃至請求項１２のいずれか１項に記載の情報処理システム。
【請求項１４】
前記アクション定義は、
前記レスポンスデータのうちいずれの部分データ構成を利用するかを指定する指定対象と当該指定対象で指定された前記部分データから取得されたデータ項目のうちいずれのデータ項目の値をいずれの処理結果オブジェクトに対応付けるかを指定する抽出式とを対応付けてマッピング情報とし、前記ＵＲＬと当該マッピング情報と、を対応付けてクエリ定義とし、１または複数の当該クエリ定義を含むことが可能であることを特徴とする請求項１３に記載の情報処理システム。
【請求項１５】
アプリケーションを開発する開発者端末と、当該アプリケーションを操作するクライアント装置と、サーバとがネットワークを介して通信可能な情報処理システムを制御する方法であって、
前記クライアント装置は、
表示制御手段が、前記サーバに処理を指示するユーザの操作を受け付ける指示受付オブジェクトが選択されることで実行されるイベント処理を含む画面データを表示する表示制御ステップと、
要求引渡手段が、前記表示制御ステップに表示された画面データ上の前記指示受付オブジェクトに関連付けられたイベント処理により生成される、当該指示受付オブジェクトの操作に応じて実行されるクエリを特定するための識別情報を含むアクション要求を、前記サーバに引き渡す要求引渡ステップと
を含み、
前記開発者端末は、
オブジェクト配置手段が、前記アプリケーションの画面データを生成するべく、アクション要求に従って得られた値を表示するオブジェクトおよび指示受付オブジェクトを配置するオブジェクト配置ステップと、
設定受付手段が、前記指示受付オブジェクトに対応付く識別情報と関連付けるべく、前記アプリケーションが実行され、前記オブジェクト配置ステップにより配置された指示受付オブジェクトが操作された場合に、前記サーバに要求するクエリであって、所望の検索サービスに対する検索条件を指定するための当該クエリの設定を受け付ける設定受付ステップと
を含み、
前記サーバは、
アクション定義登録手段が、前記設定受付ステップで受け付けた前記クエリと、前記識別情報とを含むアクション定義をアクション定義記憶手段に記憶させるアクション定義登録ステップと、
要求受付手段が、前記クライアント装置の前記要求引渡ステップから引き渡される前記アクション要求を受け付ける要求受付ステップと、
アクション定義取得手段が、前記要求受付ステップにより受け付けた前記アクション要求に含まれる前記識別情報に基づいて、前記アクション定義記憶手段に記憶されている前記アクション定義を取得するアクション定義取得ステップと、
検索実行制御手段が、前記アクション定義取得ステップにより取得した前記アクション定義に含まれる前記クエリに基づいて前記検索サービスから検索結果を取得し、処理結果とする検索実行制御ステップと、
送信手段が、前記検索実行制御ステップにより得られる前記処理結果を、前記クライアント装置へ送信する送信ステップと
を備え、
前記表示制御ステップは、前記サーバの送信ステップにより送信された処理結果が、処理結果表示オブジェクトに配置された画面データを表示することを特徴とする情報処理システムの制御方法。
【請求項１６】
アプリケーションを開発する開発者端末と、当該アプリケーションを操作するクライアント装置と、サーバとがネットワークを介して通信可能な情報処理システムにおいて実行可能なプログラムであって、
前記クライアント装置を、
前記サーバに処理を指示するユーザの操作を受け付ける指示受付オブジェクトが選択されることで実行されるイベント処理を含む画面データを表示する表示制御手段、
前記表示制御手段に表示された画面データ上の前記指示受付オブジェクトに関連付けられたイベント処理により生成される、当該指示受付オブジェクトの操作に応じて実行されるクエリを特定するための識別情報を含むアクション要求を、前記サーバに引き渡す要求引渡手段
として機能させ、
前記開発者端末を、
前記アプリケーションの画面データを生成するべく、アクション要求に従って得られた値を表示するオブジェクトおよび指示受付オブジェクトを配置するオブジェクト配置手段、
前記指示受付オブジェクトに対応付く識別情報と関連付けるべく、前記アプリケーションが実行され、前記オブジェクト配置手段により配置された指示受付オブジェクトが操作された場合に、前記サーバに要求するクエリであって、所望の検索サービスに対する検索条件を指定するための当該クエリの設定を受け付ける設定受付手段
として機能させ、
前記サーバは、
前記設定受付手段で受け付けた前記クエリと、前記識別情報とを含むアクション定義をアクション定義記憶手段に記憶させるアクション定義登録手段、
前記クライアント装置の前記要求引渡手段から引き渡される前記アクション要求を受け付ける要求受付手段、
前記要求受付手段により受け付けた前記アクション要求に含まれる前記識別情報に基づいて、前記アクション定義記憶手段に記憶されている前記アクション定義を取得するアクション定義取得手段、
前記アクション定義取得手段により取得した前記アクション定義に含まれる前記クエリに基づいて前記検索サービスから検索結果を取得し、処理結果とする検索実行制御手段と、
前記検索実行制御手段により得られる前記処理結果を、前記クライアント装置へ送信する送信手段
として機能させ、
前記表示制御手段は、前記サーバの送信手段により送信された処理結果が、処理結果表示オブジェクトに配置された画面データを表示することを特徴とするプログラム。
【請求項１７】
請求項１６に記載されたプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションの実行に関し、特に検索サービスに対するクエリの検索結果を画面に表示するためのロジックを、容易に定義可能な、アプリケーション実行環境に関する。
【背景技術】
【０００２】
従来から、業務アプリケーションにおいては、データベースの検索結果やウェブサービスのレスポンスデータ（ウェブサーバへの要求に対する応答）を表示するＧＵＩ（グラフィカルユーザインタフェース）を開発することが多い。
【０００３】
しかしながらデータベースの検索結果をＧＵＩに表示するため、アプリケーションの開発者は、どのデータ項目をＧＵＩ上のどのオブジェクト（例えばテキストボックス）に表示するか、を１つずつ対応づける必要があった。特に検索対象となるデータベースやウェブサービスの結果に含まれるデータ項目（カラム）数が多い場合には、前述の対応付けも多くなり、作業ミスも増加し、ビジネスロジックとして本質的ではない部分で、アプリケーションの実行を制御するソースコードを記載する負荷が大きかった。
【０００４】
特許文献１では、開発者が、例えば照会用ボタンがマウスクリックされた場合の処理定義として、まず照会の検索キーとなる値を取得するオブジェクト（要求項目）、照会結果の値を設定するオブジェクト（応答項目）、処理を要求するプログラム名、機能番号をトランザクションとして定義し、さらに前述のプログラム名および機能番号を、ロジックファイルに記載された関数と結びつけるロジック設定として定義し、また、前記関数はロジックファイルにおいて実際にデータベースを検索するプログラムとして定義することで、前述のようなＧＵＩ上のオブジェクトと、検索キーの取得および検索結果の対応付けを行うことが可能なプログラム自動生成装置を提供している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−０２０２９５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１におけるプログラム自動生成装置では、前述の通り、ＧＵＩ上のオブジェクトと、検索キー（要求項目）の取得および検索結果（応答項目）の対応付けを行うことが出来る。
【０００７】
しかし、開発者にとっては、トランザクション設定では前記対応付けを確認できるが、関数に受け渡しの際には配列に変換されるため、関数の開発においては、どのデータ項目の値が配列のどこに格納されているか、あるいは検索結果をどこに格納すべきかといった処理を意識する必要があること、関数内でのデータベース検索処理はプログラム言語で開発することなどが必要となる。すなわち、データリソースに対してクエリを実行し、レスポンスを受け取るため、開発者にとっては、関連する定義情報の構造を詳細に理解した上でプログラムの開発を要するものであり、容易に検索結果を表示できるものではない。
【０００８】
本発明の目的は、以上の目的を解決するものであり、オブジェクトおよび指示受付オブジェクトを配置し、当該指示受付オブジェクトに対してアクション定義を設定するという開発環境を提供し、開発環境で設定されたアクション定義を指示受付オブジェクトに対応付く識別情報をサーバに記憶させることで、アプリケーションの開発を容易にし、アクション定義による処理結果を開発したアプリケーションの表示画面で表示させる仕組みを提供することである。
【課題を解決するための手段】
【０００９】
本発明は、アプリケーションを開発する開発者端末と、当該アプリケーションを操作するクライアント装置と、サーバとがネットワークを介して通信可能な情報処理システムであって、前記クライアント装置は、前記サーバに処理を指示するユーザの操作を受け付ける指示受付オブジェクトが選択されることで実行されるイベント処理を含む画面データを表示する表示制御手段と、前記表示制御手段に表示された画面データ上の前記指示受付オブジェクトに関連付けられたイベント処理により生成される、当該指示受付オブジェクトの操作に応じて実行されるクエリを特定するための識別情報を含むアクション要求を、前記サーバに引き渡す要求引渡手段とを備え、
前記開発者端末は、前記アプリケーションの画面データを生成するべく、アクション要求に従って得られた値を表示するオブジェクトおよび指示受付オブジェクトを配置するオブジェクト配置手段と、前記指示受付オブジェクトに対応付く識別情報と関連付けるべく、前記アプリケーションが実行され、前記オブジェクト配置手段により配置された指示受付オブジェクトが操作された場合に、前記サーバに要求するクエリであって、所望の検索サービスに対する検索条件を指定するための当該クエリの設定を受け付ける設定受付手段とを備え、前記サーバは、前記設定受付手段で受け付けた前記クエリと、前記識別情報とを含むアクション定義を記憶するアクション定義記憶手段と、前記クライアント装置の前記要求引渡手段から引き渡される前記アクション要求を受け付ける要求受付手段と、前記要求受付手段により受け付けた前記アクション要求に含まれる前記識別情報に基づいて、前記アクション定義記憶手段に記憶されている前記アクション定義を取得するアクション定義取得手段と、前記アクション定義取得手段により取得した前記アクション定義に含まれる前記クエリに基づいて前記検索サービスから検索結果を取得し、処理結果とする検索実行制御手段と、前記検索実行制御手段により得られる前記処理結果を、前記クライアント装置へ送信する送信手段とを備え、前記表示制御手段は、前記サーバの送信手段により送信された処理結果が、処理結果表示オブジェクトに配置された画面データを表示することを特徴とする情報処理システム。
【発明の効果】
【００１０】
本発明により、オブジェクトおよび指示受付オブジェクトを配置し、当該指示受付オブジェクトに対してアクション定義を設定するという開発環境を提供し、開発環境で設定されたアクション定義を指示受付オブジェクトに対応付く識別情報をサーバに記憶させることで、アプリケーションの開発を容易にし、アクション定義による処理結果を開発したアプリケーションの表示画面で表示させる仕組みを提供することが可能となった。
【図面の簡単な説明】
【００１１】
【図１】本発明に係わるプログラム開発装置、プログラム開発サーバ、データベースサーバ、アプリケーションクライアント、アプリケーションサーバ、ＲＥＳＴサーバの構成の一例を示すシステム構成図である。
【図２】本発明に係わるプログラム開発装置、プログラム開発サーバ、データベースサーバ、アプリケーションクライアント、アプリケーションサーバ、ＲＥＳＴサーバとして適用可能な各ハードウェア構成の一例を示すブロック図である。
【図３】本発明の実施形態のソフトウェア構成を示すブロック図である。
【図４】本発明の実施形態のデータベースのテーブル群の一例を示すデータ構成図である。
【図５】本発明の実施形態のデータベースのテーブル群の一例を示すデータ構成図である。
【図６】開発者がレイアウト定義指示を行う画面の一例を示す図である。
【図７】開発者がレイアウト定義指示を行う操作手順の一例を簡単に説明するフローである。
【図８】レイアウトを定義する際のコンテナやオブジェクトの配置を示す一例である。
【図９】明細書形式コンテナにおける、一括作成によるレイアウトの自動作成を説明するための図である。
【図１０】グリッドオブジェクトにおける、一括作成によるレイアウトの自動作成を説明するための図である。
【図１１】グリッドオブジェクトにおける、一括作成によるレイアウトの自動作成を説明するための図である。
【図１２】明細書形式コンテナの一括作成後、更にグリッドオブジェクトの一括作成をする例を示す図である。
【図１３】明細書形式コンテナの一括作成後、グリッドオブジェクトの一括作成を実施した結果の例を示す図である。
【図１４】本発明の実施形態における一括作成部の処理の一例を示すフローチャートである。
【図１５】一括作成した結果を含むレイアウト定義のデータ構成の一例を示す図である。
【図１６】オブジェクトの属性編集するための属性編集画面の一例を示す図である。
【図１７】オブジェクトの属性編集結果が反映されたレイアウト定義のデータ構成の一例を示す図である。
【図１８】一括作成とオブジェクトの属性編集を実施した画面の一例を示す図である。
【図１９】開発者がアクション定義を行う画面の一例を示す図である。
【図２０】アクション定義のデータ構成の一例を示す図である。
【図２１】クエリ定義のデータ構成の一例を示す図である。
【図２２】本発明の実施形態におけるアクションの実行処理の一例を示すフローチャートである。
【図２３】アプリケーションクライアント画面上の指示受付オブジェクトに対応付ける処理を生成するフローチャートの一例である。
【図２４】ＲＥＳＴサーバに対するＲＥＳＴ方式の要求を示すＵＲＬと対応するレスポンスのデータの一例である。
【図２５】ＲＥＳＴ方式に基づき、明細書形式コンテナにおける、一括作成によるレイアウトの自動作成を説明するための図である。
【図２６】ＲＥＳＴ方式に基づき、グリッドオブジェクトにおける、一括作成によるレイアウトの自動作成を説明するための図である。
【図２７】本発明の実施形態における一括作成部の処理の一例を示すフローチャートである。
【図２８】一括作成した結果を含むレイアウト定義のデータ構成の一例を示す図である。
【図２９】開発者がＲＥＳＴ方式に基づきアクション定義を行う画面の一例を示す図である。
【図３０】ＲＥＳＴ方式によるクエリ定義のデータ構成の一例を示す図である。
【図３１】本発明の実施形態におけるＲＥＳＴ方式で定義したアクションの実行処理の一例を示すフローチャートである。
【図３２】レイアウトの一括作成をＳＱＬ文とＲＥＳＴ方式の両方で定義可能な場合の分岐処理の一例を示すフローチャートである。
【図３３】アクション定義から呼び出されるクエリの実行処理をＳＱＬ文とＲＥＳＴ方式の両方で定義可能な場合の分岐処理の一例を示すフローチャートである。
【図３４】ＳＱＬ文とＲＥＳＴ方式の両方でレイアウト定義するための画面を説明するための図である。
【図３５】ＳＱＬ文とＲＥＳＴ方式の両方でアクション定義するための画面を説明するための図である。
【図３６】ＳＱＬ文とＲＥＳＴ方式の両方を用いてレイアウト生成した場合のレイアウト定義のデータ構成の一例を示す図である。
【図３７】ＳＱＬ文とＲＥＳＴ方式の両方を用いてアクションを定義した場合の、アクション定義のデータ構成の一例を示す図である。
【図３８】ＳＱＬ文とＲＥＳＴ方式の両方を用いてアクションを定義した場合の、クエリ定義のデータ構成の一例を示す図である。
【発明を実施するための形態】
【００１２】
以下、本発明の実施の形態を、図面を参照して詳細に説明する。まず、第一の実施の形態を説明する。
【００１３】
図１は、本発明に係わるプログラム開発装置、プログラム開発サーバ、データベースサーバ、アプリケーションクライアント、アプリケーションサーバ、ＲＥＳＴサーバの構成の一例を示すシステム構成図である。
【００１４】
プログラム開発装置１０１（情報処理装置）は、開発者の操作に従って画面レイアウトおよびデータベース検索のアクションなどを定義する。プログラム開発装置１０１単体では、ユーザの入力を受け付け、後述するプログラム開発サーバ１０２（情報処理装置）に実際のプログラム生成処理をさせてもよいし、プログラム開発装置１０１単体でプログラム生成まで処理してもよい。
【００１５】
プログラム開発サーバ１０２ａ〜１０２ｂは、プログラム開発装置１０１により入力された開発者の指示に従って、プログラムを開発する。プログラム開発サーバ１０２ａはＬＡＮなどのネットワーク１０７内に配置されてもよいし、プログラム開発サーバ１０２ｂはインターネット上やクラウド上に配置されてもよい。
【００１６】
データベースサーバ１０３ａ〜１０３ｂ（検索サーバ）は、開発されたアプリケーションが使用するデータベースを管理するサーバであり、また本発明では開発時にも利用する。例えば、開発者が利用するためにデータベースサーバ１０３は、プログラム開発装置１０１と同一の装置で構成されていてもよいし、ＬＡＮなどのネットワーク１０７内に配置されてもよい（データベースサーバ１０３ａ）し、またインターネット上やクラウド上に配置されてもよい（データベースサーバ１０３ｂ）。また、プログラム開発装置１０１が、プログラム開発サーバ１０２と協調する場合には、プログラム開発サーバ１０２とデータベースサーバ１０３が同一の装置内に構成されていてもよい。
【００１７】
ＲＥＳＴサーバ１０６ａ〜１０６ｂ（検索サーバ）は、ＲＥＳＴ方式によりウェブサービスを提供するウェブサーバであり、また本発明では開発時にも利用する。例えば、開発者が利用するためにＲＥＳＴサーバ１０６は、プログラム開発装置１０１と同一の装置で構成されていてもよいし、ＬＡＮなどのネットワーク１０７内に配置されてもよい（ＲＥＳＴサーバ１０６ａ）し、またインターネット上やクラウド上に配置されてもよい（ＲＥＳＴサーバ１０６ｂ）。また、プログラム開発装置１０１が、プログラム開発サーバ１０２と協調する場合には、プログラム開発サーバ１０２とＲＥＳＴサーバ１０６が同一の装置内に構成されていてもよい。
【００１８】
アプリケーションサーバ１０５ａ〜１０５ｂは、プログラム開発装置１０１で開発されたアプリケーションを実行する。ＬＡＮなどのネットワーク１０７内に配置されてもよい（アプリケーションサーバ１０５ａ）し、またインターネット上やクラウド上に配置されてもよい（アプリケーションサーバ１０５ｂ）。また、ネットワーク１０７、インターネット、クラウド上のデータベースサーバ１０３と接続して動作可能である。
【００１９】
アプリケーションクライアント１０４ａ〜１０４ｂ（クライアント装置）は、アプリケーションサーバ１０５と協調してプログラム開発装置１０１で開発したアプリケーションプログラムを動作させる、ユーザの入力端末である。ＬＡＮなどのネットワーク１０７内に配置されてもよい（アプリケーションクライアント１０４ａ）し、またインターネット上やクラウド上に配置されてもよい（アプリケーションクライアント１０４ｂ）。携帯端末などの情報処理装置であってもよい。
【００２０】
図２は、本発明に係わるプログラム開発装置、プログラム開発サーバ、データベースサーバ、アプリケーションクライアント、アプリケーションサーバ、ＲＥＳＴサーバとして適用可能な各ハードウェア構成の一例を示すブロック図である。
【００２１】
図２において、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。
【００２２】
また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、プログラム開発装置、アプリケーションクライアント、各種サーバの後述する各種機能を実現するためのプログラムが記憶されている。
【００２３】
ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。
【００２４】
入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、プログラム開発装置、アプリケーションクライアント、各種サーバでは、キーボード、マウス等のポインティングデバイスが挙げられる。
【００２５】
出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶ディスプレイ等が挙げられる。
【００２６】
外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザーファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、外部メモリ２１１には、プログラム開発装置、アプリケーションクライアント、各種サーバの各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。
【００２７】
通信Ｉ／Ｆコントローラ２０８は、ネットワークを介して外部機器との通信制御処理を実行する。
【００２８】
本発明を実現するためのプログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
【００２９】
図３は、本発明の実施形態のソフトウェア構成を示すブロック図である。
【００３０】
プログラム開発装置１０１は、開発画面制御部３００、レイアウト定義部３０１、一括作成部３０２、アクション定義部３０３、クエリ定義部３０４、指示引渡処理生成部３０５、記憶部３０６を備えている。
【００３１】
記憶部３０６は、レイアウト定義記憶部３２１、アクション定義記憶部３２２、クエリ定義記憶部３２３を備えている。
【００３２】
開発画面制御部３００は、プログラム開発装置１０１に開発者が操作するための画面を表示し、また開発者の操作に応じて、他の機能部（３０１〜３０５、３１１〜３１５）を機能させる部分である。
【００３３】
レイアウト定義部３０１は、開発者に後述するテキストボックス、ボタン、グリッドオブジェクトなどのオブジェクト、前記複数のオブジェクトなどを１つの表示グループとするためのコンテナを配置させ、また移動、属性編集をさせる機能部である。また、レイアウト定義部３０１で定義されたレイアウト定義は、レイアウト定義記憶部３２１に記憶される。
【００３４】
一括作成部３０２は、ＲＥＳＴ方式のクエリによりＲＥＳＴサーバ１０６から取得したレスポンスデータや、データベースのテーブルのデータ項目（カラム）のうち表示したい項目を、前述の表示グループ（グリッドオブジェクトや後述する明細書形式コンテナ）に対して一括で配置する機能部である。
【００３５】
本発明の実施例においては、データ項目（カラム）に対応するオブジェクトの生成を“一括作成”としているが、これはあくまで例である。必ずしも一括である必要はない。例えば、前述のデータ項目（カラム）のうち表示したい項目を配置する際に、当初はデータ項目名（カラム名）を表示するだけでオブジェクトを作成しなくともよい。この場合、実際のオブジェクトの作成は、例えば属性編集（図１６）において、前述のデータ項目名（カラム名）をユーザが指定する際に、実際のオブジェクトを作成し、ユーザが属性編集しなかったデータ項目名（カラム名）に対しては、レイアウトの保存時にオブジェクトを作成する、など様々な形態が可能である。
【００３６】
一括作成情報受付部３１１は、ＲＥＳＴ方式の場合には、ＲＥＳＴサーバ１０６に対してＲＥＳＴ方式によりレスポンスデータを要求するＵＲＬ、レスポンスデータから表示するデータ項目を指定するマッピング情報、ＳＱＬ文による場合は、対応させるデータベース、データベースを検索するｓｅｌｅｃｔ文（ＳＱＬ文）、パラメータとなる条件項目、さらに前述の表示グループなど、レイアウトを自動生成するための情報を受け付ける機能部である。
【００３７】
カラム名取得部３１２（データ項目取得部）は、ＲＥＳＴ方式の要求とレスポンスにより本発明を実施する場合には、指定されたマッピング情報を解析して、表示グループに配置したいテーブルのデータ項目名（カラム名）を取得する。また、実際にＵＲＬによりＲＥＳＴサーバ１０６にレスポンスデータを要求し、マッピング情報によりレスポンスデータを処理した結果を解析して、データ項目名（カラム名）を取得してもよい。また、ＳＱＬ文により本発明を実施する場合には、ｓｅｌｅｃｔ文を実行し、その結果を解析する。ＳＱＬ文により本発明を実施する場合には、データ項目名（カラム名）自体が、ＲＥＳＴ方式の場合のマッピング情報と同一の役割を果たすものである。
【００３８】
オブジェクト生成部３１３は、前述のデータ項目名（カラム名）に対応して表示グループに配置するオブジェクトを生成する機能部である。
【００３９】
オブジェクト配置部３１４は、前述の生成されたオブジェクトを、表示グループに配置する機能部である。
【００４０】
値設定表示部３１５は、前述の生成されたオブジェクトに、前記ＲＥＳＴ方式によりＲＥＳＴサーバ１０６、または前記ｓｅｌｅｃｔ文を用いてデータベースを実際に検索した結果の値を設定、表示させる機能部である。
【００４１】
アクション定義部３０３は、開発者にボタンがクリックなどされた場合の、前記ＲＥＳＴ方式によるＲＥＳＴサーバ１０６の検索処理、またはＳＱＬ文によるデータベースの検索処理（アクション）などを定義させる機能部である。また、アクション定義部３０３で定義されたアクション定義は、アクション定義記憶部３２２に記憶される。
【００４２】
クエリ定義部３０４は、アクション定義と対応付け、具体的には前記ＲＥＳＴ方式の場合には、レスポンスデータを要求するＵＲＬやレスポンスデータを処理するマッピング情報、ＳＱＬ文による方式の場合には、ｓｅｌｅｃｔ文などの詳細を開発者に定義させる機能部である。また、クエリ定義部３０４で定義されたクエリ定義は、クエリ定義記憶部３２３に記憶される。
【００４３】
指示引渡処理生成部３０５は、後述する、指示受付オブジェクトがユーザにクリックされた際などのパラメータ取得部３３１、要求引渡部３３２に対応する処理を、アクション定義に従って予め生成しておく機能部である。実際には、指示引渡処理生成部３０５は、本図のようにプログラム開発装置１０１に備えられ、アクション定義時に実行され、生成された処理をアクション定義と結びつけて記憶してもよいし、また他の例として、アプリケーションサーバ１０５に備えられ、アプリケーションクライアント１０４に表示する画面の生成時に、指示引渡処理生成部３０５を実行され、前記処理を生成してもよい。いずれの場合も、指示引渡処理生成部３０５で生成された処理は、前記アクション定義に対応するボタンと関連付けてアプリケーションクライアント１０４に表示する画面情報に組み込まれる。
【００４４】
また、プログラム開発装置１０１は、ＲＥＳＴサーバ１０６、またはデータベースサーバ１０３と接続する。あるいは、同一筐体に含む構成であってもよい。さらにプログラム開発装置１０１が備える機能部の一部または全ては、プログラム開発サーバ１０２が備え、プログラム開発装置１０１には、開発者が操作する開発画面が表示され、開発者の操作内容がプログラム開発サーバ１０２に送られ、さらにプログラム開発サーバ１０２での処理結果がプログラム開発装置１０１に戻され、開発者が操作する操作画面に結果として表示するように構成してもよい。この場合には、プログラム開発装置１０１は、ＲＥＳＴサーバ１０６、またはデータベースサーバ１０３と直接は接続せず、プログラム開発サーバ１０２が、ＲＥＳＴサーバ１０６、またはデータベースサーバ１０３と接続することにより、検索結果を取得してもよい。
【００４５】
アプリケーションクライアント１０４は、パラメータ取得部３３１、要求引渡部３３２、結果受付部３３７、結果設定部３３８、表示制御部３３９を備えている。
【００４６】
パラメータ取得部３３１は、アプリケーションクライアント１０４のユーザがボタンをクリックするなどによりアプリケーションサーバ１０５に対する処理を指示した際に、処理に必要なパラメータ値などを取得する機能部である。
【００４７】
要求引渡部３３２は、前述のパラメータ取得部３３１で取得されたパラメータ値などを後述する要求受付部３３３に引き渡す機能部である。
【００４８】
結果受付部３３７は、アプリケーションサーバ１０５での処理結果を後述する結果受渡部３３６から受け付ける機能部である。
【００４９】
結果設定部３３８（当てはめ部）は、前述の結果受付部３３７で受け付けた処理結果を、アプリケーションクライアント１０４上のオブジェクトに設定する機能部である。
【００５０】
表示制御部３３９は、アプリケーションの特定の画面が生成される場合には、アプリケーションサーバ１０５において生成された画面を、アプリケーションクライアント１０４のアプリケーション上に表示する機能部である。また、既に表示されている場合には、前述の結果設定部３３８の設定を表示に反映する。
【００５１】
アプリケーションサーバ１０５は、画面生成部３３０、要求受付部３３３、アクション定義取得部３３４、検索実行制御部３３５、結果受渡部３３６を備え、またプログラム開発装置１０１で定義した記憶部３０６をアプリケーションの実行定義情報として含む。
【００５２】
画面生成部３３０は、アプリケーションクライアント１０４に表示するための画面をレイアウト定義に基づき生成する機能部である。
【００５３】
要求受付部３３３は、前述の要求引渡部３３２からアプリケーションサーバ１０５の処理に必要なパラメータ値などを受け付ける機能部である。
【００５４】
アクション定義取得部３３４は、アプリケーションサーバ１０５を動作させるために必要なアクション定義を取得する機能部である。
【００５５】
検索実行制御部３３５は、アプリケーションクライアント１０４から渡されたパラメータ等に基づいてアプリケーションサーバ１０５を動作させるため機能部である。
【００５６】
結果受渡部３３６（送信手段）は、前述の検索実行制御部３３５の検索結果を、アプリケーションクライアント１０４の結果受付部３３７に受け渡す機能部である。
【００５７】
アプリケーションクライアント１０４およびアプリケーションサーバ１０５に含まれる機能部は、プログラム開発装置１０１あるいはプログラム開発サーバ１０２に含まれていてもよい。これにより開発中の動作確認が可能となる。
【００５８】
図４は、本発明の実施形態のデータベースサーバ１０３のテーブル群の一例を示すデータ構成図であり、後述する開発およびアプリケーションの実行を説明する際に利用するものである。
【００５９】
注文書テーブル４００は、注文結果を登録するテーブルであり、注文番号を表すｏｒｄｅｒＩＤ４０１、顧客名を表すｃｕｓｔｏｍｅｒ４０２、顧客電話番号を表すｔｅｌｅｐｈｏｎｅ４０３、注文受付日を表すｄａｔｅ４０４、注文の合計金額を表すｔｏｔａｌ＿ｐｒｉｃｅ４０５により構成される。
【００６０】
注文品目テーブル４１０は、注文書テーブルのｏｒｄｅｒＩＤ４０１に対応する詳細の注文品目を登録するテーブルであり、注文書テーブルのｏｒｄｅｒＩＤ４０１と対応するｏｒｄｅｒＩＤ４１１と、商品名を表すｐｒｏｄｕｃｔ４１２、商品の単価を表すｐｒｉｃｅ４１３、注文数を表すａｍｏｕｎｔ４１４により構成される。
【００６１】
図５は、本発明の実施形態のデータベースのテーブル群の一例を示すデータ構成図であり、図４と同様後述する開発およびアプリケーションの実行を説明する際に利用するものである。テーブル構成が異なるが、本質的に同じ情報を含む。後述する例において、使用するテーブル構成が異なっても、ｓｅｌｅｃｔ文を書き換えることで同じ動作をさせることが可能であることを説明する。
【００６２】
注文書情報は、注文情報テーブル５００と顧客テーブル５１０に分割され、図４では、注文書テーブル４００のｃｕｓｔｏｍｅｒ４０２およびｔｅｌｅｐｈｏｎｅ４０３は、顧客テーブル５１０のｃｕｓｔｏｍｅｒ５１２およびｔｅｌｅｐｈｏｎｅ５１３として構成されている。両テーブルのレコード（行）は、ｃｕｓｔｏｍｅｒＩＤ５０２とｃｕｓｔｏｍｅｒＩＤ５１１で結びつけられている。リレーショナルデータベースとしての関連付けがされていてもされていなくてもよい。
【００６３】
同様に図４の注文品目テーブル４１０は、注文数テーブル５２０と商品情報テーブル５３０に分割され、注文数テーブルのｐｒｏｄｕｃｔ５２３と、商品情報テーブルのｐｒｏｄｕｃｔ５３１で結びつけられている。
【００６４】
図６は、開発者がレイアウト定義指示を行う画面の一例を示す図であり、プログラム開発装置１０１上に表示される。開発ＧＵＩ６００のヘッダー６０１には、開発者が行う作業毎に画面一覧６０２、レイアウト定義６０３、一括作成情報６０４、アクション定義６０５が表示されている。６０２〜６０５は単なる作業状況を示すものであってもよいし、あるいはタブとして選択し処理内容を移行できてもよいが、あくまで一例である。また本例では作業している内容に従い、６０２〜６０５のタイトルの前に“＊”を表示している。
【００６５】
作成画面一覧６０６には、作成済みの画面が表示されている。今回の説明では、新規画面作成ボタン６０７を指示することにより、開発ＧＵＩ６００ａの構成に変わる。前記指示は、マウスによるクリック、キーボードによる操作などあるが、以降の説明では区別しない。
【００６６】
例では、新規画面として画面名称６１１に“注文確認”と入力し、過去の注文を確認するための画面レイアウトを定義する処理を行う。
【００６７】
作業領域６１２には、初期状態で新規画面のベースとなる明細書形式コンテナ６１３が配置される。
【００６８】
コンテナには、例として１件の情報を１葉で各種データを表示する帳票の作成を主な用途とし、複数の行を挿入可能な“明細書形式コンテナ”と、明細書形式コンテナの中に“行”を追加して、その“行”の中の横方向に複数のオブジェクトなどを並べることが可能な“行形式コンテナ”の２種類を使用可能である。本実施形態の例では、初期状態では前述の通り明細書形式コンテナ６１３が配置される。ただし、初期状態で何も配置されず開発者が明細書形式コンテナ６１３か行形式コンテナを自由に配置できるようにしてもよい。
【００６９】
レイアウト部品６２０には部品ボタンが含まれ、各部品ボタンはコンテナ上に配置できるオブジェクトに対応する。部品ボタンをクリックあるいは、マウスでドラッグアンドドロップすることで、指定のオブジェクトを作業領域６１２に配置済みの他のコンテナ中に配置可能である。例として明細書形式コンテナ作成ボタン６２１、行形式コンテナ作成ボタン６２２、テキスト作成ボタン６２３、テキストボックス作成ボタン６２４、グリッド作成ボタン６２５、ボタン作成ボタン６２６がある。
【００７０】
コマンド６３０には、他の作業に移行する場合のコマンドが含まれ、例えば一括作成情報ボタン６３１、属性編集ボタン６３２、アクション定義ボタン６３３がある。
【００７１】
図７は、開発者がレイアウト定義指示を行う操作手順の一例を簡単に説明するフローである。また図８は、レイアウトを定義する際のコンテナやオブジェクトの配置を示す一例であり、図７の説明に使用する。ここでの説明は、あくまで一例であり、レイアウト定義を途中で中断することや、コンテナやオブジェクトの種類で、配置できないときの警告などは割愛する。
【００７２】
ステップＳ７０１で、図６の新規画面作成ボタン６０７をマウスクリックすることで、明細書形式コンテナ６１３が配置され、レイアウト定義作業を開始する。
【００７３】
次に、開発者は、配置作業の内容として“配置”または“対象の移動”のいずれかを行うかを判断する。現時点では、明細書形式コンテナ６１３上に何も配置されていないため、新しい対象の“配置”しかできないので、ステップＳ７０２で“配置”となり、ステップＳ７０３に進む。例えば、行形式コンテナを追加するためには、まず明細書形式コンテナ６１３をマウスで選択し配置先としてフォーカス（ステップＳ７０３）する。更に図６の行形式コンテナ作成ボタン６２２をマウスクリックすると、図８の明細書形式コンテナ６１３ａの中に階層的に（入れ子状態に）行形式コンテナ８０１が新規作成、挿入される（ステップＳ７０４）。同様の処理を繰り返す（ステップＳ７０６で“ＹＥＳ”と判断する）と行形式コンテナ８０２の下方に行形式コンテナ８０２が追加される（６１３ｂ）。
【００７４】
次に行形式コンテナ８０２をフォーカス（ステップＳ７０３）してから、図６の明細書形式コンテナ作成ボタン６２１あるいは、テキストボックス作成ボタン６２４などオブジェクトを配置するボタンを選択し、コンテナあるいはオブジェクト８１１を新規作成、挿入（ステップＳ７０４）することができる（６１３ｃ）。同様にコンテナあるいはオブジェクト８１２を配置することができる（６１３ｄ）。行形式コンテナ内での配置は、横方向に可能である。ここでベースになる明細書形式コンテナ６１３からは３階層目の位置にコンテナ又はオブジェクトが配置される。このように、コンテナは階層的に配置していくことが可能である。
【００７５】
次に明細書形式コンテナ６１３ｄを選択して行形式コンテナ作成ボタン６２２をマウスクリックすると、行形式コンテナ８０３が新規作成、挿入される（６１３ｅ）。
【００７６】
更に配置作業を継続する（ステップＳ７０６で“ＹＥＳ”と判断する）が、今度は、対象の移動を実施する（ステップＳ７０２で“対象の移動”と判断）。
【００７７】
対象の移動は、例えば行形式コンテナ８０３をドラッグし、行形式コンテナ８０１と行形式コンテナ８０２の間に移動してドロップする（ステップＳ７０５、図８の８２１の移動）。この時、行形式コンテナ８０２内に配置されているコンテナまたはオブジェクト８１１は、行形式コンテナ８０２の入れ子として定義されているため、行形式コンテナ８０２に伴って移動する。
【００７８】
同様にドラッグアンドドロップにより、コンテナまたはオブジェクト８１１と８１２を入れ替えることも可能である（図８の８２２の移動）。
【００７９】
以上の説明では、外側にあるコンテナを選択して、内側に他のコンテナ（あるいはオブジェクト）を最後の行、最右の位置に追加したが、例えば、明細書形式コンテナ６１３ｄの行形式コンテナ８０１と行形式コンテナ８０２の間を選択し、行形式コンテナ作成ボタン６２２をクリックすると、行形式コンテナ８０３が新規作成、挿入されるようにしてもよい。上記の説明はあくまで一例である。
【００８０】
以上でレイアウト定義作業について説明したが、本例で示したコンテナ、あるいはグリッドオブジェクトを内部に複数の項目を表示できるという意味で、“表示グループ”と呼び、レイアウトの一括作成の例として使用する。階層的には、如何に深い位置にあっても同様に対応可能である。
【００８１】
図９は、明細書形式コンテナにおける、一括作成によるレイアウトの自動作成を説明するための図である。
【００８２】
開発ＧＵＩ６００のコマンド６３０において、一括作成情報ボタン６３１を選択すると、一括作成のための情報を指定する画面に移行する。ここでは、接続先ＤＢ指定フィールド９０１およびＳＱＬ指定フィールド９０２を指定するテキスト入力フィールドがある。ただし、本発明に係わるプログラム開発装置１０１、あるいはプログラム開発サーバ１０２において、アプリケーション開発に係わるデータベースサーバ１０３を特定し、一括作成情報６０４においては、接続先ＤＢ指定フィールド９０１は指定不要としてもよい。さらにデータベースを指定する場合でも、プログラム開発装置１０１、あるいはプログラム開発サーバ１０２にデータベースサーバ１０３が同一の筐体に一体化した構成であってもよいことは前述したとおりである。また、実際に開発したアプリケーションが動作する際に接続するデータベースサーバ１０３は異なるものでもよい。画面のレイアウトを生成することが目的であるため、同じ構成あるいは同一のデータ項目（カラム）を取得できる構成であればよい。
【００８３】
ＳＱＬ指定フィールド９０２においては、ｓｅｌｅｃｔ文を指定する。９０４は、ＳＱＬ指定フィールド９０２に図４の注文書テーブル４００に対応するｓｅｌｅｃｔ文、“select * from 注文書テーブル”が指定されている。
【００８４】
ｓｅｌｅｃｔ文を指定し、一括作成後のオブジェクト表示先であるコンテナを、ユーザにマウスでフォーカスさせるなどして指定（表示グループ指示手段）した後、一括作成ボタン９０３をクリックすると、明細書形式コンテナ６１３ａのように注文書テーブル４００のデータ項目（カラム）と同数（５個）の行形式コンテナ９０６ａ〜９０６ｅが自動生成され、更に行形式コンテナ９０６ａ〜９０６ｅ内に１つずつテキストボックスが生成され、各区テキストオブジェクトのラベルには、注文書テーブル４００のデータ項目名（カラム名）であるｏｒｄｅｒＩＤ、ｃｕｓｔｏｍｅｒなどが設定される。
【００８５】
ここで、データ項目（カラム）と同数（５個）の行形式コンテナ９０６ａ〜９０６ｅおよび対応するテキストボックスが生成、配置されたのは、９０４のｓｅｌｅｃｔ文のｓｅｌｅｃｔ句（ｓｅｌｅｃｔ文実行結果として取得するデータ項目名（カラム名）を記載する部分）が“＊”であることによる。すなわち、実際にテーブルのスキーマを確認し、全てのデータ項目名（カラム名）を取得し、それらに対して生成、配置したためである。
【００８６】
次に９０５では、ｓｅｌｅｃｔ句に“＊”を指定せず、３つのデータ項目名（カラム名）“ｏｒｄｅｒＩＤ”、“ｃｕｓｔｏｍｅｒ”、“ｄａｔｅ”を具体的に指定している。これに基づいて、明細書形式コンテナ６１３ｂの通り、３個の行形式コンテナ９０６ｆ〜９０６ｈとテキストボックスを生成、配置する。この場合、接続先ＤＢ指定フィールド９０１で指定されたデータベースサーバ１０３に必ずしも接続する必要はない。例えば、ｓｅｌｅｃｔ句に記載されたデータ項目名（カラム名）に従ってのみ前述の自動生成、配置を行ってもよい。また、指定されたデータ項目名（カラム名）が実在のものか（例えばスペリングミスがないか）などを確認するために、データベースサーバ１０３に接続してもよい。
【００８７】
更に、ｓｅｌｅｃｔ文の指定方法は、データベースの構成に従って変更可能である。例えば、図５のテーブル構成であれば、ｓｅｌｅｃｔ文を次のように定義することで同様の結果を得ることができる。
【００８８】
“select
注文情報テーブル.orderID,顧客テーブル.customer,注文情報テーブル.date from 注文情報テーブル,顧客テーブル where 注文情報テーブル.customerID=顧客テーブル.customerID”
【００８９】
また、開発時と本番運用時のテーブル構成が異なっていてもよい。
【００９０】
また、行形式コンテナ９０６ａ〜９０６ｈに含まれるいずれのオブジェクトに、実際の検索結果が表示される。これにより開発作業時に、実際のレイアウトを確認しながらレイアウト調整を行ったり、接続先ＤＢ指定フィールド９０１およびＳＱＬ指定フィールド９０２の指定を確認したりすることが可能となる。
【００９１】
図１０は、グリッドオブジェクトにおける、一括作成によるレイアウトの自動作成を説明するための図である。グリッドオブジェクトは、２次元の行列形式でデータを表示する表形式のオブジェクトである。
【００９２】
ここでは、データベースサーバ１０３のデータ項目名（カラム名）を表の先頭行にヘッダーとして表示し、１行毎に検索結果のレコードを挿入していく。
【００９３】
図１０では、レイアウト定義操作により、既に明細書形式コンテナ６１３内に、行形式コンテナ１００１、さらにその中にグリッドオブジェクト１００２が配置されている前提で説明する。
【００９４】
ＳＱＬ指定フィールド９０２には、１００３とおり“select * from 注文品目テーブル”と指定する。
【００９５】
ｓｅｌｅｃｔ文を指定し、一括作成後のオブジェクト表示先であるグリッドオブジェクトを、マウスでフォーカスするなどして指定（表示グループ指示手段）した後、一括作成ボタン９０３をクリックすると、グリッドオブジェクト１００２内には、注文品目テーブルに含まれる全てのデータ項目（カラム：本例では４個）が、列方向に並ぶ。全てのデータ項目（カラム）が表示されるのは図９での説明と同様である。
【００９６】
一括作成が完了した後は、グリッドオブジェクト１００２ａのように２次元の行列（表形式）で表示される。ヘッダーの他に、注文品目テーブル４１０のデータ項目（カラム）が１００４ａ〜１００４ｄに並び、また実際のデータのうち、例えば指定した数（グリッドオブジェクト１００２ａの例では５レコード）分のデータが表示される。５レコードと指定するのは、レイアウト定義の操作時において検索条件を指定していないためであり、運用時には、上下に移動するスクロールバーが表示されて、検索結果の全データを設定する。
【００９７】
さらに図９で説明と同様、図５のテーブル構成である注文数テーブル５２０、商品情報テーブル５３０を用いたｓｅｌｅｃｔ文を指定しても同じ結果を得ることができる。
【００９８】
図１１は、また、グリッドオブジェクトにおける、一括作成によるレイアウトの自動作成を説明するための図であり、ｓｅｌｅｃｔ句において、“＊”を使用せず、検索結果として得るデータ項目名（カラム名）を明示した場合の例である。明示したデータ項目（カラム）だけが１行に並んで表示される。
【００９９】
詳細は、ｓｅｌｅｃｔ句に関する部分については、図９の９０５のｓｅｌｅｃｔ文を用いて明細書形式コンテナ６１３ｂを生成する部分、グリッドオブジェクト１００２、１００２ｂに関する部分については、図１０の説明と同じであるため省略する。
【０１００】
図１２は、明細書形式コンテナの一括作成後、更にグリッドオブジェクトの一括作成をする例を示す図である。
【０１０１】
図９で一括作成した明細書形式コンテナ６１３ａ、６１３ｂに対しても図７，図８で説明したように、さらにコンテナまたはオブジェクトを追加することができる。図１２では、明細書形式コンテナ６１３に行形式コンテナ１２０１を追加し、既存の行形式コンテナ１２０２と上下を入れ替える。さらに行形式コンテナ１２０１にグリッドオブジェクト１００２を追加する。
【０１０２】
図１３は、明細書形式コンテナの一括作成後、グリッドオブジェクトの一括作成を実施した結果の例を示す図である。すなわち、図１２でレイアウト定義を行った後、グリッドオブジェクト１００２に対して、図１１と同じ一括作成を実行した結果である。
【０１０３】
ただし、右上の“ｂｕｔｔｏｎ１”は、一括作成されたものではなく、開発者が別途追加するものである。後述の説明で使用する。
【０１０４】
図１４は、本発明の実施形態における一括作成部の処理の一例を示すフローチャートである。すなわち、図９〜図１２において、開発者がプログラム開発装置１０１上の一括作成情報の画面で一括作成に必要なコンテナまたはグリッドオブジェクト、接続先ＤＢ指定フィールド９０１、ＳＱＬ指定フィールド９０２を指定し、一括作成ボタン９０３をマウスクリックした後に、プログラム開発装置１０１のＣＰＵ２０１が、各ステップを実行する。あるいは、前述の通りプログラム開発装置１０１における開発者の操作指示を受け付けて、実際のプログラム生成処理をプログラム開発サーバ１０２が行う場合は、プログラム開発サーバ１０２のＣＰＵ２０１が各ステップを実施する。
【０１０５】
ステップＳ１４０１においては、一括作成ボタン９０３がクリックされた際に選択されている明細書形式コンテナ（例えば図９の明細書形式コンテナ６１３として説明を進める）または、グリッドオブジェクト（例えば図１２のグリッドオブジェクト１００２として説明を進める）のＩＤを取得する（表示グループ受付手段）。ここで明細書形式コンテナ６１３のＩＤを“ｃｏｎｔｅｎａＡ”、グリッドオブジェクト１００２のＩＤを“ｇｒｉｄＢ”とする。
【０１０６】
ステップＳ１４０２においては、接続先ＤＢ指定フィールド９０１で指定されたデータベースを取得し、オープンする。
【０１０７】
ステップＳ１４０３においては、ＳＱＬ指定フィールド９０２を指定されたｓｅｌｅｃｔ文を取得し、ｓｅｌｅｃｔ句の記載（ｓｅｌｅｃｔ文実行結果として取得するデータ項目名（カラム名）を記載する部分）を取得する。
【０１０８】
ステップＳ１４０４においては、指定されたｓｅｌｅｃｔ文を実行し、結果からデータ項目名（カラム名）を全て取得しカラムリストを生成する。
【０１０９】
ステップＳ１４０７においては、データ表示先の表示グループ（前述の“ｃｏｎｔｅｎａＡ”または“ｇｒｉｄＢ”に対応するコンテナ、またはオブジェクト）が、明細書形式コンテナか、グリッドオブジェクトかにより分岐する。
【０１１０】
ここでは、明細書形式コンテナ“ｃｏｎｔｅｎａＡ”が選択されているとして、ステップＳ１４１１に進む。ステップＳ１４１１からステップＳ１４１８までのループ処理においては、前述のカラムリストに含まれる各データ項目（カラム）に対応するオブジェクトを表示グループ（本例では“ｃｏｎｔｅｎａＡ”）に追加する処理を行う。また、カラムリストの例としては、図９の９０５におけるｓｅｌｅｃｔ文から生成された“ｏｒｄｅｒＩＤ”、“ｃｕｓｔｏｍｅｒ”、“ｄａｔｅ”の３個のデータ項目（カラム）を含むものとする。
【０１１１】
ステップＳ１４１２においては、カラムリストに含まれる１つのデータ項目（カラム）に着目する（最初は“ｏｒｄｅｒＩＤ”）。
【０１１２】
ステップＳ１４１３においては、行形式コンテナを生成し、“ｃｏｎｔｅｎａＡ”に追加する。さらにステップＳ１４１４においては、テキストボックスオブジェクトを１つ生成する。ステップＳ１４１５において、前記生成したテキストボックスオブジェクトのラベルに、着目中のデータ項目名（カラム名：ここでは“ｏｒｄｅｒＩＤ”）を設定する。また、ステップＳ１４１６においては、前記生成したテキストボックスオブジェクトのＩＤにも、着目中のデータ項目名（カラム名。ここでは“ｏｒｄｅｒＩＤ”）を設定する。
【０１１３】
ステップＳ１４１７においては、前記生成したオブジェクトをステップＳ１４１３で生成した行形式コンテナに挿入する。ステップＳ１４１８においてループ処理の１回目が終了する。ここまでの処理で図９の明細書形式コンテナ６１３ｂ、行形式コンテナ９０６ｆおよびその中の“ｏｒｄｅｒＩＤ”が生成されたことになる。
【０１１４】
ここで、実際のレイアウト定義記憶部３２１の説明をし、図１４のフローチャートの生成結果の構成を合わせて説明する。
【０１１５】
図１５は、一括作成した結果を含む、レイアウト定義記憶部３２１におけるレイアウト定義のデータ構成の一例を示す図である。
【０１１６】
テーブル１５００は、開発者により定義されたレイアウトおよび一括作成により定義されたレイアウトのいずれも含む例である。
【０１１７】
画面ＩＤ１５０１は、新規画面作成ボタン６０７がクリックされたときに開発中のアプリケーション中で画面に一意的に対応付けられる番号であり、現在作成している画面には“ＵＩ００１”が対応付けられている。表示グループ１５０２には例として、明細書形式コンテナまたはグリッドオブジェクトなどが登録される。説明の現時点では、“ｃｏｎｔｅｎａＡ”が登録されている（“ｇｒｉｄＢ”はこの時点では作成されていない）。
【０１１８】
接続先ＤＢ１５０３、ＳＱＬ１５０４は、一括作成によりレイアウトが定義された場合に登録される情報であり、接続先ＤＢ指定フィールド９０１、ＳＱＬ指定フィールド９０２で指定されたものが対応する。画面レイアウトの一括作成のためだけであれば記憶しておく必要はない。ただし、後述するとおり、一括作成の結果として、実際のデータベースからデータを検索し、表示グループ上に具体的な値を表示させるために記憶しておいてもよい（ここでは記憶することにする）。
【０１１９】
行／列１５０５は、表示グループ（ここでは明細書形式コンテナまたはグリッドオブジェクト）に配置される行形式コンテナ、または列オブジェクトである。行形式コンテナも表示グループの１種であり、表示グループ１５０２に登録する情報として扱ってもよいが、本構成例としては、別の項目として指定する。
【０１２０】
また、オブジェクト情報として種類１５０６としてオブジェクトの種類、ＩＤ１５０７としてオブジェクトＩＤ、Ｌａｂｅｌ１５０８としてオブジェクトのラベルが登録される。
【０１２１】
説明をステップＳ１４１８が完了した時点に戻す。ここでは、テーブル１５００の最上行のみが登録されている。すなわち、行／列１５０５としては、ステップＳ１４１３で生成した行形式コンテナに“ｌｉｎｅＡ１”というＩＤが付与され登録されている。また、オブジェクト情報には、種類１５０６として“ｔｅｘｔｂｏｘ”、ＩＤ１５０７として“ｏｒｄｅｒＩＤ”、Ｌａｂｅｌ１５０８として同じく“ｏｒｄｅｒＩＤ”が登録される（初期状態では、オブジェクトＩＤとラベルが同じため）。
【０１２２】
説明を再び図１４に戻す。ここでステップＳ１４１８まで完了したため、ステップＳ１４１１に戻り、ループ処理を繰り返し、データ項目（カラム）“ｃｕｓｔｏｍｅｒ”、“ｄａｔｅ”に対してステップＳ１４１１からステップＳ１４１８までの処理が繰り返し実行される。
【０１２３】
図１５において、データ項目（カラム）“ｃｕｓｔｏｍｅｒ”に対しては、行／列１５０５の“ｌｉｎｅＡ２”に対応する情報が、データ項目（カラム）“ｄａｔｅ”に対しては、行／列１５０５の“ｌｉｎｅＡ４”に対応する情報が登録される。
【０１２４】
“ｌｉｎｅＡ１”の“ｂｕｔｔｏｎ１”と、“ｌｉｎｅＡ３”の“ｇｒｉｄＢ”に関しては、後で開発者の操作により追加されるものなので、この段階では存在しない。
【０１２５】
ステップＳ１４１９においては、ＳＱＬ１５０４に登録されたｓｅｌｅｃｔ文により１行のデータを取得し、ステップＳ１４２０において、前記ｓｅｌｅｃｔ文により検索した結果を表示する。ｓｅｌｅｃｔ文の検索結果であるデータ項目名（カラム名）と、テキストボックスのオブジェクトＩＤが対応（一致）しているため、各データ項目（カラム）の値の登録先が特定される。これによりフローチャートの分岐の一方が完了する。
【０１２６】
以上の処理結果が、図９の６１３ｂとなり、行形式コンテナ９０６ｆ〜９０６ｈおよびその中のテキストボックスと、対応する値が表示される。
【０１２７】
さて、次に現在、図１２のレイアウト定義の状態になっているとする。図１５においては、行／列１５０５に“ｌｉｎｅＡ３”と“ｇｒｉｄＢ”が追加されている。
【０１２８】
ここで図１１における１１０１のｓｅｌｅｃｔ文を指定し、グリッドオブジェクト１００２（オブジェクトＩＤは“ｇｒｉｄＢ”）を選択して、一括作成ボタン９０３をクリックすることで実行される、図１４のフローチャートを再度説明する。
【０１２９】
ステップＳ１４０１〜ステップＳ１４０３は同じなので説明を省略する。ステップＳ１４０４では、１１０１のｓｅｌｅｃｔ文のｓｅｌｅｃｔ句から、３つのデータ項目（カラム）“ｐｒｏｄｕｃｔ”、“ｐｒｉｃｅ”、“ａｍｏｕｎｔ”を含むカラムリストが生成される。
【０１３０】
ステップＳ１４３１からステップＳ１４３７までのループ処理においては、前述のカラムリストに含まれる各データ項目（カラム：ここでは、“ｐｒｏｄｕｃｔ”、“ｐｒｉｃｅ”、“ａｍｏｕｎｔ”）に対応するオブジェクトを表示グループ（本例では“ｇｒｉｄＢ”）に追加する処理を行う。
【０１３１】
ステップＳ１４３２においては、カラムリストに含まれる１つのデータ項目（カラム）に着目する（最初に“ｐｒｏｄｕｃｔ”）。
【０１３２】
ステップＳ１４３３においては、１列分の列オブジェクトを生成する。ステップＳ１４３４においては、列オブジェクトのＩＤに、着目中のデータ項目（カラム名。こでは“ｐｒｏｄｕｃｔ”）を設定する。またステップＳ１４３５においては、前記生成した列オブジェクトのラベルにも、着目中のデータ項目名（カラム名。ここでは“ｐｒｏｄｕｃｔ”）を設定する。
【０１３３】
ステップＳ１４３６においては、前記生成した列オブジェクトをグリッドオブジェクト（“ｇｒｉｄＢ”に追加する。ステップＳ１４３７においてループ処理の１回目が終了する。
【０１３４】
これにより図１５のテーブル１５００において、行／列１５０５に“ｃｕｌｕｍｎＢ１”が登録される。種類１５０６は“ｃｕｌｕｍｎ”（列オブジェクトであることを示す）、ＩＤ１５０７が“ｐｒｏｄｕｃｔ”、Ｌａｂｅｌ１５０８が“ｐｒｏｄｕｃｔ”として登録される。
【０１３５】
ここでステップＳ１４３７まで完了したため、ステップＳ１４３１に戻り、ループ処理を繰り返し、データ項目（カラム）“ｐｒｉｃｅ”、“ａｍｏｕｎｔ”に対してステップＳ１４３１からステップＳ１４３７までの処理が繰り返し実行される。
【０１３６】
図１５において、データ項目（カラム）“ｐｒｉｃｅ”に対しては、行／列１５０５の“ｃｕｌｕｍｎＢ２”に対応する情報が、データ項目（カラム）“ａｍｏｕｎｔ”に対しては、行／列１５０５の“ｃｕｌｕｍｎＢ３”に対応する情報が登録される。
【０１３７】
ステップＳ１４３８からステップＳ１４４１までにおいて、グリッドオブジェクト（“ｇｒｉｄＢ”）に値を設定表示する。例えば、“５行分を表示する”というように表示レコード数が指定されているとする。
【０１３８】
ステップＳ１４３９においては、ｓｅｌｅｃｔ文により得られる検索結果のとして、１行分を取得する。ステップＳ１４４０においては、前記取り出した１行分のレコードをグリッドオブジェクトの１行になるように、また検索結果のデータ項目名（カラム名）に対応する値をグリッドの対応するオブジェクトＩＤを持つ列オブジェクトに設定していく。
【０１３９】
例えばこれを５レコード分繰り返すことで、ステップＳ１４３８からステップＳ１４４１までのループ処理が完了し、図１３のグリッドオブジェクト１００２の表示結果となる。
【０１４０】
ただし、前述の通り右上の“ｂｕｔｔｏｎ１”は現時点では存在しない。なお、前述の通り、本フローチャートの説明で使用した接続先ＤＢ指定フィールド９０１で指定されたデータベースは、プログラム開発装置１０１と同一の装置に備わるデータベースサーバ１０３でもよいし、ネットワーク１０７上のデータベースサーバ１０３ａ、インターネット上のデータベースサーバ１０３ｂのいずれでもよい。以上で図１４のフローチャートの説明を完了する。
【０１４１】
なお、テキストボックスのオブジェクトあるいは、グリッドオブジェクトにおける列オブジェクトを図１４のフローチャートにおいて、全て作成している。しかし、前述の一括作成部３０２で説明したとおり、この処理はあくまで一例であり、実際には、属性編集やレイアウトの保存のタイミングで生成してもよい。一括作成もそうではない場合も、本発明における“データ項目に対応する値を表示するためのオブジェクトを作成するオブジェクト作成手段”であるものとする。
【０１４２】
図１５については、図１４とともに説明したが、前述したとおり一括作成された定義だけではなく、開発者による定義も含まれる。
【０１４３】
例えば、図１３の１行目の行形式コンテナにボタン作成ボタン６２６をクリックすることによりボタンオブジェクト“ｂｕｔｔｏｎ１”を１つ追加すると、行／列１５０５の“ｌｉｎｅＡ１”の行に、“ｂｕｔｔｏｎ１”が登録される。ここで、図１３等に示したように、各オブジェクト（テキストボックス、ボタンなど）は、プログラム開発装置１０１またはプログラム開発サーバ１０２が指定したままの値がラベルとして表示される。
【０１４４】
図１６は、オブジェクトの属性編集するための属性編集画面の一例を示す図である。例えばレイアウト定義画面（図１３）においてテキストボックス“ｏｒｄｅｒＩＤ”（１３０１）にフォーカスし、属性編集ボタン６３２をクリックすると、図１６の画面に遷移し、“ｏｒｄｅｒＩＤ”の各種属性を変更できる。編集対象ＩＤは、１６０１に“ｏｒｄｅｒＩＤ”であることが示されている。ここでは、例としてＬａｂｅｌの表示文字列１６０２を“注文番号”に変更している。その他、例としてフォント、文字サイズ、カラー（文字色）、テキストボックスに実際に入る値のデータ型（数値、文字列など）の指定などを指定できる。これらの項目は、オブジェクトの種類によって異なっていてもよい。また、コンテナについても属性編集可能としてもよい。コンテナの場合であれば、例えば枠の表示（色、太さ、立体感）、コンテナ自体へのラベル付与、などが考えられる。
【０１４５】
また、図１５のレイアウト定義においては、これらの詳細の属性は記載していなかったが、これらもレイアウト定義部に記憶してもよい。また対応付けて別の記憶部に記憶してもよい。
【０１４６】
図１７は、オブジェクトの属性編集結果が反映されたレイアウト定義のデータ構成の一例を示す図である。図１７のＬａｂｅｌ１５０８に図１６の属性編集で変更した結果が登録されている。
【０１４７】
図１８は、一括作成とオブジェクトの属性編集を実施した画面の一例を示す図である。図１３に対して、オブジェクトのラベル（グリッドオブジェクト１００２の列オブジェクトを含む）を変更した結果である。
【０１４８】
以上により、ｓｅｌｅｃｔ文を用いて、プログラム開発装置１０１における開発者によるレイアウト定義、レイアウト定義の一括作成を行う操作、およびプログラム開発装置１０１またはプログラム開発サーバ１０２が、レイアウト定義を一括作成する処理動作の実施形態の一例の説明を完了する。
【０１４９】
次に、前述の通りレイアウト定義された画面に、データベース検索結果の値を設定するアクション定義と、アクション定義により開発されたアプリケーションの動作について説明する。
【０１５０】
図１９は、開発者がアクション定義を行う画面の一例を示す図である。アクション定義には、引き続きプログラム開発装置１０１を用いる。本例では、開発ＧＵＩ６００のアクション定義６０５により、アクションを定義するものとして説明する。
【０１５１】
前述の通り、実際の開発作業（アクション定義操作）を進めるにあたり、プログラム開発装置１０１単体で動作可能であってもよい。
【０１５２】
アクション定義１９０１には、アクション定義の対象となっているオブジェクトＩＤと、そのラベルが表示されている。ここでは、図１３で定義したオブジェクトＩＤ“ｂｕｔｔｏｎ１”が表示されている（ラベルは“検索”と変更されている）。
【０１５３】
アクション定義領域１９０２には、当初は１つのクエリ定義が可能な１行分のテキストボックスが表示されている。１つのクエリ定義に必要な情報は、クエリ名指定フィールド１９０３、条件項目指定フィールド１９０４、表示グループ指定フィールド１９０５の３つである。１つのアクション定義には、複数のクエリ定義を含むことが能であり、そのためには、前述のクエリ定義用の行を追加する必要がある。例えば、画面下方のクエリ追加ボタン１９１６をクリックして行を追加してもよいし、１つの行に入力を開始したタイミングなど何らかのイベントにより、予め空白の１行を追加するようにしてもよい。
【０１５４】
クエリ名指定フィールド１９０３は、アクション定義と後述するクエリ定義を関連付けるためのものである。ここでは名前を付けて開発者に分かりやすくしているが、内部情報としては単なるクエリＩＤでもよい。図２０、図２１のテーブルでは、ｑｕｅｒｙＩＤとして対応付けている。クエリ名で対応付ける、あるいは開発者にクエリＩＤを直接みせても定義上問題はない。あくまで本画面、図２０、図２１の構成はあくまで一例に過ぎない。
【０１５５】
条件項目指定フィールド１９０４は、後述するクエリ定義内にあるｓｅｌｅｃｔ文が、パラメータを含む形式で記載されている場合、そのパラメータに渡すための値を表示グループ上のどのテキストボックスから取得するか、など値を指定可能なオブジェクトを指定するものである。例として“ｉｄ＝ｏｒｄｅｒＩＤ”が指定されているので、図１８の画面では、式の右辺“ｏｒｄｅｒＩＤ”（ラベルは“注文番号”に変更してある）から取得して、式の左辺であるパラメータ“ｉｄ”に値を渡す。
【０１５６】
表示グループ指定フィールド１９０５は、クエリ定義で指定した検索結果により得られる値を、どの表示グループに設定、表示させるかを指定する項目である。１行目に指定されている“ｃｏｎｔｅｎａＡ”は、例えば図１８の明細書形式コンテナ６１３に対応しており、また図１５のレイアウト定義情報からは、“ｃｏｎｔｅｎａＡ”上のオブジェクトとして（データベースのデータ項目（カラム）に対応するものとしては）“ｏｒｄｅｒＩＤ”、“ｃｕｓｔｏｍｅｒ”、“ｄａｔｅ”があると分かる。実際の動作は、図２２にて説明する。
【０１５７】
クエリ定義領域１９１１は、アクション定義領域１９０２で指定するクエリ名指定フィールド１９０３に対応する表示の他に、検索ＤＢ指定フィールド１９１２、パラメータ指定フィールド１９１３、タイプ指定フィールド１９１４、ｓｅｌｅｃｔ文指定フィールド１９１５から構成されている。
【０１５８】
検索ＤＢ指定フィールド１９１２は、後述のクエリ定義で指定したクエリを実際に実行する際に接続するデータベースサーバ１０３上のデータベースを指定する。ただし、本発明に係わるアプリケーションクライアント１０４またはアプリケーションサーバ１０５においてデータベースサーバ１０３上のデータベースを特定し、クエリ定義毎に検索ＤＢ指定フィールド１９１２は指定不要としてもよい。なお、データベースサーバ１０３は、アプリケーションサーバ１０５と同一の筐体に一体化した構成として動作していてもよいし、ネットワーク１０７上のデータベースサーバ１０３ａでも、インターネット上のデータベースサーバ１０３ｂでもよい。
【０１５９】
パラメータ指定フィールド１９１３は、アクション定義領域１９０２の条件項目指定フィールド１９０４の内容と対応する情報を記載する。すなわち、後述するアプリケーションの動作において、条件項目指定フィールド１９０４で指定されたテキストボックス（例では“ｏｒｄｅｒＩＤ”）、その他値を設定可能なオブジェクトから値を取り出し、その値を指定のパラメータ（例では“ｉｄ”）に結びつける。
【０１６０】
タイプ指定フィールド１９１４は、パラメータで渡される値のデータ型を指定する。後述のようにパラメータを複数記載可能とする場合には、データ型も順序を合わせて複数記載可能とする。
【０１６１】
ｓｅｌｅｃｔ文指定フィールド１９１５には、実際に検索に使用するｓｅｌｅｃｔ文が記載されている。ただし、一部にパラメータを含むことが可能である。パラメータに対応する部分には、“：”など指定された記号を付与し、例えば本例では、“：ｉｄ”と記載された部分がパラメータであり、前述の“ｉｄ”と結びつけられた値（もとは“ｏｒｄｅｒＩＤ”から取得した値）を代入する。
【０１６２】
図１９の例では、条件項目指定フィールド１９０４、パラメータ指定フィールド１９１３の記載は１つとなっているが、例えば“，”や空白区切りで複数指定できるようにしてもよい。条件項目指定フィールド１９０４自体を複数用意してもよい。さらに、クエリ定義側でパラメータ指定フィールド１９１３を用意しなくても、例えばアクション定義側で指定した順番に応じて、必ず１番目の条件項目は“ｐｒａｒａｍ１”、２番目の条件項目は“ｐａｒａｍ２”が受け取るよう対応付けられていてもよい。
【０１６３】
また、本例で、アクション定義とクエリ定義を分離しているのは、ｓｅｌｅｃｔ文はデータベース検索式として汎用性が高く、１つのクエリ定義を様々なアクション定義から再利用するためである。図２０においても説明する。再利用しない構成として、アクション定義の中の１行に直接、検索ＤＢ指定フィールド１９１２、ｓｅｌｅｃｔ文指定フィールド１９１５を指定する方法をとってもよい。また、その場合、後述する図２０と図２１のテーブルを１つのテーブル構成にしてもよい。
【０１６４】
図１９では、１つのオブジェクト（本例では“検索”ボタン）に対してアクション定義を行ったが、アクション定義完了後、もとのレイアウト定義画面に戻り別のオブジェクトを指定して再度アクション定義画面に来ることで、１つの画面上の複数オブジェクトにアクションを定義可能である。
【０１６５】
更に、ｓｅｌｅｃｔ文の指定方法は、データベースの構成に従って変更可能である。例えば、図５のテーブル構成であれば、次のｓｅｌｅｃｔ文を指定することで同様の結果を得ることができる。
【０１６６】
“select
注文情報テーブル.orderID,顧客テーブル.customer,注文情報テーブル.date from 注文情報テーブル,顧客テーブル where 注文情報テーブル.customerID=顧客テーブル.customerID AND 注文情報テーブル.orderID=:id”
【０１６７】
従って、開発時と本番運用時のテーブル構成が異なっていてもよい。
【０１６８】
図２０は、アクション定義のデータ構成の一例を示す図である。
【０１６９】
アクション定義テーブル２０００においては、アクション定義したボタンなどが配置されている画面の画面ＩＤ２００１が登録されている。ただし、ｏｂｊｅｃｔＩＤ（ボタンのＩＤ）や表示グループ２００６などから一意的に特定できるのであればなくても良い。
【０１７０】
実行順２００３は、１つのオブジェクトに複数のクエリを定義した際の実行順の指定である。図１９での指定例では、“ｂｕｔｔｏｎ１”に対して、２つのクエリ“ｑｕｅｒｙ００１”、“ｑｕｅｒｙ００２”が定義され、その順で実行されることになる。
【０１７１】
また、“ｑｕｅｒｙ００１”は、“ｂｕｔｔｏｎ１”以外に“ｂｕｔｔｏｎ３”からのアクション定義でも再利用されていることが分かる。その他の項目については、図１９のアクション定義で指定した項目をそのまま登録しているので説明を省略する。
【０１７２】
図２１は、クエリ定義のデータ構成の一例を示す図である。図２０のアクション定義テーブル２０００のｑｕｅｒｙと対応付けるためにｑｕｅｒｙＩＤ２１０１を用いる。それ以外については、図１９のクエリ定義領域１９１１で指定した項目をそのまま登録しているので説明を省略する。
【０１７３】
図２２は、本発明の実施形態におけるアクションの実行処理の一例を示すフローチャートである。
【０１７４】
本処理は、アプリケーションサーバ１０５の画面生成部３３０により生成された画面が、既にアプリケーションクライアント１０４に表示されており、その画面においてユーザ操作により指示受付オブジェクトがクリックされた前提で実行されるアプリケーションの動作の説明である。
【０１７５】
ステップＳ２２０１からステップＳ２２０７までは、アプリケーションクライアント１０４のＣＰＵ２０１が、各ステップを処理する。また、ステップＳ２２１１からステップＳ２２２０までは、アプリケーションサーバ１０５のＣＰＵ２０１が各ステップを処理する。またアプリケーションサーバ１０５は、データベースサーバ１０３に接続している。なお、アプリケーションクライアント１０４ａ、アプリケーションサーバ１０５ａ、データベースサーバ１０３ａは、ネットワーク１０７に存在してもよいし、アプリケーションクライアント１０４ｂ、アプリケーションサーバ１０５ｂ、データベースサーバ１０３ｂは、インターネット上に存在してもよい。また、アプリケーションサーバ１０５とデータベースサーバ１０３は同一の情報処理装置であってもよい。
【０１７６】
ステップＳ２２０１においては、アプリケーションクライアント１０４において、ユーザがアクション定義と関連付けられたボタンなどのオブジェクトをクリックした際に、後述する図２３のフローチャートで生成された処理が実行される。クリックされたボタンなど（指示受付オブジェクトという）のオブジェクトＩＤ（指示受付オブジェクトＩＤ）と、図１９の条件項目指定フィールド１９０４で指定されたオブジェクト（条件項目オブジェクトという）から値（条件値と呼ぶ）を取得する。
【０１７７】
ステップＳ２２０２においては、ステップＳ２２０１で取得した指示受付オブジェクトのオブジェクトＩＤと条件値と、さらに図２３で生成された処理に記憶されたｑｕｅｒｙＩＤを、アプリケーションサーバ１０５側に引き渡す。ステップＳ２２０１とステップＳ２２０２の処理については、図２３で説明する処理を、予めクライアント側の画面に組み込んでおき実行する。
【０１７８】
ステップＳ２２１１においては、アプリケーションクライアント１０４から引き渡された指示受付オブジェクトのオブジェクトＩＤと、条件値、ｑｕｅｒｙＩＤを受け付ける。
【０１７９】
ステップＳ２２１２からステップＳ２２１９のループにおいては、前記受け付けたｑｕｅｒｙＩＤに対する処理を実行する（ｑｕｅｒｙＩＤは複数の可能性がある）。ここでｑｕｅｒｙＩＤの処理の順番は、アクション定義記憶部３２２において記憶された実行順２００３に従う。
【０１８０】
ステップＳ２２１３においては、１つのｑｕｅｒｙＩＤに着目する。ステップＳ２２１４においては、前記着目中のｑｕｅｒｙＩＤに基づき、クエリ定義記憶部３２３からクエリ定義を取得する。
【０１８１】
ステップＳ２２１５においては、クエリ定義において指定された接続先ＤＢに接続する（必要があればオープンする）。またステップＳ２２１６においては、クエリ定義において指定されたｓｅｌｅｃｔ文を取得する。本ｓｅｌｅｃｔ文は、パラメータ部を含んだ記載をされている場合がある。
【０１８２】
ステップＳ２２１７においては、前記ｓｅｌｅｃｔ文がパラメータ部を含む場合に、アプリケーションクライアント１０４から受け付けたパラメータ値を代入する。ステップＳ２２１８においては、前記パラメータ値を代入済み（パラメータ値がない場合は、クエリ定義から取得したまま）のｓｅｌｅｃｔ文を実行する。
【０１８３】
ステップＳ２２２０では、前記検索結果が、アプリケーションクライアント１０４に引き渡しされる。引渡時には、ｑｕｅｒｙＩＤ（表示グループ）毎の検索結果が分かるような構成で引き渡す。
【０１８４】
アプリケーションクライアント１０４は、ステップＳ２２０３において、アプリケーションサーバ１０５から引き渡された、検索結果を受け付ける。
【０１８５】
ステップＳ２２０４からステップＳ２２０６のループでは、アプリケーションサーバ１０５から受け付けた検索結果に対するループである。本ループは、ｑｕｅｒｙＩＤと各データ項目（カラム）の２重のループである。
【０１８６】
結果は、ｑｕｅｒｙＩＤ毎（表示グループに対応する）および各データ項目（カラム）と値が対応付けられており、また各データ項目名（カラム名）は、表示グループ上の実際のオブジェクトＩＤと対応付けられているため、対応するオブジェクトに値を設定する。具体的には、ステップＳ２２０５において対応するオブジェクト（検索結果表示オブジェクトまたは処理結果表示オブジェクトと呼ぶことにする）に値を設定する。
【０１８７】
なお、例えばＡｊａｘなどにより、必要な部分のみを非同期に更新する方法でもよい。その場合には、アプリケーションクライアント１０４からアプリケーションサーバ１０５への要求および結果応答は、ｑｕｅｒｙＩＤ毎に行ってもよい。
【０１８８】
また、アプリケーションクライアント１０４においてユーザが指示受付オブジェクト（例えばボタンオブジェクト）をクリックした画面と、検索結果が表示される画面は異なる画面であってもよい。アクション定義には表示グループが含まれており、これはコンテナまたはグリッドオブジェクトなどとしてＩＤを持っているため、表示グループがどの画面に属しているかはアプリケーションサーバ１０５が判別してもよいし、ステップＳ２２０２においてアプリケーションクライアント１０４から引き渡し、ステップＳ２２１１においてアプリケーションサーバ１０５で受け付ける値に、画面ＩＤを含めるようにしてもよい。そのため、図２３で生成する処理において、画面ＩＤを処理に含めてもよい。
【０１８９】
さらに、異なる画面である場合には、レイアウト定義記憶部３２１に含まれるレイアウト定義から、対応する画面を生成し、アプリケーションクライアント１０４に表示させるとともに、前記の検索結果を受け渡すことで、本フローチャートで説明したこととが実現できる。また、この場合、値を設定するステップＳ２２０４からステップＳ２２０６までの処理は、アプリケーションサーバ１０５側で実施してもよい。この場合、結果受渡部３３６では、検索結果ではなく、画面データを、アプリケーションクライアント１０４の結果受付部３３７に渡してもよい。
【０１９０】
さらに、アプリケーションクライアント１０４に表示されている画面であっても、ステップＳ２２０４からステップＳ２２０６までの処理はアプリケーションサーバ１０５側で実施し、表示のみアプリケーションクライアント１０４で実施してもよい。この場合には、画面生成部３３０において画面データをアプリケーションサーバ１０５で生成し、結果受渡部３３６では、検索結果ではなく、画面データを、アプリケーションクライアント１０４の結果受付部３３７に渡してもよい。
【０１９１】
この場合、本処理は、アプリケーションサーバ１０５において、全画面を更新する処理でもよい。その場合には、指示要求オブジェクトＩＤを含む画面をレイアウト定義記憶部３２１から取得し、画面を生成してもよい。
以上で、図２２のフローチャートの説明は完了する。
【０１９２】
なお、以上の説明では、例えば“ｇｒｉｄＢ”などと説明したが、ベースとなるコンテナからの階層を明示する必要があれば、“ｃｏｎｔｅｎａＡ．ｌｉｎｅＡ３．ｇｒｉｄＢ”と指定するようにしてもよい（図１９の表示グループ指定フィールド１９０５においても同様）。
【０１９３】
図２３は、アプリケーションクライアント画面上の指示受付オブジェクトに対応付ける処理（イベント処理）を生成するフローチャートの一例である。
【０１９４】
アプリケーションクライアント１０４の画面上において、ユーザが指示受付オブジェクト（ボタンなど）をクリックすると、その指示受付オブジェクトに対応する処理（図２２のフローチャートでは、ステップＳ２２０１とステップＳ２２０２）が起動させる。この処理は、指示受付オブジェクトに対応するアクション定義に基づいて生成され、画面内に組み込まれている。
【０１９５】
本処理は、開発時にプログラム開発装置１０１またはプログラム開発サーバ１０２で生成してもよいし、実行時にアプリケーションサーバ１０５において生成してもよい。以下、実際に処理の説明をするが、システム構成に従って、ステップＳ２３０１からステップＳ２３０９の各ステップは、プログラムの開発時に本処理が生成される場合であって、プログラムの開発がプログラム開発装置１０１単体で行われる場合にはプログラム開発装置１０１のＣＰＵ２０１が、またプログラムの開発がプログラム開発装置１０１とプログラム開発サーバ１０２が協調して行う場合にはプログラム開発サーバ１０２が、アプリケーションの動作時に生成される場合にはアプリケーションサーバ１０５のＣＰＵ２０１が実行する。
【０１９６】
ステップＳ２３０１においては、アプリケーションクライアント１０４の実行時において、ボタンなどの指示受付オブジェクト（図１８では検索ボタン１８０１。以降図１８を例として使用）をユーザがマウスクリックした場合（グラフィカルユーザインタフェース（ＧＵＩ）上でイベントが発生した場合）、当該指示受付オブジェクト（例では、検索ボタン１８０１）のオブジェクトＩＤ（“ｂｕｔｔｏｎ１”）を取得する必要がある。ここでは、オブジェクトＩＤを取得する処理を生成する。
【０１９７】
ステップＳ２３０２からステップＳ２３０７までは、指示受付オブジェクトに対応付けられたクエリ定義のｑｕｅｒｙＩＤに対する処理を生成するループである。アプリケーションサーバ１０５で処理するためにｑｕｅｒｙＩＤをパラメータとして引き渡すためである。ただし、アプリケーションサーバ１０５側で、指示受付オブジェクトＩＤに基づきアクション定義記憶部からｑｕｅｒｙＩＤを取得するように図２２のフローチャートを構成する場合には、本処理の生成はなくてもよい。
【０１９８】
ステップＳ２３０３においては、着目中のｑｕｅｒｙＩＤを生成中の本処理に保持するためのコードを生成する。
【０１９９】
ステップＳ２３０４からステップＳ２３０６においては、ステップＳ２３０３において着目中のｑｕｅｒｙＩＤに引き渡すパラメータ値を取得するためのループである。
【０２００】
ステップＳ２３０５においては、１つの条件項目オブジェクトに着目し、その値を取得するための処理を生成する。
【０２０１】
全てのｑｕｅｒｙＩＤに対して、全ての条件項目値から値を取得する処理のコード生成が完了したら、ステップＳ２３０８において、前述までの処理で取得した指示受付オブジェクトＩＤ、ｑｕｅｒｙＩＤ、ｑｕｅｒｙＩＤのパラメータ値をアプリケーションサーバ１０５に引き渡す処理のコードを生成する。
【０２０２】
ステップＳ２３０９において、上記生成した処理を一連の処理として指示受付オブジェクトに対応付ける。
【０２０３】
ここで、対応付けとは、開発時に本処理を生成するのであれば、例えばアクション定義記憶部３２２において記憶させる、またアプリケーションサーバ１０５においてアプリケーション実行時に生成するのであれば、アプリケーションクライアント１０４に表示する画面内に記憶させる、などの方法がある。
以上で図２３のフローチャートについて説明を完了する。
【０２０４】
以上により、プログラム開発装置１０１において、開発者がｓｅｌｅｃｔ文によりアプリケーションの動作を定義する方法と、その定義に従ったアプリケーションの動作についての一例についての説明を完了する。
【０２０５】
次に、第二の実施の形態を説明する。第二の実施の形態は、ＳＱＬ文を用いる方式以外の方式であって、レイアウトの一括作成、アクションの定義によるアプリケーション画面へのデータ項目（カラム）の表示を実施する方法としてＲＥＳＴ方式について説明する。
【０２０６】
本実施形態において、ＲＥＳＴ方式とは、ウェブサーバが規定するＵＲＬにより、ウェブサーバにレスポンスデータを要求する方式である。このＵＲＬには、ウェブサーバが規定する引数を含めることにより、要求するレスポンスデータを指定することができる。ＲＥＳＴ方式の要求に対して、ウェブサーバ側は、規定された形式のレスポンスデータを戻り値として戻す。戻り値としては、呼出側が容易に解析できるＪＳＯＮ形式、ＣＳＶ形式、ＸＭＬ形式、その他のテキスト形式がある。本例ではＪＳＯＮ形式を用いて説明するが、ＪＳＯＮ形式に制限するものではない。
【０２０７】
また、呼出側からＲＥＳＴ方式のＵＲＬによりレスポンスデータを要求され、規定の形式でレスポンスデータを返すウェブサービスを提供するウェブサーバを、ＲＥＳＴサーバ１０６と呼ぶことにする。
【０２０８】
なお、ＲＥＳＴは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒの略、ＪＳＯＮは、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎの略である。
【０２０９】
図２４は、ＲＥＳＴサーバ１０６に対するＲＥＳＴ方式の要求を示すＵＲＬと対応するレスポンスデータの一例である。
【０２１０】
ＲＥＳＴ方式のＵＲＬとして“ｈｔｔｐ：／／ｈｏｓｔｎａｍｅ．ｊｐ／ｏｒｄｅｒ／００１”を指定することで、ＲＥＳＴサーバ１０６は注文書データ、注文品目データをレスポンスデータとして返す。引数として指定された“００１”は注文番号を意味する。図４において、注文書テーブル４００、注文品目テーブル４１０を、ｏｒｄｅｒＩＤとして“００１”を指定して検索する事に相当する。“ｈｔｔｐ：／／ｈｏｓｔｎａｍｅ．ｊｐ／ｏｒｄｅｒ／００１”のように引数を記述する規定は、あくまであるＲＥＳＴサーバ１０６の例である。別のＲＥＳＴサーバ１０６であれば、“ｈｔｔｐ：／／ｈｏｓｔｎａｍｅ．ｊｐ／ｏｒｄｅｒ？ｏｒｄｅｒ＿ＩＤ＝‘００１’”というように、引数を記述するよう規定されていても良い。すなわち「？引数名＝値＆引数名＝値＆引数名＝値・・・」というように複数の引数をＲＥＳＴサーバ１０６に渡すことが出るよう規定されていても良い。
【０２１１】
一方、レスポンスデータの例としては、ＪＳＯＮ形式で記載している。データの内容としては、注文書データと注文品目データの２つの連想配列（部分データ構成）が含まれている。引数に注文番号“００１”を指定しているため、“ｏｒｄｅｒ＿ＩＤが‘００１’であるレスポンスデータのみが連想配列に含まれている。注文書データは、ＪＳＯＮ形式のデータ中、ルートに記載されたデータであることを示す“＄ｒｅｓｕｌｔ”に対応する連想配列である。データが一意的に決定されるため、連想配列は１レコードのみ含んでいる。
【０２１２】
連想配列は、“キーワード：値”という形で構成されている。前記注文書データの例では、“ｏｒｄｅｒ＿ｉｄ”、“ｃｕｓｔｏｍｅｒ＿ｎａｍｅ”、“ｔｅｌｅｐｈｏｎｅ”、“ｄａｔｅ”、“ｔｏｔａｌ＿ｐｒｉｃｅ”の５つのキーワードが含まれている。それぞれのキーワードに対応する値は、各々‘００１’、‘山下産業（株）’、‘０３−１２３４−５６７８’、‘２０１１／０１／２６’、‘１００００００’である。
【０２１３】
また、注文品目データは、“＄ｏｒｄｅｒ＿ｉｔｅｍｓ”に対応する連想配列である。正確には、ルート“＄ｒｅｓｕｌｔ”の下の階層にあるため、“＄ｒｅｓｕｌｔ．＄ｏｒｄｅｒ＿ｉｔｅｍｓ”で指定される。注文品目データの連想配列には、３レコードが含まれている。また、キーワードは４つであり、“ｏｒｄｅｒ＿ｉｄ”、“ｐｒｏｄｕｃｔ＿ｎａｍｅ”、“ｐｒｉｃｅ”、“ａｍｏｕｎｔ”の４つである。
【０２１４】
すなわち、本例では、“ｏｒｄｅｒ＿ｉｄ”を引数として検索された２つの連想配列がレスポンスデータとして返されるものである。
【０２１５】
図２５は、ＲＥＳＴ方式に基づき、明細書形式コンテナにおける、一括作成によるレイアウトの自動作成を説明するための図である。
【０２１６】
図２５については、図９の説明とほぼ同様となるため、異なる部分を説明する。
【０２１７】
開発ＧＵＩ６００において、図９における接続先ＤＢ指定フィールド９０１、ＳＱＬ指定フィールド９０２のかわりに、ＲＥＳＴ方式による定義（図２５）では、ＵＲＬ指定フィールド２５０１、対象配列指定フィールド２５０２、抽出式指定フィールド２５０３がある。なお対象配列のことを指定対象と呼ぶこともある（ＪＳＯＮ形式以外では、対象配列の形式ではない場合もあるため）。
【０２１８】
ＵＲＬ指定フィールド２５０１には、ＲＥＳＴ方式のＵＲＬを指定する。図２５では、例として図２４のＵＲＬ、“ｈｔｔｐ：／／ｈｏｓｔｎａｍｅ．ｊｐ／ｏｒｄｅｒ／００１”が指定されている。
【０２１９】
対象配列指定フィールド２５０２は、レスポンスデータに含まれるいずれの連想配列を使用するかを指定するものである。図２４のレスポンスデータを用いる場合であれば、注文書データの連想配列を示す“＄ｒｅｓｕｌｔ”、または注文品目データの連想配列を示す“＄ｒｅｓｕｌｔ．＄ｏｒｄｅｒ＿ｉｔｅｍｓ”のいずれかが指定される。図２５においては、“＄ｒｅｓｕｌｔ”が指定されている。
【０２２０】
抽出式指定フィールド２５０３には、連想配列のキーワードのうちのいずれを、レイアウト定義に使用するか、また使用する場合にいかなるデータ項目名（カラム名）として扱うかを対応付けるものである。“｛＊｝”（抽出式２５０４ａ）を指定して一括作成ボタン９０３をクリックすると、レスポンスデータの対象配列“＄ｒｅｓｕｌｔ”に対応する全キーワードに対して、図９の明細書形式コンテナ６１３ａと同様に、明細書形式コンテナ２５０５に一括作成処理がなさせる。すなわち、５つの行形式コンテナ２５０６ａ〜ｅと、連想配列“注文書データ”の５つのキーワードを見出しとするテキストオブジェクトが生成される。さらに、各テキストオブジェクトには、各キーワードに対応する値が表示される。一括作成の詳細は、図２７のフローチャートにおいて説明する。
【０２２１】
図９においては、図１４のフローチャートにより、ｓｅｌｅｃｔ文の検索結果である各データ項目名（カラム名）をテキストオブジェクトの見出しおよびオブジェクトＩＤとして用いた。ＲＥＳＴ方式で、抽出式指定フィールド２５０３に指定された抽出式が前述の通り“｛＊｝”（抽出式２５０４ａ）の場合には、キーワード自体をデータ項目名（カラム名）として、同様に処理する。
【０２２２】
連想配列の一部のキーワードについてのみを選択し、あるいは、キーワードと異なるデータ項目名（カラム名）に置き換える場合には、抽出式２５０４ｂのように、“データ項目名（カラム名）：キーワード”の対応付けを定義する。
【０２２３】
抽出式２５０４ｂでは、“ｏｒｄｅｒ＿ｉｄ”、“ｃｕｓｔｏｍｅｒ＿ｎａｍｅ”、“ｄａｔｅ”の３つのキーワードを抽出し、各々“ｏｒｄｅｒＩＤ”、“ｃｕｓｔｏｍｅｒ”、“ｄａｔｅ”というデータ項目名（カラム名）に対応付けている。これらの指定をした上で、一括作成ボタン９０３をクリックすると、レスポンスデータの対象配列“＄ｒｅｓｕｌｔ”に対応する抽出した３キーワードに対して、図９の明細書形式コンテナ６１３ｂと同じ結果が得られる。
【０２２４】
なお、抽出式２５０４ｂでは、“データ項目名（カラム名）：キーワード”と記述することでキーワードをデータ項目名（カラム名）に対応付けるよう定義したが、データ項目名（カラム名）は省略することができる。
【０２２５】
例えば、抽出式を“｛ｏｒｄｅｒ＿ｉｄ、ｃｕｓｔｏｍｅｒ＿ｎａｍｅ、ｄａｔｅ｝”と定義できる。この場合には、キーワード自体をデータ項目名(カラム名)とする。
【０２２６】
図２６は、ＲＥＳＴ方式に基づき、グリッドオブジェクトにおける、一括作成によるレイアウトの自動作成を説明するための図である。
【０２２７】
図２６については、図１１とほぼ同様のため、異なる部分のみを説明する。
【０２２８】
ＵＲＬ指定フィールド２５０１には図２５と同様に、図２４のＵＲＬ、“ｈｔｔｐ：／／ｈｏｓｔｎａｍｅ．ｊｐ／ｏｒｄｅｒ／００１”が入力されている。
【０２２９】
対象配列指定フィールド２５０２は、注文品目データの連想配列を示す“＄ｒｅｓｕｌｔ．＄ｏｒｄｅｒ＿ｉｔｅｍｓ”が指定されている。
【０２３０】
抽出式指定フィールド２５０３には、抽出式２６０１が指定されている。
【０２３１】
これらの指定により、図２４の“注文品目データ”に対応する連想配列から、“ｐｒｏｄｕｃｔ＿ｎａｍｅ”、“ｐｒｉｃｅ”、“ａｍｏｕｎｔ”の３つのキーワードが抽出される。また、各々のキーワードは、データ項目名（カラム名）、“ｐｒｏｄｕｃｔ”、“ｐｒｉｃｅ”、“ａｍｏｕｎｔ”に対応付けられる。
【０２３２】
一括作成ボタン９０３をクリックすると、図１１の１１０２ｂと同様、グリッドオブジェクト２６０２に、前記抽出された３つのデータ項目名（カラム名）に対応する列が生成され、値が表示される。
【０２３３】
ただし、図２４のレスポンスデータ中の注文品目データに３レコードしかデータが含まれないため、表示も３行に限られる。
【０２３４】
図２７は、本発明の実施形態における一括作成部の処理の一例を示すフローチャートである。プログラム開発装置１０１のＣＰＵ２０１が、各ステップを実行する。ＲＥＳＴ方式による一括作成の処理であるが、図１４で説明したフローチャート（ＳＱＬ文による一括作成の処理）との違いは、戻り値であるレスポンスデータ（図２４）から、ＳＱＬ文の戻り値であるテーブルと同等のデータ構成を作成する部分である。図１４のステップＳ１４０１〜Ｓ１４０４に対応する部分を、図２７のステップＳ２７０１〜Ｓ２７１４の処理で置き換えることで実現する。
【０２３５】
ステップＳ２７０１〜Ｓ２７１４においてテーブルと同等のデータ構成を作成することにより、後述するとおり、図１４のフローチャートと同様の処理となる。
【０２３６】
ステップＳ２７０１においては、一括作成ボタン９０３がクリックされた際に選択されている明細書形式コンテナ、またはグリッドオブジェクトのＩＤを、一括作成先の表示グループのＩＤとして取得する。
【０２３７】
ステップＳ２７０２においては、ＲＥＳＴ方式の要求としてＵＲＬ指定フィールド２５０１で指定したＵＲＬ（例として図２４のＵＲＬ）を受け付け、ＲＥＳＴサーバ１０６に対して発行する。
【０２３８】
ステップＳ２７０３においては、ステップＳ２７０２において発行した要求に対してのレスポンスデータ（例として図２４のレスポンスデータ）を受信する。
【０２３９】
ステップＳ２７０４においては、対象配列指定フィールド２５０２で指定した対象配列に基づき、レスポンスデータから連想配列を取得する（図２４では、注文書データ、または注文品目データ）。
【０２４０】
ステップＳ２７０５では、抽出式指定フィールド２５０３で指定した抽出式に基づき、カラムリストを生成する。抽出式２５０４ａのように抽出式が“｛＊｝”の場合には、連想配列の全キーワードを、データ項目名（カラム名）とみなして、カラムリストを作成する。抽出式２５０４ｂまたは抽出式２６０１のように、データ項目名（カラム名）とキーワードの具体的な対応付けが指定されている場合には、指定されたデータ項目名（カラム名）からカラムリストを作成する。
【０２４１】
ステップＳ２７０６においては、前記カラムリストに含まれるデータ項目（カラム）により構成される、空の（データが１行もない）テーブルを生成する。
【０２４２】
ステップＳ２７０７からステップＳ２７１４までのループ処理においては、前述の処理で取得した連想配列の各行に対する処理を１行ずつ着目して実施する。
【０２４３】
ステップＳ２７０８においては、前記テーブルに空の行（データ項目に対応する値が設定されていない行）を１行追加する。
【０２４４】
ステップＳ２７０９からステップＳ２７１３までのループ処理においては、前記のカラムリストに含まれる各データ項目（カラム）に対するループ処理である。
【０２４５】
ステップＳ２７１０においては、カラムリストから１つのデータ項目（カラム）に着目する。
【０２４６】
ステップＳ２７１１においては、抽出式に基づき、データ項目（カラム）に対応する連想配列のキーワードを取得し、連想配列の着目中の行から前記キーワードに対応する値を取得する。この値を、データ項目（カラム）に対応する値とみなす。抽出式が“｛＊｝”で指定されている場合には、データ項目（カラム）そのものを連想配列のキーワードとする。
【０２４７】
ステップＳ２７１２においては、テーブルの着目中の行（ステップＳ２７０８においてテーブルに追加した行）における着目中のデータ項目（カラム）に、ステップＳ２７１１で取得した値を設定する。
【０２４８】
ステップＳ２７０９からステップＳ２７１３のループにより指定の処理を繰り返すことで、連想配列の１行分のデータのうち、カラムリストに対応するデータ項目（カラム）の値が、テーブルの１行分のデータとして設定される。ステップＳ２７０７からステップＳ２７１４までのループにより指定の処理を繰り返すことで、前記テーブルに、連想配列の全ての行、全てのデータ項目（カラム）に対して値が設定される。
【０２４９】
ステップＳ２７１５は、図１４のステップＳ１４０７に相当し、表示グループ（一括作成先）が明細書形式コンテナか、グリッドオブジェクトかに従った分岐を行う処理である。
【０２５０】
ステップＳ２７０１で取得したＩＤが明細書形式コンテナのものであればステップＳ２７１６に進む。ステップＳ２７０１で取得したＩＤがグリッドオブジェクトのものであればステップＳ２７１７に進む。
【０２５１】
ステップＳ２７１６は、前述の処理で生成したテーブルに従って、明細書形式コンテナに対してレイアウトの一括作成を実施する処理である。図１４のステップＳ１４１１〜Ｓ１４２０に相当する部分と同一の処理であり、詳細の説明は省略する。
【０２５２】
ステップＳ２７１７は、前述の処理で生成したテーブルに従って、グリッドオブジェクトに対してレイアウトの一括作成を実施する処理である。図１４のステップＳ１４３１〜Ｓ１４４１に相当する部分と同一の処理であり、詳細の説明は省略する。
以上で、図２７のフローチャートの処理の説明を完了する。
【０２５３】
図２８は、一括作成した結果を含む、レイアウト定義記憶部３２１におけるレイアウト定義のデータ構成の一例を示す図である。
【０２５４】
図２８の定義は、ＲＥＳＴ方式を用いたものであるが、本定義が生成される過程は、ＳＱＬ文を用いた方式により、図９から図１８で説明した流れとほぼ同様である。そのため、繰り返しになる部分もあるが、図２８のレイアウト定義の生成過程を簡単に説明する。
【０２５５】
まず、図２５で説明したように明細書形式コンテナ６１３（コンテナＩＤは“ｃｏｎｔｅｎａＡ”とする）上で、抽出式２５０４ｂを用いて一括作成をし、結果として図２５の６１３ｂを得る。一括作成は図２７のフローチャートのステップＳ２７１６による。
【０２５６】
次に図１２のように、開発者の操作により１行（行形式コンテナ１２０１）とグリッドオブジェクト１００２（オブジェクトＩＤは“ｇｒｉｄＢ”）を挿入する。
【０２５７】
さらに、グリッドオブジェクト１００２に対して、図２６で説明したように抽出式２６０１を用いて一括作成をし、グリッドオブジェクト２６０２にデータ項目（カラム）および値が生成、表示される。全体のレイアウトは、グリッドオブジェクト２６０２に表示されたデータが３行に限定されていることを除き、図１３のようになる。一括作成は図２７のフローチャートのステップＳ２７１７による。
【０２５８】
更に図１３の説明と同様に、ボタンオブジェクト（オブジェクトＩＤは“ｂｕｔｔｏｎ１”）を追加する。
【０２５９】
更に図１６での説明と同様に、各オブジェクトの属性、特に見出しを変更することで、図１８と同様の画面になる。ただし前述の通り、グリッドオブジェクト２６０２の内容が３行であることは図１８と異なる部分である。
【０２６０】
説明を前記の作業及び一括作成処理により生成された図２８のレイアウト定義のデータ構成に戻す。
【０２６１】
図２８のレイアウト定義のデータ構成は、ほぼ図１７と同様である。すなわち、表示グループで指定される明細書形式コンテナ、さらに行形式コンテナ、テキストボックスやボタンなどのオブジェクトの種類、ＩＤ、Ｌａｂｅｌは同様に定義される。
【０２６２】
異なるのはレイアウトを一括作成するため、図１７では、データベースに対応する情報として“接続先ＤＢ”、“ＳＱＬ”が指定されていたのに対して、図２８では、ＲＥＳＴ方式として、“ＵＲＬ”、“対象配列”、“抽出式”が登録されることである。それぞれの情報がどのように用いられるかは、既に説明しているため、ここでは説明を省略する。
【０２６３】
これらのレイアウト定義のデータ構成は、図２５の一括作成ボタン９０３がクリックされ、図２７のフローチャートにより実際にレイアウトされるタイミングなどでレイアウト定義記憶部３２１に登録される。
【０２６４】
以上により、ＲＥＳＴ方式を用いて、プログラム開発装置１０１における開発者によるレイアウト定義、レイアウト定義の一括作成を行う操作、およびプログラム開発装置１０１またはプログラム開発サーバ１０２が、レイアウト定義を一括作成する処理動作の実施形態の一例の説明を完了する。
【０２６５】
次に、ＲＥＳＴ方式によりアクション定義を行い、実際のアプリケーション動作時に、アプリケーションクライアント１０４とアプリケーションサーバ１０５が協調動作する処理について説明する。ＳＱＬ文による方式と異なる部分を詳細に説明する。
【０２６６】
図２９は、開発者がＲＥＳＴ方式に基づきアクション定義を行う画面の一例を示す図である。アクション定義には、プログラム開発装置１０１を用いる。本例では開発ＧＵＩ６００のアクション定義６０５によりアクション定義を行う。
【０２６７】
ＲＥＳＴ方式による定義（図２５）では、ＵＲＬ指定フィールド２９０１、対象配列指定フィールド２９０２、抽出式指定フィールド２９０３を定義する。前記項目には、各々ＲＥＳＴ方式でレスポンスデータを要求するためのＵＲＬ、レスポンスデータから処理対象とする連想配列を指定する対象配列、連想配列から必要なキーワードを抽出しデータ項目（カラム）に対応付ける抽出式を定義する。なお、レイアウト作成の場合と同様、対象配列のことを指定対象と呼ぶこともある（ＪＳＯＮ形式以外では、対象配列の形式ではない場合もあるため）。
【０２６８】
図１９での説明と同様に、条件項目指定フィールド１９０４とパラメータ指定フィールド１９１３には対応付けられた複数の項目が指定可能である。すなわち、ＵＲＬ指定フィールド２９０１において定義されるＵＲＬにおいて複数のパラメータ（例では“:id”など）が指定可能である場合には、条件項目指定フィールド１９０４とパラメータ指定フィールド１９１３には、複数の項目を指定する。
【０２６９】
また、図１９と同様に、定義内容を、アクション定義（アクション定義領域１９０２にて定義）とクエリ定義（クエリ定義領域１９１１にて定義）に分離している。アクション定義については、図２０で説明したアクション定義テーブル２０００として構成されるテーブルに登録、記憶される。また、クエリ定義については、後述の図３０のクエリ定義テーブル２１００に記憶される。
【０２７０】
アクション定義テーブル２０００に登録、記憶される定義内容ついては、ＳＱＬ文による方式の場合と、ＲＥＳＴ方式による場合とで共通である。また、図２０の説明において、アクション定義テーブル２０００とクエリ定義テーブル２１００を、１つのテーブル構成にしてもよいとした。この場合、両方式のために２種類の異なる構成のアクション定義テーブル２０００を用意してもよい。あるいは、定義の異なる部分の両方を１つのテーブル構成に含むことができるようにして、単一のアクション定義テーブル２０００を用意してもよい。
【０２７１】
図３０は、ＲＥＳＴ方式によるクエリ定義のデータ構成の一例を示す図である。前述の通り、クエリ定義テーブル２１００を構成する定義内容は、アクション定義テーブル２０００に含めてもよいが、図３０では、クエリ定義テーブル２１００を分離した構成として説明する。具体的には、図２９のクエリ定義領域１９１１の内容を登録、記憶するものであり、また図２１のクエリ定義テーブル２１００と同様の構成であるため、異なる部分のみ説明する。
【０２７２】
図３０のクエリ定義テーブル２１００の構成においては、図２１のＳＱＬ文による方式として登録した接続先ＤＢ、ｓｅｌｅｃｔ文のかわりに、ＵＲＬ、対象配列、抽出式を登録する。
【０２７３】
ＵＲＬ３００１には、ＲＥＳＴ方式によりＲＥＳＴサーバ１０６にレスポンスデータを要求するＵＲＬが定義され、ＵＲＬは、図２９のＵＲＬ指定フィールド２９０１で説明したようにパラメータを含むことが可能である。対象配列、抽出式は既に説明しているので省略する。
【０２７４】
これらの定義は、アプリケーションの実行時に参照されるものであり、詳細の動作については、図３１のフローチャートにおいて説明する。
【０２７５】
なお、ＳＱＬ文による方式とＲＥＳＴ方式による場合で、クエリ定義テーブル２１００はデータ構成が異なる。両方式に対して、２種類の異なるデータ構成のクエリ定義テーブル２１００を用意してもよい。あるいは、定義の異なる部分の両方を１つのテーブル構成に含むことができるようにして、単一のクエリ定義テーブル２１００を用意してもよい。
【０２７６】
図３１は、本発明の実施形態におけるＲＥＳＴ方式で定義したアクションの実行処理の一例を示すフローチャートである。
【０２７７】
本処理は、アプリケーションサーバ１０５の画面生成部３３０により生成された画面が、既にアプリケーションクライアント１０４に表示されており、その画面においてユーザ操作により指示受け付けオブジェクトがクリックされた前提で実行されるアプリケーションの動作の説明である。
【０２７８】
本処理は、ＳＱＬ文による方式の説明における図２２に対応するものであるが、アプリケーションクライアント１０４側の図を省略している。すなわち、図２２のステップＳ２２０１からステップ２２０７までを、アプリケーションクライアント１０４のＣＰＵ２０１が実行するのに応じて、図３１のステップＳ２２１１からステップＳ２２１４、ステップＳ３１０１からステップＳ３１１５、ステップＳ２２１９からステップＳ２２２０までを、アプリケーションサーバ１０５のＣＰＵ２０１が実行する。各ステップについては、アプリケーションサーバ側の説明のみ行う。
【０２７９】
また、データベースサーバ１０３を含めた構成については、図２２での説明と同様である。
【０２８０】
ステップＳ２２１１においては、アプリケーションクライアント１０４から引き渡された指示受け付けオブジェクトのオブジェクトＩＤと、条件値、ｑｕｅｒｙＩＤを受け付ける。
【０２８１】
ステップＳ２２１２からステップＳ２２１９のループにおいては、前記受け付けたｑｕｅｒｙＩＤに対応する処理を実行する（ｑｕｅｒｙＩＤは複数の可能性がある）。ここで、ｑｕｅｒｙＩＤの処理の順番は、アクション定義記憶部３２２において記憶された実行順２００３（図２０）に従う。
【０２８２】
ステップＳ２２１３においては、１つのｑｕｅｒｙＩＤに着目する。ステップＳ２２１４においては、前記着目中のｑｕｅｒｙＩＤに基づき、クエリ定義記憶部３２３からクエリ定義を取得する。
【０２８３】
ステップＳ３１０１においては、前のステップＳ２２１４で取得されたクエリ定義に基づき、図３０のクエリ定義テーブル２１００からＵＲＬを取得する。例として“ｈｔｔｐ：／／ｈｏｓｔｎａｍｅ．ｊｐ／ｏｒｄｅｒ／：ｉｄ”を取得する。
【０２８４】
ステップＳ３１０２においては、前記ＵＲＬがパラメータ部を含む場合には、アプリケーションクライアント１０４から受け付けたパラメータ値を代入する。例えば、前記ＵＲＬにパラメータ値“００１”を代入すると“ｈｔｔｐ：／／ｈｏｓｔｎａｍｅ．ｊｐ／ｏｒｄｅｒ／００１”となる。
【０２８５】
ステップＳ３１０３においては、ＲＥＳＴ方式の要求として前記パラメータ値を代入済み（パラメータ部がない場合は、図３０のクエリ定義テーブル２１００から取得したまま）のＵＲＬを、ＲＥＳＴサーバ１０６に対して発行する。
【０２８６】
ステップＳ３１０４においては、ステップＳ３１０３において発行した要求に対してのレスポンスデータ（例として図２４のレスポンスデータ）をＲＥＳＴサーバ１０６から受信する。
【０２８７】
ステップＳ３１０５においては、対象配列３００２で指定され対象配列に基づき、レスポンスデータから連想配列を取得する。例えば、図２４のレスポンスデータに対して、指定が“ｒｅｓｕｌｔ”であれば注文書データ、“＄ｒｅｓｕｌｔ．＄ｏｒｄｅｒ＿ｉｔｅｍｓ”であれば注文品目データを取得する。
【０２８８】
ステップＳ３１０６では、図３０の抽出式３００３で指定された抽出式に基づき、カラムリストを生成する。カラムリストの作成方法については、図２７（ステップＳ２７０５）と同様なので説明を省略する。
【０２８９】
ステップＳ３１０７においては、前記カラムリストに含まれるデータ項目（カラム）により構成される、空の（データが１行もない）テーブルを生成する。
【０２９０】
ステップＳ３１０８からステップＳ３１１５までのループ処理においては、前述の処理で取得した連想配列の各行に対する処理を１行ずつ着目して実施する。
【０２９１】
ステップＳ３１０９においては、前記テーブルに空の行（データ項目に対応する値が設定されていない行）を１行追加する。
【０２９２】
ステップＳ３１１０からステップＳ３１１４までのループは、前記のカラムリストに含まれる各データ項目（カラム）に対する処理である。
【０２９３】
ステップＳ３１１１においては、カラムリストから１つのデータ項目（カラム）に着目する。
【０２９４】
ステップＳ３１１２においては、抽出式に基づき、データ項目名（カラム名）に対応する連想配列のキーワードを取得し、連想配列の着目中の行から前記キーワードに対応する値を取得する。この値を、データ項目（カラム）に対応する値とみなす。抽出式が“｛＊｝”で指定されている場合には、データ項目名（カラム名）そのものを連想配列のキーワードとする。
【０２９５】
ステップＳ３１１３においては、テーブルの着目中の行（ステップＳ３１０９においてテーブルに追加した行）における着目中のデータ項目（カラム）に、ステップＳ３１１２で取得した値を設定する。
【０２９６】
ステップＳ３１１０からステップＳ３１１４のループにより指定の処理を繰り返すことで、連想配列の１行分のデータのうち、カラムリストに対応するデータ項目（カラム）の値が、テーブルの１行分のデータとして設定される。ステップＳ３１０８からステップＳ３１１５までのループにより指定の処理を繰り返すことで、前記テーブルに、連想配列の全ての行、抽出式でキーワードと対応付けられた全てのデータ項目（カラム）に対して値が設定される。
【０２９７】
ステップＳ２２２０では、前記生成されたテーブルにレスポンスデータの連想配列のデータ項目（カラム）の値を設定した結果が、アプリケーションクライアント１０４に引き渡しされる。この結果は、ＳＱＬ文による方式による場合の検索結果に相当するデータである。
【０２９８】
なお、図２２で説明したのと同様に、Ａｊａｘなどにより非同期処理により本処理を実現してもよい、などの構成が可能である。同様に、アプリケーションサーバ１０５からアプリケーションクライアント１０４に引き渡すのは、テーブルのデータ（検索結果）ではなく、画面データである処理にすることが可能である。
以上で、図３１のフローチャートの説明を完了する。
【０２９９】
以上により、プログラム開発装置１０１において、開発者がＲＥＳＴ方式によりアプリケーションの動作を定義する方法と、その定義に従ったアプリケーションの動作についての一実施形態についての説明を完了する。
【０３００】
次に、第三の実施の形態を説明する。前述の説明では、レイアウトの一括作成を、ＳＱＬ文による方式とＲＥＳＴ方式を個別に実行する方法として説明した。第三の実施の形態では、ＳＱＬ文による方式とＲＥＳＴ方式を、混在することが可能なプログラム開発装置１０１の説明をする。
【０３０１】
図３２は、レイアウトの一括作成をＳＱＬ文とＲＥＳＴ方式の両方で定義可能な場合の分岐処理の一例を示すフローチャートである。一括作成ボタン９０３がクリックされると、プログラム開発装置１０１のＣＰＵ２０１が、各ステップを実行する。
【０３０２】
レイアウト定義をいずれの方式で行うのか、開発ＧＵＩ６００上、一括作成情報６０４において開発者に選択させる、などすることができる。また、一括作成情報６０４における定義内容が異なるため、開発ＧＵＩ６００には、いずれの方法でレイアウト定義されるかの判別可能な情報が含まれている。図３２のフローチャートを説明する前に、図３４（一括作成の操作をするための画面）について説明する。
【０３０３】
図３４は、ＳＱＬ文とＲＥＳＴ方式の両方でレイアウト定義するための画面を説明するための図である。
【０３０４】
ＳＱＬ文でレイアウト定義をする図９、ＲＥＳＴ方式でレイアウト定義をする図２５と異なるのは次の点である。すなわち一括作成情報６０４によりレイアウト定義の操作をする画面を表示したときに、“ＳＱＬで一括作成”３４０１を操作するタブ（３４００ａ）または、“ＲＥＳＴで一括作成”３４０２を操作するタブ（３４００ｂ）を開発者に明示的に選択させる部分が異なる。
【０３０５】
さらに、“ＲＥＳＴで一括作成”３４０２をするタブを選択した場合（３４００ｂ）には、ＲＥＳＴ方式の中でも“ＪＳＯＮ形式”、“ＸＭＬ形式”、“ＣＳＶ形式”などいずれの方法により一括作成するのかを、プルダウンメニュー３４０３により開発者に選択させる。
【０３０６】
以上により、プログラム開発装置１０１は、開発者が選択した方法で一括作成の定義させることが可能となる。またプログラム開発装置１０１は、内部的には、いずれの方法で一括作成の定義をするのかをクエリ種別として記憶することができる。
【０３０７】
ステップＳ３２０１においては、ＳＱＬ文による方式かＲＥＳＴ方式が判断される。具体的には、前述のクエリ種別により一括作成の方式を判別する。
【０３０８】
レイアウト定義が、“ＳＱＬ文による方式として定義されている”と判断された場合には、ステップＳ３２０２に進む。“ＲＥＳＴ方式として定義されている”と判断された場合には、ステップＳ３２０３に進む。
【０３０９】
ステップＳ３２０２においては、ＳＱＬ文による方式によりレイアウト定義を一括作成する処理を実施する。具体的には、図１４において説明したフローチャートに対応する処理を実施する。
【０３１０】
ステップＳ３２０３においては、ＲＥＳＴ方式によりレイアウト定義を一括作成する処理を実施する。具体的には、図２７において説明したフローチャートに対応する処理を実施する。図２７のフローチャートは、ＪＳＯＮ形式の場合を説明したものであるが、“ＸＭＬ形式”、“ＣＳＶ形式”など他の方法を図３４のプルダウンメニュー３４０３により選択されている場合には、各々対応した処理（不図示）を実行する。具体的には、プルダウンメニュー３４０３により選択したクエリ種別により分岐し、各々分岐した処理を実行する。レイアウト定義を一括作成した後、一括作成情報はレイアウト定義記憶部３２１に記憶される。
【０３１１】
図３６は、ＳＱＬ文とＲＥＳＴ方式の両方を用いてレイアウト生成した場合のレイアウト定義のデータ構成の一例を示す図である。図３６においては、図１５のＳＱＬ文により一括作成されたレイアウト（クエリ種別３６０２が“ＳＱＬ”の場合）と、図２８のＲＥＳＴ方式により一括作成されたレイアウト（クエリ種別３６０２が“ＲＥＳＴ（ＪＳＯＮ）”の場合）が混在したデータ構成となっている。クエリ種別３６０２の記載により、一括作成時の方式を判別できるようにしてもよい。また、レイアウト定義記憶部３２１にクエリ種別３６０２を記憶しなくとも、“接続先＆データ取得式”３６０３に記載された内容を文字列として解析する、などによりクエリ種別を判別するようにしてもよい。
【０３１２】
前述するフローチャートは、あくまで一例である。両方式に共通した処理がある場合には、分岐するタイミングと、分岐後にステップＳ３２０２およびステップＳ３２０３において実施する処理は、前述の説明と異なるものであってもよい。
【０３１３】
図３３は、アクション定義から呼び出されるクエリの実行処理を、ＳＱＬ文とＲＥＳＴ方式の両方で定義可能な場合の分岐処理の一例を示すフローチャートである。アクション定義により定義された処理は、例えば図１８の検索ボタン１８０１がクリックされると、アプリケーションクライアント１０４およびアプリケーションサーバ１０５のＣＰＵ２０１により協調して処理される。
【０３１４】
前述の説明では、アクション定義により定義された処理の実行について、ＳＱＬ文による方式とＲＥＳＴ方式を個別に説明した（図２２および図３１）。
【０３１５】
しかし、前述の通り、開発ＧＵＩ６００のアクション定義６０５によりアクション定義を行うが、クエリ定義毎に、ＳＱＬ文による方式、あるいはＲＥＳＴ方式のいずれにて定義を行うか、開発者が選択できるようにさせてもよい。すなわち、定義するアクションによってＳＱＬ文による方式、ＲＥＳＴ方式のいずれにて定義を行うかが異なってもよいし、また１つのアクション定義において、両方式が混在してもよい。図３３のフローチャートを説明する前に、図３５（アクション定義の操作をするための画面）、図３７（アクション定義のデータ構成）、図３８（クエリ定義のデータ構成）について説明する。
【０３１６】
図３５は、ＳＱＬ文とＲＥＳＴ方式の両方でアクション定義するための画面を説明するための図である。アクション定義画面３５００ｂでは、クエリ定義画面の部分のみ図３５に記載し、その他の部分は省略しているが、実際にはアクション定義画面３５００ａと同じで、“ＳＱＬによる定義”３５０１を選択しているか、“ＲＥＳＴによる定義”３５０２を選択しているかが異なるだけである。
【０３１７】
また、ＳＱＬ文でアクション定義をする図１９、ＲＥＳＴ方式でレイアウト定義をする図２９と異なるのは次の点である。すなわちアクション定義６０５によりアクション定義の操作をする画面を表示したときに、“ＳＱＬによる定義”３５０１を操作するタブ（３５００ａ）または、“ＲＥＳＴによる定義”３５０２を操作するタブ（３５００ｂ）を開発者に明示的に選択させる部分が異なる。
【０３１８】
さらに、“ＲＥＳＴによる定義”３４０２を操作するタブを選択した場合（３５００ｂ）には、ＲＥＳＴ方式の中でも“ＪＳＯＮ形式”、“ＸＭＬ形式”、“ＣＳＶ形式”などいずれの方法によりアクション定義をするのかを、プルダウンメニュー３５０３により開発者に選択させる。
【０３１９】
以上により、プログラム開発装置１０１は、開発者が選択した方法でアクション定義させることが可能となる。
【０３２０】
これにより、また、アクション定義またはクエリ定義を登録し、記憶する際に、いずれの方式で定義されたのかを指定する情報をともに登録、記憶して実行時の判別するための情報とすることが可能である。
【０３２１】
図３７は、ＳＱＬ文とＲＥＳＴ方式の両方を用いてアクションを定義した場合の、アクション定義のデータ構成の一例を示す図である。図２０のデータ構成とほぼ同じ構成である（アクション定義テーブル２０００の２００１〜２００６）。
【０３２２】
図２０と図３７の異なる点は、図３７は、クエリ種別３７０１がデータ構成に含まれている点である。これによりアクションを実行する際に、そのアクションの定義が“ＳＱＬ”形式であるか、“ＲＥＳＴ”形式であるか、ＲＥＳＴ形式であっても更にその詳細の種別が特定される。
【０３２３】
図３８は、ＳＱＬ文とＲＥＳＴ方式の両方を用いてアクションを定義した場合の、クエリ定義のデータ構成の一例を示す図である。図２１、図３０のデータ構成と、ほぼ同じ構成である。図２１若しくは図３０と、図３８の異なる点は、まずはクエリ種別３８０１がデータ構成に含まれる点である。クエリ種別３８０１に記載された種別により、接続先３８０２、データ取得式３８０３の内容が、“ＳＱＬ”形式であるか、“ＲＥＳＴ”形式であるか、ＲＥＳＴ形式であっても更にその詳細の種別が特定される。
【０３２４】
なお、図３７と図３８のクエリ種別はいずれか一方があればよい。また、実際には後述するようにクエリ種別の記載はなくともよい。
【０３２５】
ステップＳ３３０１においては、クエリ定義の方式が、ＳＱＬ文による方式か、ＲＥＳＴ方式かを判断する。具体的には、前述のクエリ種別（図３７の３７０１または図３８の３８０１）により判断される。また前述したように、クエリ種別（図３７の３７０１または図３８の３８０１）を記憶しなくとも、接続先３８０２またはデータ取得式３８０３に記載された内容を文字列として解析する、などによりクエリ種別を判別するようにしてもよい。アクションが“ＳＱＬ文による方式として定義されている”と判断された場合には、ステップＳ３３０２に進む。“ＲＥＳＴ方式として定義されている”と判断された場合には、ステップＳ３３０３に進む。
【０３２６】
ステップＳ３３０２においては、“ＳＱＬ文による方式”として、図２２のステップＳ２２１５からステップＳ２２１８までの処理を実行する。
【０３２７】
ステップＳ３３０３においては、“ＲＥＳＴ方式”として、例えばＪＳＯＮ形式であれば、図３１のステップＳ３１０１からステップＳ３１１５までの処理を実行する。また、ＲＥＳＴ方式として、ＪＳＯＮ形式以外にも、ＸＭＬ形式、ＣＳＶ形式などにより定義する場合には、ステップＳ３３０３において、各々の形式に対応する処理を実行する。そのためクエリ定義の方式が、ＲＥＳＴ方式のいずれであるかを判断して処理の分岐を行う。具体的には、前述のクエリ種別（図３７の３７０１または図３８の３８０１）により判断される。
【０３２８】
これにより、両フローチャートは、クエリ定義毎に方式を判別して分岐し、クエリ定義を実行するフローチャートとなる。
【０３２９】
以上により、レイアウト定義およびアプリケーション実行時に、ＳＱＬ文による方式とＲＥＳＴ方式によるクエリ定義の双方を混在させることが可能であることの説明を完了する。
【０３３０】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０３３１】
また、本発明におけるプログラムは、本発明に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体はコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは各装置の処理方法ごとのプログラムであってもよい。
【０３３２】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０３３３】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。
【０３３４】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。
【０３３５】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０３３６】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０３３７】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。  上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、ＯＳ（オペレーティングシステム）に供給されるスクリプトデータ等の形態から成ってもよい。
【０３３８】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０３３９】
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０３４０】
１０１  プログラム開発装置
１０２  プログラム開発サーバ
１０３  データベースサーバ
１０４  アプリケーションクライアント
１０５  アプリケーションサーバ
１０６  ＲＥＳＴサーバ
１０７  ネットワーク
３００  開発画面制御部
３０１  レイアウト定義部
３０２  一括作成部
３０３  アクション定義部
３０４  クエリ定義部
３０５  指示引渡処理生成部
３０６  記憶部
３１１  一括作成情報受付部
３１２  カラム名取得部
３１３  オブジェクト生成部
３１４  オブジェクト配置部
３１５  値設定表示部
３２１  レイアウト定義記憶部
３２２  アクション定義記憶部
３２３  クエリ定義記憶部
３３０  画面生成部
３３１  パラメータ取得部
３３２  要求引渡部
３３３  要求受付部
３３４  アクション定義取得部
３３５  検索実行制御部
３３６  結果受渡部
３３７  結果受付部
３３８  結果設定部
３３９  表示制御部
【図１】
0005445619.tif 000002
【図２】
0005445619.tif 000003
【図３】
0005445619.tif 000004
【図４】
0005445619.tif 000005
【図５】
0005445619.tif 000006
【図６】
0005445619.tif 000007
【図７】
0005445619.tif 000008
【図８】
0005445619.tif 000009
【図９】
0005445619.tif 000010
【図１０】
0005445619.tif 000011
【図１１】
0005445619.tif 000012
【図１２】
0005445619.tif 000013
【図１３】
0005445619.tif 000014
【図１４】
0005445619.tif 000015
【図１５】
0005445619.tif 000016
【図１６】
0005445619.tif 000017
【図１７】
0005445619.tif 000018
【図１８】
0005445619.tif 000019
【図１９】
0005445619.tif 000020
【図２０】
0005445619.tif 000021
【図２１】
0005445619.tif 000022
【図２２】
0005445619.tif 000023
【図２３】
0005445619.tif 000024
【図２４】
0005445619.tif 000025
【図２５】
0005445619.tif 000026
【図２６】
0005445619.tif 000027
【図２７】
0005445619.tif 000028
【図２８】
0005445619.tif 000029
【図２９】
0005445619.tif 000030
【図３０】
0005445619.tif 000031
【図３１】
0005445619.tif 000032
【図３２】
0005445619.tif 000033
【図３３】
0005445619.tif 000034
【図３４】
0005445619.tif 000035
【図３５】
0005445619.tif 000036
【図３６】
0005445619.tif 000037
【図３７】
0005445619.tif 000038
【図３８】
0005445619.tif 000039