以下、本発明の実施の形態を、図面を参照して詳細に説明する。まず、第一の実施の形態を説明する。
図1は、本発明に係わるプログラム開発装置、プログラム開発サーバ、データベースサーバ、アプリケーションクライアント、アプリケーションサーバ、RESTサーバの構成の一例を示すシステム構成図である。
プログラム開発装置101(情報処理装置)は、開発者の操作に従って画面レイアウトおよびデータベース検索のアクションなどを定義する。プログラム開発装置101単体では、ユーザの入力を受け付け、後述するプログラム開発サーバ102(情報処理装置)に実際のプログラム生成処理をさせてもよいし、プログラム開発装置101単体でプログラム生成まで処理してもよい。
プログラム開発サーバ102a〜102bは、プログラム開発装置101により入力された開発者の指示に従って、プログラムを開発する。プログラム開発サーバ102aはLANなどのネットワーク107内に配置されてもよいし、プログラム開発サーバ102bはインターネット上やクラウド上に配置されてもよい。
データベースサーバ103a〜103b(検索サーバ)は、開発されたアプリケーションが使用するデータベースを管理するサーバであり、また本発明では開発時にも利用する。例えば、開発者が利用するためにデータベースサーバ103は、プログラム開発装置101と同一の装置で構成されていてもよいし、LANなどのネットワーク107内に配置されてもよい(データベースサーバ103a)し、またインターネット上やクラウド上に配置されてもよい(データベースサーバ103b)。また、プログラム開発装置101が、プログラム開発サーバ102と協調する場合には、プログラム開発サーバ102とデータベースサーバ103が同一の装置内に構成されていてもよい。
RESTサーバ106a〜106b(検索サーバ)は、REST方式によりウェブサービスを提供するウェブサーバであり、また本発明では開発時にも利用する。例えば、開発者が利用するためにRESTサーバ106は、プログラム開発装置101と同一の装置で構成されていてもよいし、LANなどのネットワーク107内に配置されてもよい(RESTサーバ106a)し、またインターネット上やクラウド上に配置されてもよい(RESTサーバ106b)。また、プログラム開発装置101が、プログラム開発サーバ102と協調する場合には、プログラム開発サーバ102とRESTサーバ106が同一の装置内に構成されていてもよい。
アプリケーションサーバ105a〜105bは、プログラム開発装置101で開発されたアプリケーションを実行する。LANなどのネットワーク107内に配置されてもよい(アプリケーションサーバ105a)し、またインターネット上やクラウド上に配置されてもよい(アプリケーションサーバ105b)。また、ネットワーク107、インターネット、クラウド上のデータベースサーバ103と接続して動作可能である。
アプリケーションクライアント104a〜104b(クライアント装置)は、アプリケーションサーバ105と協調してプログラム開発装置101で開発したアプリケーションプログラムを動作させる、ユーザの入力端末である。LANなどのネットワーク107内に配置されてもよい(アプリケーションクライアント104a)し、またインターネット上やクラウド上に配置されてもよい(アプリケーションクライアント104b)。携帯端末などの情報処理装置であってもよい。
図2は、本発明に係わるプログラム開発装置、プログラム開発サーバ、データベースサーバ、アプリケーションクライアント、アプリケーションサーバ、RESTサーバとして適用可能な各ハードウェア構成の一例を示すブロック図である。
図2において、CPU201は、システムバス204に接続される各デバイスを統括的に制御する。
また、ROM203あるいは外部メモリ211には、CPU201の制御プログラムであるオペレーティングシステム(OS)や、プログラム開発装置、アプリケーションクライアント、各種サーバの後述する各種機能を実現するためのプログラムが記憶されている。
RAM202は、CPU201の主メモリ、ワークエリア、一時待避領域等として機能する。
入力コントローラ205は、入力部209からの入力を制御する。この入力部209としては、特に、プログラム開発装置、アプリケーションクライアント、各種サーバでは、キーボード、マウス等のポインティングデバイスが挙げられる。
出力コントローラ206は、出力部210の表示を制御する。この出力部210としては、例えば、CRTや液晶ディスプレイ等が挙げられる。
外部メモリコントローラ207は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザーファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ211へのアクセスを制御する。加えて、外部メモリ211には、プログラム開発装置、アプリケーションクライアント、各種サーバの各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ211としては、ハードディスク(HD)やフロッピー(登録商標)ディスク(FD)、PCMCIAカードスロットにアダプタを介して接続されるコンパクトフラッシュ(登録商標)、スマートメディア等が挙げられる。
通信I/Fコントローラ208は、ネットワークを介して外部機器との通信制御処理を実行する。
本発明を実現するためのプログラム212は外部メモリ211に記録されており、必要に応じてRAM202にロードされることによりCPU201によって実行されるものである。
図3は、本発明の実施形態のソフトウェア構成を示すブロック図である。
プログラム開発装置101は、開発画面制御部300、レイアウト定義部301、一括作成部302、アクション定義部303、クエリ定義部304、指示引渡処理生成部305、記憶部306を備えている。
記憶部306は、レイアウト定義記憶部321、アクション定義記憶部322、クエリ定義記憶部323を備えている。
開発画面制御部300は、プログラム開発装置101に開発者が操作するための画面を表示し、また開発者の操作に応じて、他の機能部(301〜305、311〜315)を機能させる部分である。
レイアウト定義部301は、開発者に後述するテキストボックス、ボタン、グリッドオブジェクトなどのオブジェクト、前記複数のオブジェクトなどを1つの表示グループとするためのコンテナを配置させ、また移動、属性編集をさせる機能部である。また、レイアウト定義部301で定義されたレイアウト定義は、レイアウト定義記憶部321に記憶される。
一括作成部302は、REST方式のクエリによりRESTサーバ106から取得したレスポンスデータや、データベースのテーブルのデータ項目(カラム)のうち表示したい項目を、前述の表示グループ(グリッドオブジェクトや後述する明細書形式コンテナ)に対して一括で配置する機能部である。
本発明の実施例においては、データ項目(カラム)に対応するオブジェクトの生成を“一括作成”としているが、これはあくまで例である。必ずしも一括である必要はない。例えば、前述のデータ項目(カラム)のうち表示したい項目を配置する際に、当初はデータ項目名(カラム名)を表示するだけでオブジェクトを作成しなくともよい。この場合、実際のオブジェクトの作成は、例えば属性編集(図16)において、前述のデータ項目名(カラム名)をユーザが指定する際に、実際のオブジェクトを作成し、ユーザが属性編集しなかったデータ項目名(カラム名)に対しては、レイアウトの保存時にオブジェクトを作成する、など様々な形態が可能である。
一括作成情報受付部311は、REST方式の場合には、RESTサーバ106に対してREST方式によりレスポンスデータを要求するURL、レスポンスデータから表示するデータ項目を指定するマッピング情報、SQL文による場合は、対応させるデータベース、データベースを検索するselect文(SQL文)、パラメータとなる条件項目、さらに前述の表示グループなど、レイアウトを自動生成するための情報を受け付ける機能部である。
カラム名取得部312(データ項目取得部)は、REST方式の要求とレスポンスにより本発明を実施する場合には、指定されたマッピング情報を解析して、表示グループに配置したいテーブルのデータ項目名(カラム名)を取得する。また、実際にURLによりRESTサーバ106にレスポンスデータを要求し、マッピング情報によりレスポンスデータを処理した結果を解析して、データ項目名(カラム名)を取得してもよい。また、SQL文により本発明を実施する場合には、select文を実行し、その結果を解析する。SQL文により本発明を実施する場合には、データ項目名(カラム名)自体が、REST方式の場合のマッピング情報と同一の役割を果たすものである。
オブジェクト生成部313は、前述のデータ項目名(カラム名)に対応して表示グループに配置するオブジェクトを生成する機能部である。
オブジェクト配置部314は、前述の生成されたオブジェクトを、表示グループに配置する機能部である。
値設定表示部315は、前述の生成されたオブジェクトに、前記REST方式によりRESTサーバ106、または前記select文を用いてデータベースを実際に検索した結果の値を設定、表示させる機能部である。
アクション定義部303は、開発者にボタンがクリックなどされた場合の、前記REST方式によるRESTサーバ106の検索処理、またはSQL文によるデータベースの検索処理(アクション)などを定義させる機能部である。また、アクション定義部303で定義されたアクション定義は、アクション定義記憶部322に記憶される。
クエリ定義部304は、アクション定義と対応付け、具体的には前記REST方式の場合には、レスポンスデータを要求するURLやレスポンスデータを処理するマッピング情報、SQL文による方式の場合には、select文などの詳細を開発者に定義させる機能部である。また、クエリ定義部304で定義されたクエリ定義は、クエリ定義記憶部323に記憶される。
指示引渡処理生成部305は、後述する、指示受付オブジェクトがユーザにクリックされた際などのパラメータ取得部331、要求引渡部332に対応する処理を、アクション定義に従って予め生成しておく機能部である。実際には、指示引渡処理生成部305は、本図のようにプログラム開発装置101に備えられ、アクション定義時に実行され、生成された処理をアクション定義と結びつけて記憶してもよいし、また他の例として、アプリケーションサーバ105に備えられ、アプリケーションクライアント104に表示する画面の生成時に、指示引渡処理生成部305を実行され、前記処理を生成してもよい。いずれの場合も、指示引渡処理生成部305で生成された処理は、前記アクション定義に対応するボタンと関連付けてアプリケーションクライアント104に表示する画面情報に組み込まれる。
また、プログラム開発装置101は、RESTサーバ106、またはデータベースサーバ103と接続する。あるいは、同一筐体に含む構成であってもよい。さらにプログラム開発装置101が備える機能部の一部または全ては、プログラム開発サーバ102が備え、プログラム開発装置101には、開発者が操作する開発画面が表示され、開発者の操作内容がプログラム開発サーバ102に送られ、さらにプログラム開発サーバ102での処理結果がプログラム開発装置101に戻され、開発者が操作する操作画面に結果として表示するように構成してもよい。この場合には、プログラム開発装置101は、RESTサーバ106、またはデータベースサーバ103と直接は接続せず、プログラム開発サーバ102が、RESTサーバ106、またはデータベースサーバ103と接続することにより、検索結果を取得してもよい。
アプリケーションクライアント104は、パラメータ取得部331、要求引渡部332、結果受付部337、結果設定部338、表示制御部339を備えている。
パラメータ取得部331は、アプリケーションクライアント104のユーザがボタンをクリックするなどによりアプリケーションサーバ105に対する処理を指示した際に、処理に必要なパラメータ値などを取得する機能部である。
要求引渡部332は、前述のパラメータ取得部331で取得されたパラメータ値などを後述する要求受付部333に引き渡す機能部である。
結果受付部337は、アプリケーションサーバ105での処理結果を後述する結果受渡部336から受け付ける機能部である。
結果設定部338(当てはめ部)は、前述の結果受付部337で受け付けた処理結果を、アプリケーションクライアント104上のオブジェクトに設定する機能部である。
表示制御部339は、アプリケーションの特定の画面が生成される場合には、アプリケーションサーバ105において生成された画面を、アプリケーションクライアント104のアプリケーション上に表示する機能部である。また、既に表示されている場合には、前述の結果設定部338の設定を表示に反映する。
アプリケーションサーバ105は、画面生成部330、要求受付部333、アクション定義取得部334、検索実行制御部335、結果受渡部336を備え、またプログラム開発装置101で定義した記憶部306をアプリケーションの実行定義情報として含む。
画面生成部330は、アプリケーションクライアント104に表示するための画面をレイアウト定義に基づき生成する機能部である。
要求受付部333は、前述の要求引渡部332からアプリケーションサーバ105の処理に必要なパラメータ値などを受け付ける機能部である。
アクション定義取得部334は、アプリケーションサーバ105を動作させるために必要なアクション定義を取得する機能部である。
検索実行制御部335は、アプリケーションクライアント104から渡されたパラメータ等に基づいてアプリケーションサーバ105を動作させるため機能部である。
結果受渡部336(送信手段)は、前述の検索実行制御部335の検索結果を、アプリケーションクライアント104の結果受付部337に受け渡す機能部である。
アプリケーションクライアント104およびアプリケーションサーバ105に含まれる機能部は、プログラム開発装置101あるいはプログラム開発サーバ102に含まれていてもよい。これにより開発中の動作確認が可能となる。
図4は、本発明の実施形態のデータベースサーバ103のテーブル群の一例を示すデータ構成図であり、後述する開発およびアプリケーションの実行を説明する際に利用するものである。
注文書テーブル400は、注文結果を登録するテーブルであり、注文番号を表すorderID401、顧客名を表すcustomer402、顧客電話番号を表すtelephone403、注文受付日を表すdate404、注文の合計金額を表すtotal_price405により構成される。
注文品目テーブル410は、注文書テーブルのorderID401に対応する詳細の注文品目を登録するテーブルであり、注文書テーブルのorderID401と対応するorderID411と、商品名を表すproduct412、商品の単価を表すprice413、注文数を表すamount414により構成される。
図5は、本発明の実施形態のデータベースのテーブル群の一例を示すデータ構成図であり、図4と同様後述する開発およびアプリケーションの実行を説明する際に利用するものである。テーブル構成が異なるが、本質的に同じ情報を含む。後述する例において、使用するテーブル構成が異なっても、select文を書き換えることで同じ動作をさせることが可能であることを説明する。
注文書情報は、注文情報テーブル500と顧客テーブル510に分割され、図4では、注文書テーブル400のcustomer402およびtelephone403は、顧客テーブル510のcustomer512およびtelephone513として構成されている。両テーブルのレコード(行)は、customerID502とcustomerID511で結びつけられている。リレーショナルデータベースとしての関連付けがされていてもされていなくてもよい。
同様に図4の注文品目テーブル410は、注文数テーブル520と商品情報テーブル530に分割され、注文数テーブルのproduct523と、商品情報テーブルのproduct531で結びつけられている。
図6は、開発者がレイアウト定義指示を行う画面の一例を示す図であり、プログラム開発装置101上に表示される。開発GUI600のヘッダー601には、開発者が行う作業毎に画面一覧602、レイアウト定義603、一括作成情報604、アクション定義605が表示されている。602〜605は単なる作業状況を示すものであってもよいし、あるいはタブとして選択し処理内容を移行できてもよいが、あくまで一例である。また本例では作業している内容に従い、602〜605のタイトルの前に“*”を表示している。
作成画面一覧606には、作成済みの画面が表示されている。今回の説明では、新規画面作成ボタン607を指示することにより、開発GUI600aの構成に変わる。前記指示は、マウスによるクリック、キーボードによる操作などあるが、以降の説明では区別しない。
例では、新規画面として画面名称611に“注文確認”と入力し、過去の注文を確認するための画面レイアウトを定義する処理を行う。
作業領域612には、初期状態で新規画面のベースとなる明細書形式コンテナ613が配置される。
コンテナには、例として1件の情報を1葉で各種データを表示する帳票の作成を主な用途とし、複数の行を挿入可能な“明細書形式コンテナ”と、明細書形式コンテナの中に“行”を追加して、その“行”の中の横方向に複数のオブジェクトなどを並べることが可能な“行形式コンテナ”の2種類を使用可能である。本実施形態の例では、初期状態では前述の通り明細書形式コンテナ613が配置される。ただし、初期状態で何も配置されず開発者が明細書形式コンテナ613か行形式コンテナを自由に配置できるようにしてもよい。
レイアウト部品620には部品ボタンが含まれ、各部品ボタンはコンテナ上に配置できるオブジェクトに対応する。部品ボタンをクリックあるいは、マウスでドラッグアンドドロップすることで、指定のオブジェクトを作業領域612に配置済みの他のコンテナ中に配置可能である。例として明細書形式コンテナ作成ボタン621、行形式コンテナ作成ボタン622、テキスト作成ボタン623、テキストボックス作成ボタン624、グリッド作成ボタン625、ボタン作成ボタン626がある。
コマンド630には、他の作業に移行する場合のコマンドが含まれ、例えば一括作成情報ボタン631、属性編集ボタン632、アクション定義ボタン633がある。
図7は、開発者がレイアウト定義指示を行う操作手順の一例を簡単に説明するフローである。また図8は、レイアウトを定義する際のコンテナやオブジェクトの配置を示す一例であり、図7の説明に使用する。ここでの説明は、あくまで一例であり、レイアウト定義を途中で中断することや、コンテナやオブジェクトの種類で、配置できないときの警告などは割愛する。
ステップS701で、図6の新規画面作成ボタン607をマウスクリックすることで、明細書形式コンテナ613が配置され、レイアウト定義作業を開始する。
次に、開発者は、配置作業の内容として“配置”または“対象の移動”のいずれかを行うかを判断する。現時点では、明細書形式コンテナ613上に何も配置されていないため、新しい対象の“配置”しかできないので、ステップS702で“配置”となり、ステップS703に進む。例えば、行形式コンテナを追加するためには、まず明細書形式コンテナ613をマウスで選択し配置先としてフォーカス(ステップS703)する。更に図6の行形式コンテナ作成ボタン622をマウスクリックすると、図8の明細書形式コンテナ613aの中に階層的に(入れ子状態に)行形式コンテナ801が新規作成、挿入される(ステップS704)。同様の処理を繰り返す(ステップS706で“YES”と判断する)と行形式コンテナ802の下方に行形式コンテナ802が追加される(613b)。
次に行形式コンテナ802をフォーカス(ステップS703)してから、図6の明細書形式コンテナ作成ボタン621あるいは、テキストボックス作成ボタン624などオブジェクトを配置するボタンを選択し、コンテナあるいはオブジェクト811を新規作成、挿入(ステップS704)することができる(613c)。同様にコンテナあるいはオブジェクト812を配置することができる(613d)。行形式コンテナ内での配置は、横方向に可能である。ここでベースになる明細書形式コンテナ613からは3階層目の位置にコンテナ又はオブジェクトが配置される。このように、コンテナは階層的に配置していくことが可能である。
次に明細書形式コンテナ613dを選択して行形式コンテナ作成ボタン622をマウスクリックすると、行形式コンテナ803が新規作成、挿入される(613e)。
更に配置作業を継続する(ステップS706で“YES”と判断する)が、今度は、対象の移動を実施する(ステップS702で“対象の移動”と判断)。
対象の移動は、例えば行形式コンテナ803をドラッグし、行形式コンテナ801と行形式コンテナ802の間に移動してドロップする(ステップS705、図8の821の移動)。この時、行形式コンテナ802内に配置されているコンテナまたはオブジェクト811は、行形式コンテナ802の入れ子として定義されているため、行形式コンテナ802に伴って移動する。
同様にドラッグアンドドロップにより、コンテナまたはオブジェクト811と812を入れ替えることも可能である(図8の822の移動)。
以上の説明では、外側にあるコンテナを選択して、内側に他のコンテナ(あるいはオブジェクト)を最後の行、最右の位置に追加したが、例えば、明細書形式コンテナ613dの行形式コンテナ801と行形式コンテナ802の間を選択し、行形式コンテナ作成ボタン622をクリックすると、行形式コンテナ803が新規作成、挿入されるようにしてもよい。上記の説明はあくまで一例である。
以上でレイアウト定義作業について説明したが、本例で示したコンテナ、あるいはグリッドオブジェクトを内部に複数の項目を表示できるという意味で、“表示グループ”と呼び、レイアウトの一括作成の例として使用する。階層的には、如何に深い位置にあっても同様に対応可能である。
図9は、明細書形式コンテナにおける、一括作成によるレイアウトの自動作成を説明するための図である。
開発GUI600のコマンド630において、一括作成情報ボタン631を選択すると、一括作成のための情報を指定する画面に移行する。ここでは、接続先DB指定フィールド901およびSQL指定フィールド902を指定するテキスト入力フィールドがある。ただし、本発明に係わるプログラム開発装置101、あるいはプログラム開発サーバ102において、アプリケーション開発に係わるデータベースサーバ103を特定し、一括作成情報604においては、接続先DB指定フィールド901は指定不要としてもよい。さらにデータベースを指定する場合でも、プログラム開発装置101、あるいはプログラム開発サーバ102にデータベースサーバ103が同一の筐体に一体化した構成であってもよいことは前述したとおりである。また、実際に開発したアプリケーションが動作する際に接続するデータベースサーバ103は異なるものでもよい。画面のレイアウトを生成することが目的であるため、同じ構成あるいは同一のデータ項目(カラム)を取得できる構成であればよい。
SQL指定フィールド902においては、select文を指定する。904は、SQL指定フィールド902に図4の注文書テーブル400に対応するselect文、“select * from 注文書テーブル”が指定されている。
select文を指定し、一括作成後のオブジェクト表示先であるコンテナを、ユーザにマウスでフォーカスさせるなどして指定(表示グループ指示手段)した後、一括作成ボタン903をクリックすると、明細書形式コンテナ613aのように注文書テーブル400のデータ項目(カラム)と同数(5個)の行形式コンテナ906a〜906eが自動生成され、更に行形式コンテナ906a〜906e内に1つずつテキストボックスが生成され、各区テキストオブジェクトのラベルには、注文書テーブル400のデータ項目名(カラム名)であるorderID、customerなどが設定される。
ここで、データ項目(カラム)と同数(5個)の行形式コンテナ906a〜906eおよび対応するテキストボックスが生成、配置されたのは、904のselect文のselect句(select文実行結果として取得するデータ項目名(カラム名)を記載する部分)が“*”であることによる。すなわち、実際にテーブルのスキーマを確認し、全てのデータ項目名(カラム名)を取得し、それらに対して生成、配置したためである。
次に905では、select句に“*”を指定せず、3つのデータ項目名(カラム名)“orderID”、“customer”、“date”を具体的に指定している。これに基づいて、明細書形式コンテナ613bの通り、3個の行形式コンテナ906f〜906hとテキストボックスを生成、配置する。この場合、接続先DB指定フィールド901で指定されたデータベースサーバ103に必ずしも接続する必要はない。例えば、select句に記載されたデータ項目名(カラム名)に従ってのみ前述の自動生成、配置を行ってもよい。また、指定されたデータ項目名(カラム名)が実在のものか(例えばスペリングミスがないか)などを確認するために、データベースサーバ103に接続してもよい。
更に、select文の指定方法は、データベースの構成に従って変更可能である。例えば、図5のテーブル構成であれば、select文を次のように定義することで同様の結果を得ることができる。
“select 注文情報テーブル.orderID,顧客テーブル.customer,注文情報テーブル.date from 注文情報テーブル,顧客テーブル where 注文情報テーブル.customerID=顧客テーブル.customerID”
また、開発時と本番運用時のテーブル構成が異なっていてもよい。
また、行形式コンテナ906a〜906hに含まれるいずれのオブジェクトに、実際の検索結果が表示される。これにより開発作業時に、実際のレイアウトを確認しながらレイアウト調整を行ったり、接続先DB指定フィールド901およびSQL指定フィールド902の指定を確認したりすることが可能となる。
図10は、グリッドオブジェクトにおける、一括作成によるレイアウトの自動作成を説明するための図である。グリッドオブジェクトは、2次元の行列形式でデータを表示する表形式のオブジェクトである。
ここでは、データベースサーバ103のデータ項目名(カラム名)を表の先頭行にヘッダーとして表示し、1行毎に検索結果のレコードを挿入していく。
図10では、レイアウト定義操作により、既に明細書形式コンテナ613内に、行形式コンテナ1001、さらにその中にグリッドオブジェクト1002が配置されている前提で説明する。
SQL指定フィールド902には、1003とおり“select * from 注文品目テーブル”と指定する。
select文を指定し、一括作成後のオブジェクト表示先であるグリッドオブジェクトを、マウスでフォーカスするなどして指定(表示グループ指示手段)した後、一括作成ボタン903をクリックすると、グリッドオブジェクト1002内には、注文品目テーブルに含まれる全てのデータ項目(カラム:本例では4個)が、列方向に並ぶ。全てのデータ項目(カラム)が表示されるのは図9での説明と同様である。
一括作成が完了した後は、グリッドオブジェクト1002aのように2次元の行列(表形式)で表示される。ヘッダーの他に、注文品目テーブル410のデータ項目(カラム)が1004a〜1004dに並び、また実際のデータのうち、例えば指定した数(グリッドオブジェクト1002aの例では5レコード)分のデータが表示される。5レコードと指定するのは、レイアウト定義の操作時において検索条件を指定していないためであり、運用時には、上下に移動するスクロールバーが表示されて、検索結果の全データを設定する。
さらに図9で説明と同様、図5のテーブル構成である注文数テーブル520、商品情報テーブル530を用いたselect文を指定しても同じ結果を得ることができる。
図11は、また、グリッドオブジェクトにおける、一括作成によるレイアウトの自動作成を説明するための図であり、select句において、“*”を使用せず、検索結果として得るデータ項目名(カラム名)を明示した場合の例である。明示したデータ項目(カラム)だけが1行に並んで表示される。
詳細は、select句に関する部分については、図9の905のselect文を用いて明細書形式コンテナ613bを生成する部分、グリッドオブジェクト1002、1002bに関する部分については、図10の説明と同じであるため省略する。
図12は、明細書形式コンテナの一括作成後、更にグリッドオブジェクトの一括作成をする例を示す図である。
図9で一括作成した明細書形式コンテナ613a、613bに対しても図7,図8で説明したように、さらにコンテナまたはオブジェクトを追加することができる。図12では、明細書形式コンテナ613に行形式コンテナ1201を追加し、既存の行形式コンテナ1202と上下を入れ替える。さらに行形式コンテナ1201にグリッドオブジェクト1002を追加する。
図13は、明細書形式コンテナの一括作成後、グリッドオブジェクトの一括作成を実施した結果の例を示す図である。すなわち、図12でレイアウト定義を行った後、グリッドオブジェクト1002に対して、図11と同じ一括作成を実行した結果である。
ただし、右上の“button1”は、一括作成されたものではなく、開発者が別途追加するものである。後述の説明で使用する。
図14は、本発明の実施形態における一括作成部の処理の一例を示すフローチャートである。すなわち、図9〜図12において、開発者がプログラム開発装置101上の一括作成情報の画面で一括作成に必要なコンテナまたはグリッドオブジェクト、接続先DB指定フィールド901、SQL指定フィールド902を指定し、一括作成ボタン903をマウスクリックした後に、プログラム開発装置101のCPU201が、各ステップを実行する。あるいは、前述の通りプログラム開発装置101における開発者の操作指示を受け付けて、実際のプログラム生成処理をプログラム開発サーバ102が行う場合は、プログラム開発サーバ102のCPU201が各ステップを実施する。
ステップS1401においては、一括作成ボタン903がクリックされた際に選択されている明細書形式コンテナ(例えば図9の明細書形式コンテナ613として説明を進める)または、グリッドオブジェクト(例えば図12のグリッドオブジェクト1002として説明を進める)のIDを取得する(表示グループ受付手段)。ここで明細書形式コンテナ613のIDを“contenaA”、グリッドオブジェクト1002のIDを“gridB”とする。
ステップS1402においては、接続先DB指定フィールド901で指定されたデータベースを取得し、オープンする。
ステップS1403においては、SQL指定フィールド902を指定されたselect文を取得し、select句の記載(select文実行結果として取得するデータ項目名(カラム名)を記載する部分)を取得する。
ステップS1404においては、指定されたselect文を実行し、結果からデータ項目名(カラム名)を全て取得しカラムリストを生成する。
ステップS1407においては、データ表示先の表示グループ(前述の“contenaA”または“gridB”に対応するコンテナ、またはオブジェクト)が、明細書形式コンテナか、グリッドオブジェクトかにより分岐する。
ここでは、明細書形式コンテナ“contenaA”が選択されているとして、ステップS1411に進む。ステップS1411からステップS1418までのループ処理においては、前述のカラムリストに含まれる各データ項目(カラム)に対応するオブジェクトを表示グループ(本例では“contenaA”)に追加する処理を行う。また、カラムリストの例としては、図9の905におけるselect文から生成された“orderID”、“customer”、“date”の3個のデータ項目(カラム)を含むものとする。
ステップS1412においては、カラムリストに含まれる1つのデータ項目(カラム)に着目する(最初は“orderID”)。
ステップS1413においては、行形式コンテナを生成し、“contenaA”に追加する。さらにステップS1414においては、テキストボックスオブジェクトを1つ生成する。ステップS1415において、前記生成したテキストボックスオブジェクトのラベルに、着目中のデータ項目名(カラム名:ここでは“orderID”)を設定する。また、ステップS1416においては、前記生成したテキストボックスオブジェクトのIDにも、着目中のデータ項目名(カラム名。ここでは“orderID”)を設定する。
ステップS1417においては、前記生成したオブジェクトをステップS1413で生成した行形式コンテナに挿入する。ステップS1418においてループ処理の1回目が終了する。ここまでの処理で図9の明細書形式コンテナ613b、行形式コンテナ906fおよびその中の“orderID”が生成されたことになる。
ここで、実際のレイアウト定義記憶部321の説明をし、図14のフローチャートの生成結果の構成を合わせて説明する。
図15は、一括作成した結果を含む、レイアウト定義記憶部321におけるレイアウト定義のデータ構成の一例を示す図である。
テーブル1500は、開発者により定義されたレイアウトおよび一括作成により定義されたレイアウトのいずれも含む例である。
画面ID1501は、新規画面作成ボタン607がクリックされたときに開発中のアプリケーション中で画面に一意的に対応付けられる番号であり、現在作成している画面には“UI001”が対応付けられている。表示グループ1502には例として、明細書形式コンテナまたはグリッドオブジェクトなどが登録される。説明の現時点では、“contenaA”が登録されている(“gridB”はこの時点では作成されていない)。
接続先DB1503、SQL1504は、一括作成によりレイアウトが定義された場合に登録される情報であり、接続先DB指定フィールド901、SQL指定フィールド902で指定されたものが対応する。画面レイアウトの一括作成のためだけであれば記憶しておく必要はない。ただし、後述するとおり、一括作成の結果として、実際のデータベースからデータを検索し、表示グループ上に具体的な値を表示させるために記憶しておいてもよい(ここでは記憶することにする)。
行/列1505は、表示グループ(ここでは明細書形式コンテナまたはグリッドオブジェクト)に配置される行形式コンテナ、または列オブジェクトである。行形式コンテナも表示グループの1種であり、表示グループ1502に登録する情報として扱ってもよいが、本構成例としては、別の項目として指定する。
また、オブジェクト情報として種類1506としてオブジェクトの種類、ID1507としてオブジェクトID、Label1508としてオブジェクトのラベルが登録される。
説明をステップS1418が完了した時点に戻す。ここでは、テーブル1500の最上行のみが登録されている。すなわち、行/列1505としては、ステップS1413で生成した行形式コンテナに“lineA1”というIDが付与され登録されている。また、オブジェクト情報には、種類1506として“textbox”、ID1507として“orderID”、Label1508として同じく“orderID”が登録される(初期状態では、オブジェクトIDとラベルが同じため)。
説明を再び図14に戻す。ここでステップS1418まで完了したため、ステップS1411に戻り、ループ処理を繰り返し、データ項目(カラム)“customer”、“date”に対してステップS1411からステップS1418までの処理が繰り返し実行される。
図15において、データ項目(カラム)“customer”に対しては、行/列1505の“lineA2”に対応する情報が、データ項目(カラム)“date”に対しては、行/列1505の“lineA4”に対応する情報が登録される。
“lineA1”の“button1”と、“lineA3”の“gridB”に関しては、後で開発者の操作により追加されるものなので、この段階では存在しない。
ステップS1419においては、SQL1504に登録されたselect文により1行のデータを取得し、ステップS1420において、前記select文により検索した結果を表示する。select文の検索結果であるデータ項目名(カラム名)と、テキストボックスのオブジェクトIDが対応(一致)しているため、各データ項目(カラム)の値の登録先が特定される。これによりフローチャートの分岐の一方が完了する。
以上の処理結果が、図9の613bとなり、行形式コンテナ906f〜906hおよびその中のテキストボックスと、対応する値が表示される。
さて、次に現在、図12のレイアウト定義の状態になっているとする。図15においては、行/列1505に“lineA3”と“gridB”が追加されている。
ここで図11における1101のselect文を指定し、グリッドオブジェクト1002(オブジェクトIDは“gridB”)を選択して、一括作成ボタン903をクリックすることで実行される、図14のフローチャートを再度説明する。
ステップS1401〜ステップS1403は同じなので説明を省略する。ステップS1404では、1101のselect文のselect句から、3つのデータ項目(カラム)“product”、“price”、“amount”を含むカラムリストが生成される。
ステップS1431からステップS1437までのループ処理においては、前述のカラムリストに含まれる各データ項目(カラム:ここでは、“product”、“price”、“amount”)に対応するオブジェクトを表示グループ(本例では“gridB”)に追加する処理を行う。
ステップS1432においては、カラムリストに含まれる1つのデータ項目(カラム)に着目する(最初に“product”)。
ステップS1433においては、1列分の列オブジェクトを生成する。ステップS1434においては、列オブジェクトのIDに、着目中のデータ項目(カラム名。こでは“product”)を設定する。またステップS1435においては、前記生成した列オブジェクトのラベルにも、着目中のデータ項目名(カラム名。ここでは“product”)を設定する。
ステップS1436においては、前記生成した列オブジェクトをグリッドオブジェクト(“gridB”に追加する。ステップS1437においてループ処理の1回目が終了する。
これにより図15のテーブル1500において、行/列1505に“culumnB1”が登録される。種類1506は“culumn”(列オブジェクトであることを示す)、ID1507が“product”、Label1508が“product”として登録される。
ここでステップS1437まで完了したため、ステップS1431に戻り、ループ処理を繰り返し、データ項目(カラム)“price”、“amount”に対してステップS1431からステップS1437までの処理が繰り返し実行される。
図15において、データ項目(カラム)“price”に対しては、行/列1505の“culumnB2”に対応する情報が、データ項目(カラム)“amount”に対しては、行/列1505の“culumnB3”に対応する情報が登録される。
ステップS1438からステップS1441までにおいて、グリッドオブジェクト(“gridB”)に値を設定表示する。例えば、“5行分を表示する”というように表示レコード数が指定されているとする。
ステップS1439においては、select文により得られる検索結果のとして、1行分を取得する。ステップS1440においては、前記取り出した1行分のレコードをグリッドオブジェクトの1行になるように、また検索結果のデータ項目名(カラム名)に対応する値をグリッドの対応するオブジェクトIDを持つ列オブジェクトに設定していく。
例えばこれを5レコード分繰り返すことで、ステップS1438からステップS1441までのループ処理が完了し、図13のグリッドオブジェクト1002の表示結果となる。
ただし、前述の通り右上の“button1”は現時点では存在しない。なお、前述の通り、本フローチャートの説明で使用した接続先DB指定フィールド901で指定されたデータベースは、プログラム開発装置101と同一の装置に備わるデータベースサーバ103でもよいし、ネットワーク107上のデータベースサーバ103a、インターネット上のデータベースサーバ103bのいずれでもよい。以上で図14のフローチャートの説明を完了する。
なお、テキストボックスのオブジェクトあるいは、グリッドオブジェクトにおける列オブジェクトを図14のフローチャートにおいて、全て作成している。しかし、前述の一括作成部302で説明したとおり、この処理はあくまで一例であり、実際には、属性編集やレイアウトの保存のタイミングで生成してもよい。一括作成もそうではない場合も、本発明における“データ項目に対応する値を表示するためのオブジェクトを作成するオブジェクト作成手段”であるものとする。
図15については、図14とともに説明したが、前述したとおり一括作成された定義だけではなく、開発者による定義も含まれる。
例えば、図13の1行目の行形式コンテナにボタン作成ボタン626をクリックすることによりボタンオブジェクト“button1”を1つ追加すると、行/列1505の“lineA1”の行に、“button1”が登録される。ここで、図13等に示したように、各オブジェクト(テキストボックス、ボタンなど)は、プログラム開発装置101またはプログラム開発サーバ102が指定したままの値がラベルとして表示される。
図16は、オブジェクトの属性編集するための属性編集画面の一例を示す図である。例えばレイアウト定義画面(図13)においてテキストボックス“orderID”(1301)にフォーカスし、属性編集ボタン632をクリックすると、図16の画面に遷移し、“orderID”の各種属性を変更できる。編集対象IDは、1601に“orderID”であることが示されている。ここでは、例としてLabelの表示文字列1602を“注文番号”に変更している。その他、例としてフォント、文字サイズ、カラー(文字色)、テキストボックスに実際に入る値のデータ型(数値、文字列など)の指定などを指定できる。これらの項目は、オブジェクトの種類によって異なっていてもよい。また、コンテナについても属性編集可能としてもよい。コンテナの場合であれば、例えば枠の表示(色、太さ、立体感)、コンテナ自体へのラベル付与、などが考えられる。
また、図15のレイアウト定義においては、これらの詳細の属性は記載していなかったが、これらもレイアウト定義部に記憶してもよい。また対応付けて別の記憶部に記憶してもよい。
図17は、オブジェクトの属性編集結果が反映されたレイアウト定義のデータ構成の一例を示す図である。図17のLabel1508に図16の属性編集で変更した結果が登録されている。
図18は、一括作成とオブジェクトの属性編集を実施した画面の一例を示す図である。図13に対して、オブジェクトのラベル(グリッドオブジェクト1002の列オブジェクトを含む)を変更した結果である。
以上により、select文を用いて、プログラム開発装置101における開発者によるレイアウト定義、レイアウト定義の一括作成を行う操作、およびプログラム開発装置101またはプログラム開発サーバ102が、レイアウト定義を一括作成する処理動作の実施形態の一例の説明を完了する。
次に、前述の通りレイアウト定義された画面に、データベース検索結果の値を設定するアクション定義と、アクション定義により開発されたアプリケーションの動作について説明する。
図19は、開発者がアクション定義を行う画面の一例を示す図である。アクション定義には、引き続きプログラム開発装置101を用いる。本例では、開発GUI600のアクション定義605により、アクションを定義するものとして説明する。
前述の通り、実際の開発作業(アクション定義操作)を進めるにあたり、プログラム開発装置101単体で動作可能であってもよい。
アクション定義1901には、アクション定義の対象となっているオブジェクトIDと、そのラベルが表示されている。ここでは、図13で定義したオブジェクトID“button1”が表示されている(ラベルは“検索”と変更されている)。
アクション定義領域1902には、当初は1つのクエリ定義が可能な1行分のテキストボックスが表示されている。1つのクエリ定義に必要な情報は、クエリ名指定フィールド1903、条件項目指定フィールド1904、表示グループ指定フィールド1905の3つである。1つのアクション定義には、複数のクエリ定義を含むことが能であり、そのためには、前述のクエリ定義用の行を追加する必要がある。例えば、画面下方のクエリ追加ボタン1916をクリックして行を追加してもよいし、1つの行に入力を開始したタイミングなど何らかのイベントにより、予め空白の1行を追加するようにしてもよい。
クエリ名指定フィールド1903は、アクション定義と後述するクエリ定義を関連付けるためのものである。ここでは名前を付けて開発者に分かりやすくしているが、内部情報としては単なるクエリIDでもよい。図20、図21のテーブルでは、queryIDとして対応付けている。クエリ名で対応付ける、あるいは開発者にクエリIDを直接みせても定義上問題はない。あくまで本画面、図20、図21の構成はあくまで一例に過ぎない。
条件項目指定フィールド1904は、後述するクエリ定義内にあるselect文が、パラメータを含む形式で記載されている場合、そのパラメータに渡すための値を表示グループ上のどのテキストボックスから取得するか、など値を指定可能なオブジェクトを指定するものである。例として“id=orderID”が指定されているので、図18の画面では、式の右辺“orderID”(ラベルは“注文番号”に変更してある)から取得して、式の左辺であるパラメータ“id”に値を渡す。
表示グループ指定フィールド1905は、クエリ定義で指定した検索結果により得られる値を、どの表示グループに設定、表示させるかを指定する項目である。1行目に指定されている“contenaA”は、例えば図18の明細書形式コンテナ613に対応しており、また図15のレイアウト定義情報からは、“contenaA”上のオブジェクトとして(データベースのデータ項目(カラム)に対応するものとしては)“orderID”、“customer”、“date”があると分かる。実際の動作は、図22にて説明する。
クエリ定義領域1911は、アクション定義領域1902で指定するクエリ名指定フィールド1903に対応する表示の他に、検索DB指定フィールド1912、パラメータ指定フィールド1913、タイプ指定フィールド1914、select文指定フィールド1915から構成されている。
検索DB指定フィールド1912は、後述のクエリ定義で指定したクエリを実際に実行する際に接続するデータベースサーバ103上のデータベースを指定する。ただし、本発明に係わるアプリケーションクライアント104またはアプリケーションサーバ105においてデータベースサーバ103上のデータベースを特定し、クエリ定義毎に検索DB指定フィールド1912は指定不要としてもよい。なお、データベースサーバ103は、アプリケーションサーバ105と同一の筐体に一体化した構成として動作していてもよいし、ネットワーク107上のデータベースサーバ103aでも、インターネット上のデータベースサーバ103bでもよい。
パラメータ指定フィールド1913は、アクション定義領域1902の条件項目指定フィールド1904の内容と対応する情報を記載する。すなわち、後述するアプリケーションの動作において、条件項目指定フィールド1904で指定されたテキストボックス(例では“orderID”)、その他値を設定可能なオブジェクトから値を取り出し、その値を指定のパラメータ(例では“id”)に結びつける。
タイプ指定フィールド1914は、パラメータで渡される値のデータ型を指定する。後述のようにパラメータを複数記載可能とする場合には、データ型も順序を合わせて複数記載可能とする。
select文指定フィールド1915には、実際に検索に使用するselect文が記載されている。ただし、一部にパラメータを含むことが可能である。パラメータに対応する部分には、“:”など指定された記号を付与し、例えば本例では、“:id”と記載された部分がパラメータであり、前述の“id”と結びつけられた値(もとは“orderID”から取得した値)を代入する。
図19の例では、条件項目指定フィールド1904、パラメータ指定フィールド1913の記載は1つとなっているが、例えば“,”や空白区切りで複数指定できるようにしてもよい。条件項目指定フィールド1904自体を複数用意してもよい。さらに、クエリ定義側でパラメータ指定フィールド1913を用意しなくても、例えばアクション定義側で指定した順番に応じて、必ず1番目の条件項目は“praram1”、2番目の条件項目は“param2”が受け取るよう対応付けられていてもよい。
また、本例で、アクション定義とクエリ定義を分離しているのは、select文はデータベース検索式として汎用性が高く、1つのクエリ定義を様々なアクション定義から再利用するためである。図20においても説明する。再利用しない構成として、アクション定義の中の1行に直接、検索DB指定フィールド1912、select文指定フィールド1915を指定する方法をとってもよい。また、その場合、後述する図20と図21のテーブルを1つのテーブル構成にしてもよい。
図19では、1つのオブジェクト(本例では“検索”ボタン)に対してアクション定義を行ったが、アクション定義完了後、もとのレイアウト定義画面に戻り別のオブジェクトを指定して再度アクション定義画面に来ることで、1つの画面上の複数オブジェクトにアクションを定義可能である。
更に、select文の指定方法は、データベースの構成に従って変更可能である。例えば、図5のテーブル構成であれば、次のselect文を指定することで同様の結果を得ることができる。
“select 注文情報テーブル.orderID,顧客テーブル.customer,注文情報テーブル.date from 注文情報テーブル,顧客テーブル where 注文情報テーブル.customerID=顧客テーブル.customerID AND 注文情報テーブル.orderID=:id”
従って、開発時と本番運用時のテーブル構成が異なっていてもよい。
図20は、アクション定義のデータ構成の一例を示す図である。
アクション定義テーブル2000においては、アクション定義したボタンなどが配置されている画面の画面ID2001が登録されている。ただし、objectID(ボタンのID)や表示グループ2006などから一意的に特定できるのであればなくても良い。
実行順2003は、1つのオブジェクトに複数のクエリを定義した際の実行順の指定である。図19での指定例では、“button1”に対して、2つのクエリ“query001”、“query002”が定義され、その順で実行されることになる。
また、“query001”は、“button1”以外に“button3”からのアクション定義でも再利用されていることが分かる。その他の項目については、図19のアクション定義で指定した項目をそのまま登録しているので説明を省略する。
図21は、クエリ定義のデータ構成の一例を示す図である。図20のアクション定義テーブル2000のqueryと対応付けるためにqueryID2101を用いる。それ以外については、図19のクエリ定義領域1911で指定した項目をそのまま登録しているので説明を省略する。
図22は、本発明の実施形態におけるアクションの実行処理の一例を示すフローチャートである。
本処理は、アプリケーションサーバ105の画面生成部330により生成された画面が、既にアプリケーションクライアント104に表示されており、その画面においてユーザ操作により指示受付オブジェクトがクリックされた前提で実行されるアプリケーションの動作の説明である。
ステップS2201からステップS2207までは、アプリケーションクライアント104のCPU201が、各ステップを処理する。また、ステップS2211からステップS2220までは、アプリケーションサーバ105のCPU201が各ステップを処理する。またアプリケーションサーバ105は、データベースサーバ103に接続している。なお、アプリケーションクライアント104a、アプリケーションサーバ105a、データベースサーバ103aは、ネットワーク107に存在してもよいし、アプリケーションクライアント104b、アプリケーションサーバ105b、データベースサーバ103bは、インターネット上に存在してもよい。また、アプリケーションサーバ105とデータベースサーバ103は同一の情報処理装置であってもよい。
ステップS2201においては、アプリケーションクライアント104において、ユーザがアクション定義と関連付けられたボタンなどのオブジェクトをクリックした際に、後述する図23のフローチャートで生成された処理が実行される。クリックされたボタンなど(指示受付オブジェクトという)のオブジェクトID(指示受付オブジェクトID)と、図19の条件項目指定フィールド1904で指定されたオブジェクト(条件項目オブジェクトという)から値(条件値と呼ぶ)を取得する。
ステップS2202においては、ステップS2201で取得した指示受付オブジェクトのオブジェクトIDと条件値と、さらに図23で生成された処理に記憶されたqueryIDを、アプリケーションサーバ105側に引き渡す。ステップS2201とステップS2202の処理については、図23で説明する処理を、予めクライアント側の画面に組み込んでおき実行する。
ステップS2211においては、アプリケーションクライアント104から引き渡された指示受付オブジェクトのオブジェクトIDと、条件値、queryIDを受け付ける。
ステップS2212からステップS2219のループにおいては、前記受け付けたqueryIDに対する処理を実行する(queryIDは複数の可能性がある)。ここでqueryIDの処理の順番は、アクション定義記憶部322において記憶された実行順2003に従う。
ステップS2213においては、1つのqueryIDに着目する。ステップS2214においては、前記着目中のqueryIDに基づき、クエリ定義記憶部323からクエリ定義を取得する。
ステップS2215においては、クエリ定義において指定された接続先DBに接続する(必要があればオープンする)。またステップS2216においては、クエリ定義において指定されたselect文を取得する。本select文は、パラメータ部を含んだ記載をされている場合がある。
ステップS2217においては、前記select文がパラメータ部を含む場合に、アプリケーションクライアント104から受け付けたパラメータ値を代入する。ステップS2218においては、前記パラメータ値を代入済み(パラメータ値がない場合は、クエリ定義から取得したまま)のselect文を実行する。
ステップS2220では、前記検索結果が、アプリケーションクライアント104に引き渡しされる。引渡時には、queryID(表示グループ)毎の検索結果が分かるような構成で引き渡す。
アプリケーションクライアント104は、ステップS2203において、アプリケーションサーバ105から引き渡された、検索結果を受け付ける。
ステップS2204からステップS2206のループでは、アプリケーションサーバ105から受け付けた検索結果に対するループである。本ループは、queryIDと各データ項目(カラム)の2重のループである。
結果は、queryID毎(表示グループに対応する)および各データ項目(カラム)と値が対応付けられており、また各データ項目名(カラム名)は、表示グループ上の実際のオブジェクトIDと対応付けられているため、対応するオブジェクトに値を設定する。具体的には、ステップS2205において対応するオブジェクト(検索結果表示オブジェクトまたは処理結果表示オブジェクトと呼ぶことにする)に値を設定する。
なお、例えばAjaxなどにより、必要な部分のみを非同期に更新する方法でもよい。その場合には、アプリケーションクライアント104からアプリケーションサーバ105への要求および結果応答は、queryID毎に行ってもよい。
また、アプリケーションクライアント104においてユーザが指示受付オブジェクト(例えばボタンオブジェクト)をクリックした画面と、検索結果が表示される画面は異なる画面であってもよい。アクション定義には表示グループが含まれており、これはコンテナまたはグリッドオブジェクトなどとしてIDを持っているため、表示グループがどの画面に属しているかはアプリケーションサーバ105が判別してもよいし、ステップS2202においてアプリケーションクライアント104から引き渡し、ステップS2211においてアプリケーションサーバ105で受け付ける値に、画面IDを含めるようにしてもよい。そのため、図23で生成する処理において、画面IDを処理に含めてもよい。
さらに、異なる画面である場合には、レイアウト定義記憶部321に含まれるレイアウト定義から、対応する画面を生成し、アプリケーションクライアント104に表示させるとともに、前記の検索結果を受け渡すことで、本フローチャートで説明したこととが実現できる。また、この場合、値を設定するステップS2204からステップS2206までの処理は、アプリケーションサーバ105側で実施してもよい。この場合、結果受渡部336では、検索結果ではなく、画面データを、アプリケーションクライアント104の結果受付部337に渡してもよい。
さらに、アプリケーションクライアント104に表示されている画面であっても、ステップS2204からステップS2206までの処理はアプリケーションサーバ105側で実施し、表示のみアプリケーションクライアント104で実施してもよい。この場合には、画面生成部330において画面データをアプリケーションサーバ105で生成し、結果受渡部336では、検索結果ではなく、画面データを、アプリケーションクライアント104の結果受付部337に渡してもよい。
この場合、本処理は、アプリケーションサーバ105において、全画面を更新する処理でもよい。その場合には、指示要求オブジェクトIDを含む画面をレイアウト定義記憶部321から取得し、画面を生成してもよい。
以上で、図22のフローチャートの説明は完了する。
なお、以上の説明では、例えば“gridB”などと説明したが、ベースとなるコンテナからの階層を明示する必要があれば、“contenaA.lineA3.gridB”と指定するようにしてもよい(図19の表示グループ指定フィールド1905においても同様)。
図23は、アプリケーションクライアント画面上の指示受付オブジェクトに対応付ける処理(イベント処理)を生成するフローチャートの一例である。
アプリケーションクライアント104の画面上において、ユーザが指示受付オブジェクト(ボタンなど)をクリックすると、その指示受付オブジェクトに対応する処理(図22のフローチャートでは、ステップS2201とステップS2202)が起動させる。この処理は、指示受付オブジェクトに対応するアクション定義に基づいて生成され、画面内に組み込まれている。
本処理は、開発時にプログラム開発装置101またはプログラム開発サーバ102で生成してもよいし、実行時にアプリケーションサーバ105において生成してもよい。以下、実際に処理の説明をするが、システム構成に従って、ステップS2301からステップS2309の各ステップは、プログラムの開発時に本処理が生成される場合であって、プログラムの開発がプログラム開発装置101単体で行われる場合にはプログラム開発装置101のCPU201が、またプログラムの開発がプログラム開発装置101とプログラム開発サーバ102が協調して行う場合にはプログラム開発サーバ102が、アプリケーションの動作時に生成される場合にはアプリケーションサーバ105のCPU201が実行する。
ステップS2301においては、アプリケーションクライアント104の実行時において、ボタンなどの指示受付オブジェクト(図18では検索ボタン1801。以降図18を例として使用)をユーザがマウスクリックした場合(グラフィカルユーザインタフェース(GUI)上でイベントが発生した場合)、当該指示受付オブジェクト(例では、検索ボタン1801)のオブジェクトID(“button1”)を取得する必要がある。ここでは、オブジェクトIDを取得する処理を生成する。
ステップS2302からステップS2307までは、指示受付オブジェクトに対応付けられたクエリ定義のqueryIDに対する処理を生成するループである。アプリケーションサーバ105で処理するためにqueryIDをパラメータとして引き渡すためである。ただし、アプリケーションサーバ105側で、指示受付オブジェクトIDに基づきアクション定義記憶部からqueryIDを取得するように図22のフローチャートを構成する場合には、本処理の生成はなくてもよい。
ステップS2303においては、着目中のqueryIDを生成中の本処理に保持するためのコードを生成する。
ステップS2304からステップS2306においては、ステップS2303において着目中のqueryIDに引き渡すパラメータ値を取得するためのループである。
ステップS2305においては、1つの条件項目オブジェクトに着目し、その値を取得するための処理を生成する。
全てのqueryIDに対して、全ての条件項目値から値を取得する処理のコード生成が完了したら、ステップS2308において、前述までの処理で取得した指示受付オブジェクトID、queryID、queryIDのパラメータ値をアプリケーションサーバ105に引き渡す処理のコードを生成する。
ステップS2309において、上記生成した処理を一連の処理として指示受付オブジェクトに対応付ける。
ここで、対応付けとは、開発時に本処理を生成するのであれば、例えばアクション定義記憶部322において記憶させる、またアプリケーションサーバ105においてアプリケーション実行時に生成するのであれば、アプリケーションクライアント104に表示する画面内に記憶させる、などの方法がある。
以上で図23のフローチャートについて説明を完了する。
以上により、プログラム開発装置101において、開発者がselect文によりアプリケーションの動作を定義する方法と、その定義に従ったアプリケーションの動作についての一例についての説明を完了する。
次に、第二の実施の形態を説明する。第二の実施の形態は、SQL文を用いる方式以外の方式であって、レイアウトの一括作成、アクションの定義によるアプリケーション画面へのデータ項目(カラム)の表示を実施する方法としてREST方式について説明する。
本実施形態において、REST方式とは、ウェブサーバが規定するURLにより、ウェブサーバにレスポンスデータを要求する方式である。このURLには、ウェブサーバが規定する引数を含めることにより、要求するレスポンスデータを指定することができる。REST方式の要求に対して、ウェブサーバ側は、規定された形式のレスポンスデータを戻り値として戻す。戻り値としては、呼出側が容易に解析できるJSON形式、CSV形式、XML形式、その他のテキスト形式がある。本例ではJSON形式を用いて説明するが、JSON形式に制限するものではない。
また、呼出側からREST方式のURLによりレスポンスデータを要求され、規定の形式でレスポンスデータを返すウェブサービスを提供するウェブサーバを、RESTサーバ106と呼ぶことにする。
なお、RESTは、Representational State Transferの略、JSONは、Java(登録商標)Script Object Notationの略である。
図24は、RESTサーバ106に対するREST方式の要求を示すURLと対応するレスポンスデータの一例である。
REST方式のURLとして“http://hostname.jp/order/001”を指定することで、RESTサーバ106は注文書データ、注文品目データをレスポンスデータとして返す。引数として指定された“001”は注文番号を意味する。図4において、注文書テーブル400、注文品目テーブル410を、orderIDとして“001”を指定して検索する事に相当する。“http://hostname.jp/order/001”のように引数を記述する規定は、あくまであるRESTサーバ106の例である。別のRESTサーバ106であれば、“http://hostname.jp/order?order_ID=‘001’”というように、引数を記述するよう規定されていても良い。すなわち「?引数名=値&引数名=値&引数名=値・・・」というように複数の引数をRESTサーバ106に渡すことが出るよう規定されていても良い。
一方、レスポンスデータの例としては、JSON形式で記載している。データの内容としては、注文書データと注文品目データの2つの連想配列(部分データ構成)が含まれている。引数に注文番号“001”を指定しているため、“order_IDが‘001’であるレスポンスデータのみが連想配列に含まれている。注文書データは、JSON形式のデータ中、ルートに記載されたデータであることを示す“$result”に対応する連想配列である。データが一意的に決定されるため、連想配列は1レコードのみ含んでいる。
連想配列は、“キーワード:値”という形で構成されている。前記注文書データの例では、“order_id”、“customer_name”、“telephone”、“date”、“total_price”の5つのキーワードが含まれている。それぞれのキーワードに対応する値は、各々‘001’、‘山下産業(株)’、‘03−1234−5678’、‘2011/01/26’、‘1000000’である。
また、注文品目データは、“$order_items”に対応する連想配列である。正確には、ルート“$result”の下の階層にあるため、“$result.$order_items”で指定される。注文品目データの連想配列には、3レコードが含まれている。また、キーワードは4つであり、“order_id”、“product_name”、“price”、“amount”の4つである。
すなわち、本例では、“order_id”を引数として検索された2つの連想配列がレスポンスデータとして返されるものである。
図25は、REST方式に基づき、明細書形式コンテナにおける、一括作成によるレイアウトの自動作成を説明するための図である。
図25については、図9の説明とほぼ同様となるため、異なる部分を説明する。
開発GUI600において、図9における接続先DB指定フィールド901、SQL指定フィールド902のかわりに、REST方式による定義(図25)では、URL指定フィールド2501、対象配列指定フィールド2502、抽出式指定フィールド2503がある。なお対象配列のことを指定対象と呼ぶこともある(JSON形式以外では、対象配列の形式ではない場合もあるため)。
URL指定フィールド2501には、REST方式のURLを指定する。図25では、例として図24のURL、“http://hostname.jp/order/001”が指定されている。
対象配列指定フィールド2502は、レスポンスデータに含まれるいずれの連想配列を使用するかを指定するものである。図24のレスポンスデータを用いる場合であれば、注文書データの連想配列を示す“$result”、または注文品目データの連想配列を示す“$result.$order_items”のいずれかが指定される。図25においては、“$result”が指定されている。
抽出式指定フィールド2503には、連想配列のキーワードのうちのいずれを、レイアウト定義に使用するか、また使用する場合にいかなるデータ項目名(カラム名)として扱うかを対応付けるものである。“{*}”(抽出式2504a)を指定して一括作成ボタン903をクリックすると、レスポンスデータの対象配列“$result”に対応する全キーワードに対して、図9の明細書形式コンテナ613aと同様に、明細書形式コンテナ2505に一括作成処理がなさせる。すなわち、5つの行形式コンテナ2506a〜eと、連想配列“注文書データ”の5つのキーワードを見出しとするテキストオブジェクトが生成される。さらに、各テキストオブジェクトには、各キーワードに対応する値が表示される。一括作成の詳細は、図27のフローチャートにおいて説明する。
図9においては、図14のフローチャートにより、select文の検索結果である各データ項目名(カラム名)をテキストオブジェクトの見出しおよびオブジェクトIDとして用いた。REST方式で、抽出式指定フィールド2503に指定された抽出式が前述の通り“{*}”(抽出式2504a)の場合には、キーワード自体をデータ項目名(カラム名)として、同様に処理する。
連想配列の一部のキーワードについてのみを選択し、あるいは、キーワードと異なるデータ項目名(カラム名)に置き換える場合には、抽出式2504bのように、“データ項目名(カラム名):キーワード”の対応付けを定義する。
抽出式2504bでは、“order_id”、“customer_name”、“date”の3つのキーワードを抽出し、各々“orderID”、“customer”、“date”というデータ項目名(カラム名)に対応付けている。これらの指定をした上で、一括作成ボタン903をクリックすると、レスポンスデータの対象配列“$result”に対応する抽出した3キーワードに対して、図9の明細書形式コンテナ613bと同じ結果が得られる。
なお、抽出式2504bでは、“データ項目名(カラム名):キーワード”と記述することでキーワードをデータ項目名(カラム名)に対応付けるよう定義したが、データ項目名(カラム名)は省略することができる。
例えば、抽出式を“{order_id、customer_name、date}”と定義できる。この場合には、キーワード自体をデータ項目名(カラム名)とする。
図26は、REST方式に基づき、グリッドオブジェクトにおける、一括作成によるレイアウトの自動作成を説明するための図である。
図26については、図11とほぼ同様のため、異なる部分のみを説明する。
URL指定フィールド2501には図25と同様に、図24のURL、“http://hostname.jp/order/001”が入力されている。
対象配列指定フィールド2502は、注文品目データの連想配列を示す“$result.$order_items”が指定されている。
抽出式指定フィールド2503には、抽出式2601が指定されている。
これらの指定により、図24の“注文品目データ”に対応する連想配列から、“product_name”、“price”、“amount”の3つのキーワードが抽出される。また、各々のキーワードは、データ項目名(カラム名)、“product”、“price”、“amount”に対応付けられる。
一括作成ボタン903をクリックすると、図11の1102bと同様、グリッドオブジェクト2602に、前記抽出された3つのデータ項目名(カラム名)に対応する列が生成され、値が表示される。
ただし、図24のレスポンスデータ中の注文品目データに3レコードしかデータが含まれないため、表示も3行に限られる。
図27は、本発明の実施形態における一括作成部の処理の一例を示すフローチャートである。プログラム開発装置101のCPU201が、各ステップを実行する。REST方式による一括作成の処理であるが、図14で説明したフローチャート(SQL文による一括作成の処理)との違いは、戻り値であるレスポンスデータ(図24)から、SQL文の戻り値であるテーブルと同等のデータ構成を作成する部分である。図14のステップS1401〜S1404に対応する部分を、図27のステップS2701〜S2714の処理で置き換えることで実現する。
ステップS2701〜S2714においてテーブルと同等のデータ構成を作成することにより、後述するとおり、図14のフローチャートと同様の処理となる。
ステップS2701においては、一括作成ボタン903がクリックされた際に選択されている明細書形式コンテナ、またはグリッドオブジェクトのIDを、一括作成先の表示グループのIDとして取得する。
ステップS2702においては、REST方式の要求としてURL指定フィールド2501で指定したURL(例として図24のURL)を受け付け、RESTサーバ106に対して発行する。
ステップS2703においては、ステップS2702において発行した要求に対してのレスポンスデータ(例として図24のレスポンスデータ)を受信する。
ステップS2704においては、対象配列指定フィールド2502で指定した対象配列に基づき、レスポンスデータから連想配列を取得する(図24では、注文書データ、または注文品目データ)。
ステップS2705では、抽出式指定フィールド2503で指定した抽出式に基づき、カラムリストを生成する。抽出式2504aのように抽出式が“{*}”の場合には、連想配列の全キーワードを、データ項目名(カラム名)とみなして、カラムリストを作成する。抽出式2504bまたは抽出式2601のように、データ項目名(カラム名)とキーワードの具体的な対応付けが指定されている場合には、指定されたデータ項目名(カラム名)からカラムリストを作成する。
ステップS2706においては、前記カラムリストに含まれるデータ項目(カラム)により構成される、空の(データが1行もない)テーブルを生成する。
ステップS2707からステップS2714までのループ処理においては、前述の処理で取得した連想配列の各行に対する処理を1行ずつ着目して実施する。
ステップS2708においては、前記テーブルに空の行(データ項目に対応する値が設定されていない行)を1行追加する。
ステップS2709からステップS2713までのループ処理においては、前記のカラムリストに含まれる各データ項目(カラム)に対するループ処理である。
ステップS2710においては、カラムリストから1つのデータ項目(カラム)に着目する。
ステップS2711においては、抽出式に基づき、データ項目(カラム)に対応する連想配列のキーワードを取得し、連想配列の着目中の行から前記キーワードに対応する値を取得する。この値を、データ項目(カラム)に対応する値とみなす。抽出式が“{*}”で指定されている場合には、データ項目(カラム)そのものを連想配列のキーワードとする。
ステップS2712においては、テーブルの着目中の行(ステップS2708においてテーブルに追加した行)における着目中のデータ項目(カラム)に、ステップS2711で取得した値を設定する。
ステップS2709からステップS2713のループにより指定の処理を繰り返すことで、連想配列の1行分のデータのうち、カラムリストに対応するデータ項目(カラム)の値が、テーブルの1行分のデータとして設定される。ステップS2707からステップS2714までのループにより指定の処理を繰り返すことで、前記テーブルに、連想配列の全ての行、全てのデータ項目(カラム)に対して値が設定される。
ステップS2715は、図14のステップS1407に相当し、表示グループ(一括作成先)が明細書形式コンテナか、グリッドオブジェクトかに従った分岐を行う処理である。
ステップS2701で取得したIDが明細書形式コンテナのものであればステップS2716に進む。ステップS2701で取得したIDがグリッドオブジェクトのものであればステップS2717に進む。
ステップS2716は、前述の処理で生成したテーブルに従って、明細書形式コンテナに対してレイアウトの一括作成を実施する処理である。図14のステップS1411〜S1420に相当する部分と同一の処理であり、詳細の説明は省略する。
ステップS2717は、前述の処理で生成したテーブルに従って、グリッドオブジェクトに対してレイアウトの一括作成を実施する処理である。図14のステップS1431〜S1441に相当する部分と同一の処理であり、詳細の説明は省略する。
以上で、図27のフローチャートの処理の説明を完了する。
図28は、一括作成した結果を含む、レイアウト定義記憶部321におけるレイアウト定義のデータ構成の一例を示す図である。
図28の定義は、REST方式を用いたものであるが、本定義が生成される過程は、SQL文を用いた方式により、図9から図18で説明した流れとほぼ同様である。そのため、繰り返しになる部分もあるが、図28のレイアウト定義の生成過程を簡単に説明する。
まず、図25で説明したように明細書形式コンテナ613(コンテナIDは“contenaA”とする)上で、抽出式2504bを用いて一括作成をし、結果として図25の613bを得る。一括作成は図27のフローチャートのステップS2716による。
次に図12のように、開発者の操作により1行(行形式コンテナ1201)とグリッドオブジェクト1002(オブジェクトIDは“gridB”)を挿入する。
さらに、グリッドオブジェクト1002に対して、図26で説明したように抽出式2601を用いて一括作成をし、グリッドオブジェクト2602にデータ項目(カラム)および値が生成、表示される。全体のレイアウトは、グリッドオブジェクト2602に表示されたデータが3行に限定されていることを除き、図13のようになる。一括作成は図27のフローチャートのステップS2717による。
更に図13の説明と同様に、ボタンオブジェクト(オブジェクトIDは“button1”)を追加する。
更に図16での説明と同様に、各オブジェクトの属性、特に見出しを変更することで、図18と同様の画面になる。ただし前述の通り、グリッドオブジェクト2602の内容が3行であることは図18と異なる部分である。
説明を前記の作業及び一括作成処理により生成された図28のレイアウト定義のデータ構成に戻す。
図28のレイアウト定義のデータ構成は、ほぼ図17と同様である。すなわち、表示グループで指定される明細書形式コンテナ、さらに行形式コンテナ、テキストボックスやボタンなどのオブジェクトの種類、ID、Labelは同様に定義される。
異なるのはレイアウトを一括作成するため、図17では、データベースに対応する情報として“接続先DB”、“SQL”が指定されていたのに対して、図28では、REST方式として、“URL”、“対象配列”、“抽出式”が登録されることである。それぞれの情報がどのように用いられるかは、既に説明しているため、ここでは説明を省略する。
これらのレイアウト定義のデータ構成は、図25の一括作成ボタン903がクリックされ、図27のフローチャートにより実際にレイアウトされるタイミングなどでレイアウト定義記憶部321に登録される。
以上により、REST方式を用いて、プログラム開発装置101における開発者によるレイアウト定義、レイアウト定義の一括作成を行う操作、およびプログラム開発装置101またはプログラム開発サーバ102が、レイアウト定義を一括作成する処理動作の実施形態の一例の説明を完了する。
次に、REST方式によりアクション定義を行い、実際のアプリケーション動作時に、アプリケーションクライアント104とアプリケーションサーバ105が協調動作する処理について説明する。SQL文による方式と異なる部分を詳細に説明する。
図29は、開発者がREST方式に基づきアクション定義を行う画面の一例を示す図である。アクション定義には、プログラム開発装置101を用いる。本例では開発GUI600のアクション定義605によりアクション定義を行う。
REST方式による定義(図25)では、URL指定フィールド2901、対象配列指定フィールド2902、抽出式指定フィールド2903を定義する。前記項目には、各々REST方式でレスポンスデータを要求するためのURL、レスポンスデータから処理対象とする連想配列を指定する対象配列、連想配列から必要なキーワードを抽出しデータ項目(カラム)に対応付ける抽出式を定義する。なお、レイアウト作成の場合と同様、対象配列のことを指定対象と呼ぶこともある(JSON形式以外では、対象配列の形式ではない場合もあるため)。
図19での説明と同様に、条件項目指定フィールド1904とパラメータ指定フィールド1913には対応付けられた複数の項目が指定可能である。すなわち、URL指定フィールド2901において定義されるURLにおいて複数のパラメータ(例では“:id”など)が指定可能である場合には、条件項目指定フィールド1904とパラメータ指定フィールド1913には、複数の項目を指定する。
また、図19と同様に、定義内容を、アクション定義(アクション定義領域1902にて定義)とクエリ定義(クエリ定義領域1911にて定義)に分離している。アクション定義については、図20で説明したアクション定義テーブル2000として構成されるテーブルに登録、記憶される。また、クエリ定義については、後述の図30のクエリ定義テーブル2100に記憶される。
アクション定義テーブル2000に登録、記憶される定義内容ついては、SQL文による方式の場合と、REST方式による場合とで共通である。また、図20の説明において、アクション定義テーブル2000とクエリ定義テーブル2100を、1つのテーブル構成にしてもよいとした。この場合、両方式のために2種類の異なる構成のアクション定義テーブル2000を用意してもよい。あるいは、定義の異なる部分の両方を1つのテーブル構成に含むことができるようにして、単一のアクション定義テーブル2000を用意してもよい。
図30は、REST方式によるクエリ定義のデータ構成の一例を示す図である。前述の通り、クエリ定義テーブル2100を構成する定義内容は、アクション定義テーブル2000に含めてもよいが、図30では、クエリ定義テーブル2100を分離した構成として説明する。具体的には、図29のクエリ定義領域1911の内容を登録、記憶するものであり、また図21のクエリ定義テーブル2100と同様の構成であるため、異なる部分のみ説明する。
図30のクエリ定義テーブル2100の構成においては、図21のSQL文による方式として登録した接続先DB、select文のかわりに、URL、対象配列、抽出式を登録する。
URL3001には、REST方式によりRESTサーバ106にレスポンスデータを要求するURLが定義され、URLは、図29のURL指定フィールド2901で説明したようにパラメータを含むことが可能である。対象配列、抽出式は既に説明しているので省略する。
これらの定義は、アプリケーションの実行時に参照されるものであり、詳細の動作については、図31のフローチャートにおいて説明する。
なお、SQL文による方式とREST方式による場合で、クエリ定義テーブル2100はデータ構成が異なる。両方式に対して、2種類の異なるデータ構成のクエリ定義テーブル2100を用意してもよい。あるいは、定義の異なる部分の両方を1つのテーブル構成に含むことができるようにして、単一のクエリ定義テーブル2100を用意してもよい。
図31は、本発明の実施形態におけるREST方式で定義したアクションの実行処理の一例を示すフローチャートである。
本処理は、アプリケーションサーバ105の画面生成部330により生成された画面が、既にアプリケーションクライアント104に表示されており、その画面においてユーザ操作により指示受け付けオブジェクトがクリックされた前提で実行されるアプリケーションの動作の説明である。
本処理は、SQL文による方式の説明における図22に対応するものであるが、アプリケーションクライアント104側の図を省略している。すなわち、図22のステップS2201からステップ2207までを、アプリケーションクライアント104のCPU201が実行するのに応じて、図31のステップS2211からステップS2214、ステップS3101からステップS3115、ステップS2219からステップS2220までを、アプリケーションサーバ105のCPU201が実行する。各ステップについては、アプリケーションサーバ側の説明のみ行う。
また、データベースサーバ103を含めた構成については、図22での説明と同様である。
ステップS2211においては、アプリケーションクライアント104から引き渡された指示受け付けオブジェクトのオブジェクトIDと、条件値、queryIDを受け付ける。
ステップS2212からステップS2219のループにおいては、前記受け付けたqueryIDに対応する処理を実行する(queryIDは複数の可能性がある)。ここで、queryIDの処理の順番は、アクション定義記憶部322において記憶された実行順2003(図20)に従う。
ステップS2213においては、1つのqueryIDに着目する。ステップS2214においては、前記着目中のqueryIDに基づき、クエリ定義記憶部323からクエリ定義を取得する。
ステップS3101においては、前のステップS2214で取得されたクエリ定義に基づき、図30のクエリ定義テーブル2100からURLを取得する。例として“http://hostname.jp/order/:id”を取得する。
ステップS3102においては、前記URLがパラメータ部を含む場合には、アプリケーションクライアント104から受け付けたパラメータ値を代入する。例えば、前記URLにパラメータ値“001”を代入すると“http://hostname.jp/order/001”となる。
ステップS3103においては、REST方式の要求として前記パラメータ値を代入済み(パラメータ部がない場合は、図30のクエリ定義テーブル2100から取得したまま)のURLを、RESTサーバ106に対して発行する。
ステップS3104においては、ステップS3103において発行した要求に対してのレスポンスデータ(例として図24のレスポンスデータ)をRESTサーバ106から受信する。
ステップS3105においては、対象配列3002で指定され対象配列に基づき、レスポンスデータから連想配列を取得する。例えば、図24のレスポンスデータに対して、指定が“result”であれば注文書データ、“$result.$order_items”であれば注文品目データを取得する。
ステップS3106では、図30の抽出式3003で指定された抽出式に基づき、カラムリストを生成する。カラムリストの作成方法については、図27(ステップS2705)と同様なので説明を省略する。
ステップS3107においては、前記カラムリストに含まれるデータ項目(カラム)により構成される、空の(データが1行もない)テーブルを生成する。
ステップS3108からステップS3115までのループ処理においては、前述の処理で取得した連想配列の各行に対する処理を1行ずつ着目して実施する。
ステップS3109においては、前記テーブルに空の行(データ項目に対応する値が設定されていない行)を1行追加する。
ステップS3110からステップS3114までのループは、前記のカラムリストに含まれる各データ項目(カラム)に対する処理である。
ステップS3111においては、カラムリストから1つのデータ項目(カラム)に着目する。
ステップS3112においては、抽出式に基づき、データ項目名(カラム名)に対応する連想配列のキーワードを取得し、連想配列の着目中の行から前記キーワードに対応する値を取得する。この値を、データ項目(カラム)に対応する値とみなす。抽出式が“{*}”で指定されている場合には、データ項目名(カラム名)そのものを連想配列のキーワードとする。
ステップS3113においては、テーブルの着目中の行(ステップS3109においてテーブルに追加した行)における着目中のデータ項目(カラム)に、ステップS3112で取得した値を設定する。
ステップS3110からステップS3114のループにより指定の処理を繰り返すことで、連想配列の1行分のデータのうち、カラムリストに対応するデータ項目(カラム)の値が、テーブルの1行分のデータとして設定される。ステップS3108からステップS3115までのループにより指定の処理を繰り返すことで、前記テーブルに、連想配列の全ての行、抽出式でキーワードと対応付けられた全てのデータ項目(カラム)に対して値が設定される。
ステップS2220では、前記生成されたテーブルにレスポンスデータの連想配列のデータ項目(カラム)の値を設定した結果が、アプリケーションクライアント104に引き渡しされる。この結果は、SQL文による方式による場合の検索結果に相当するデータである。
なお、図22で説明したのと同様に、Ajaxなどにより非同期処理により本処理を実現してもよい、などの構成が可能である。同様に、アプリケーションサーバ105からアプリケーションクライアント104に引き渡すのは、テーブルのデータ(検索結果)ではなく、画面データである処理にすることが可能である。
以上で、図31のフローチャートの説明を完了する。
以上により、プログラム開発装置101において、開発者がREST方式によりアプリケーションの動作を定義する方法と、その定義に従ったアプリケーションの動作についての一実施形態についての説明を完了する。
次に、第三の実施の形態を説明する。前述の説明では、レイアウトの一括作成を、SQL文による方式とREST方式を個別に実行する方法として説明した。第三の実施の形態では、SQL文による方式とREST方式を、混在することが可能なプログラム開発装置101の説明をする。
図32は、レイアウトの一括作成をSQL文とREST方式の両方で定義可能な場合の分岐処理の一例を示すフローチャートである。一括作成ボタン903がクリックされると、プログラム開発装置101のCPU201が、各ステップを実行する。
レイアウト定義をいずれの方式で行うのか、開発GUI600上、一括作成情報604において開発者に選択させる、などすることができる。また、一括作成情報604における定義内容が異なるため、開発GUI600には、いずれの方法でレイアウト定義されるかの判別可能な情報が含まれている。図32のフローチャートを説明する前に、図34(一括作成の操作をするための画面)について説明する。
図34は、SQL文とREST方式の両方でレイアウト定義するための画面を説明するための図である。
SQL文でレイアウト定義をする図9、REST方式でレイアウト定義をする図25と異なるのは次の点である。すなわち一括作成情報604によりレイアウト定義の操作をする画面を表示したときに、“SQLで一括作成”3401を操作するタブ(3400a)または、“RESTで一括作成”3402を操作するタブ(3400b)を開発者に明示的に選択させる部分が異なる。
さらに、“RESTで一括作成”3402をするタブを選択した場合(3400b)には、REST方式の中でも“JSON形式”、“XML形式”、“CSV形式”などいずれの方法により一括作成するのかを、プルダウンメニュー3403により開発者に選択させる。
以上により、プログラム開発装置101は、開発者が選択した方法で一括作成の定義させることが可能となる。またプログラム開発装置101は、内部的には、いずれの方法で一括作成の定義をするのかをクエリ種別として記憶することができる。
ステップS3201においては、SQL文による方式かREST方式が判断される。具体的には、前述のクエリ種別により一括作成の方式を判別する。
レイアウト定義が、“SQL文による方式として定義されている”と判断された場合には、ステップS3202に進む。“REST方式として定義されている”と判断された場合には、ステップS3203に進む。
ステップS3202においては、SQL文による方式によりレイアウト定義を一括作成する処理を実施する。具体的には、図14において説明したフローチャートに対応する処理を実施する。
ステップS3203においては、REST方式によりレイアウト定義を一括作成する処理を実施する。具体的には、図27において説明したフローチャートに対応する処理を実施する。図27のフローチャートは、JSON形式の場合を説明したものであるが、“XML形式”、“CSV形式”など他の方法を図34のプルダウンメニュー3403により選択されている場合には、各々対応した処理(不図示)を実行する。具体的には、プルダウンメニュー3403により選択したクエリ種別により分岐し、各々分岐した処理を実行する。レイアウト定義を一括作成した後、一括作成情報はレイアウト定義記憶部321に記憶される。
図36は、SQL文とREST方式の両方を用いてレイアウト生成した場合のレイアウト定義のデータ構成の一例を示す図である。図36においては、図15のSQL文により一括作成されたレイアウト(クエリ種別3602が“SQL”の場合)と、図28のREST方式により一括作成されたレイアウト(クエリ種別3602が“REST(JSON)”の場合)が混在したデータ構成となっている。クエリ種別3602の記載により、一括作成時の方式を判別できるようにしてもよい。また、レイアウト定義記憶部321にクエリ種別3602を記憶しなくとも、“接続先&データ取得式”3603に記載された内容を文字列として解析する、などによりクエリ種別を判別するようにしてもよい。
前述するフローチャートは、あくまで一例である。両方式に共通した処理がある場合には、分岐するタイミングと、分岐後にステップS3202およびステップS3203において実施する処理は、前述の説明と異なるものであってもよい。
図33は、アクション定義から呼び出されるクエリの実行処理を、SQL文とREST方式の両方で定義可能な場合の分岐処理の一例を示すフローチャートである。アクション定義により定義された処理は、例えば図18の検索ボタン1801がクリックされると、アプリケーションクライアント104およびアプリケーションサーバ105のCPU201により協調して処理される。
前述の説明では、アクション定義により定義された処理の実行について、SQL文による方式とREST方式を個別に説明した(図22および図31)。
しかし、前述の通り、開発GUI600のアクション定義605によりアクション定義を行うが、クエリ定義毎に、SQL文による方式、あるいはREST方式のいずれにて定義を行うか、開発者が選択できるようにさせてもよい。すなわち、定義するアクションによってSQL文による方式、REST方式のいずれにて定義を行うかが異なってもよいし、また1つのアクション定義において、両方式が混在してもよい。図33のフローチャートを説明する前に、図35(アクション定義の操作をするための画面)、図37(アクション定義のデータ構成)、図38(クエリ定義のデータ構成)について説明する。
図35は、SQL文とREST方式の両方でアクション定義するための画面を説明するための図である。アクション定義画面3500bでは、クエリ定義画面の部分のみ図35に記載し、その他の部分は省略しているが、実際にはアクション定義画面3500aと同じで、“SQLによる定義”3501を選択しているか、“RESTによる定義”3502を選択しているかが異なるだけである。
また、SQL文でアクション定義をする図19、REST方式でレイアウト定義をする図29と異なるのは次の点である。すなわちアクション定義605によりアクション定義の操作をする画面を表示したときに、“SQLによる定義”3501を操作するタブ(3500a)または、“RESTによる定義”3502を操作するタブ(3500b)を開発者に明示的に選択させる部分が異なる。
さらに、“RESTによる定義”3402を操作するタブを選択した場合(3500b)には、REST方式の中でも“JSON形式”、“XML形式”、“CSV形式”などいずれの方法によりアクション定義をするのかを、プルダウンメニュー3503により開発者に選択させる。
以上により、プログラム開発装置101は、開発者が選択した方法でアクション定義させることが可能となる。
これにより、また、アクション定義またはクエリ定義を登録し、記憶する際に、いずれの方式で定義されたのかを指定する情報をともに登録、記憶して実行時の判別するための情報とすることが可能である。
図37は、SQL文とREST方式の両方を用いてアクションを定義した場合の、アクション定義のデータ構成の一例を示す図である。図20のデータ構成とほぼ同じ構成である(アクション定義テーブル2000の2001〜2006)。
図20と図37の異なる点は、図37は、クエリ種別3701がデータ構成に含まれている点である。これによりアクションを実行する際に、そのアクションの定義が“SQL”形式であるか、“REST”形式であるか、REST形式であっても更にその詳細の種別が特定される。
図38は、SQL文とREST方式の両方を用いてアクションを定義した場合の、クエリ定義のデータ構成の一例を示す図である。図21、図30のデータ構成と、ほぼ同じ構成である。図21若しくは図30と、図38の異なる点は、まずはクエリ種別3801がデータ構成に含まれる点である。クエリ種別3801に記載された種別により、接続先3802、データ取得式3803の内容が、“SQL”形式であるか、“REST”形式であるか、REST形式であっても更にその詳細の種別が特定される。
なお、図37と図38のクエリ種別はいずれか一方があればよい。また、実際には後述するようにクエリ種別の記載はなくともよい。
ステップS3301においては、クエリ定義の方式が、SQL文による方式か、REST方式かを判断する。具体的には、前述のクエリ種別(図37の3701または図38の3801)により判断される。また前述したように、クエリ種別(図37の3701または図38の3801)を記憶しなくとも、接続先3802またはデータ取得式3803に記載された内容を文字列として解析する、などによりクエリ種別を判別するようにしてもよい。アクションが“SQL文による方式として定義されている”と判断された場合には、ステップS3302に進む。“REST方式として定義されている”と判断された場合には、ステップS3303に進む。
ステップS3302においては、“SQL文による方式”として、図22のステップS2215からステップS2218までの処理を実行する。
ステップS3303においては、“REST方式”として、例えばJSON形式であれば、図31のステップS3101からステップS3115までの処理を実行する。また、REST方式として、JSON形式以外にも、XML形式、CSV形式などにより定義する場合には、ステップS3303において、各々の形式に対応する処理を実行する。そのためクエリ定義の方式が、REST方式のいずれであるかを判断して処理の分岐を行う。具体的には、前述のクエリ種別(図37の3701または図38の3801)により判断される。
これにより、両フローチャートは、クエリ定義毎に方式を判別して分岐し、クエリ定義を実行するフローチャートとなる。
以上により、レイアウト定義およびアプリケーション実行時に、SQL文による方式とREST方式によるクエリ定義の双方を混在させることが可能であることの説明を完了する。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、本発明におけるプログラムは、本発明に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体はコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは各装置の処理方法ごとのプログラムであってもよい。
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ(またはCPUやMPU)が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、DVD−ROM、磁気テープ、不揮発性のメモリカード、ROM、EEPROM、シリコンディスク、ソリッドステートドライブ等を用いることができる。
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
また、本発明は、複数の機器から構成されるシステムに適用しても、1つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。 上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、OS(オペレーティングシステム)に供給されるスクリプトデータ等の形態から成ってもよい。
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。