FAQ
技術的な質問> 一般的な質問
技術的な質問> 一般的な質問
Q122：①MZPlatformのコンポーネントが低レベル(プログラム言語を組むことに近い)と感じております。もっと、大きいくくりのコンポーネントはないのでしょうか？
②複数の複合コンポーネントが異なる階層にある場合に、複合コンポーネントへのパラメータの受渡しは、どのようにするのが一般的でしょうか？
③データベースアクセスチュートリアルを参考に、動的にSQL文を作成する処理を作りました。その際は、SQL文中の特殊文字のエスケープ処理は、自分で作成しないといけないのでしょうか？
②複数の複合コンポーネントが異なる階層にある場合に、複合コンポーネントへのパラメータの受渡しは、どのようにするのが一般的でしょうか？
③データベースアクセスチュートリアルを参考に、動的にSQL文を作成する処理を作りました。その際は、SQL文中の特殊文字のエスケープ処理は、自分で作成しないといけないのでしょうか？
Q122-1：
MZPlatformで業務システム(データベースアクセスを伴う)を作成しようと考えており、現在、学習中です。
その際に、いくつかの質問や確認しておきたいことがありましたのでご回答よろしくお願いします。
・確認したいこと
１．MZPlatformのコンポーネントが低レベル(プログラム言語を組むことに近い)と感じております。もっと、大きいくくりのコンポーネントはないのでしょうか？
MZPlatform複合コンポーネントを自前で作成できれば、いいのですが、プログラム言語がある程度、わかる人でないと敷居が高く、実用的なものを作成するのが困難に感じております。(当方は、プログラム言語経験者が少ない状態です。)
カスタマイズを少し加えれば、実用的なシステムが出来上がるような複合コンポーネントはないのかという意味の内容になります。
２．１の内容に絡みますが、プログラム言語経験者が少ないようなケースの場合に、MZPlatformで業務アプリを作成する為のドキュメントおよびチュートリアルや機能的にすぐに使える(少しのカスタマイズで済む)ような複合コンポーネント等をいただいたりすることはできないのでしょうか？
３．１、２の内容に絡みますが、結局、MZPlatformを使いこなすためには、プログラム言語を学ぶことに近いぐらいの学習時間が最初にかかるような気がしております。さらに、その後、業務システムの作成にも、時間がかかることが考えれれます。
このような場合は、そもそも、MZPlatformを使用するべきではないのでしょうか？
以下、質問になります。
１．複数の複合コンポーネントが異なる階層にある場合に、複合コンポーネントへのパラメータの受渡しは、どのようにするのが一般的でしょうか？
今のところ、複合コンポーネント間でイベントを介してパラメータを渡す方法が複合コンポーネントの再利用性が高まるのではと思っているところです。
ただし、イベント番号での振り分けを多用しないといけなくなるので、イベント番号の管理のために、別途イベント番号対応表を作成しないといけなくなるのが問題となっております。
イメージ
最上位----複合コンポーネント１
|--複合コンポーネント２--複合コンポーネント３
のような場合に、複合コンポーネント３から、複合コンポーネント１の処理を呼び出して、結果を受け取りたいケースになります。
２．テーブル(GUI)について
セルの結合はありますでしょうか？
３．データベースアクセス時のSQL文中の特殊文字のエスケープ処理について
データベースアクセスチュートリアルを参考に、動的にSQL文を作成する処理を作りました。その際は、SQL文中の特殊文字のエスケープ処理は、自分で作成しないといけないのでしょうか？
イメージ
SELECT * FROM テーブル WHERE ID='パラメータ'
パラメータ部分を動的に変更するケースになります。パラメータに「'」などが含まれるケースです。
その際に、いくつかの質問や確認しておきたいことがありましたのでご回答よろしくお願いします。
・確認したいこと
１．MZPlatformのコンポーネントが低レベル(プログラム言語を組むことに近い)と感じております。もっと、大きいくくりのコンポーネントはないのでしょうか？
MZPlatform複合コンポーネントを自前で作成できれば、いいのですが、プログラム言語がある程度、わかる人でないと敷居が高く、実用的なものを作成するのが困難に感じております。(当方は、プログラム言語経験者が少ない状態です。)
カスタマイズを少し加えれば、実用的なシステムが出来上がるような複合コンポーネントはないのかという意味の内容になります。
２．１の内容に絡みますが、プログラム言語経験者が少ないようなケースの場合に、MZPlatformで業務アプリを作成する為のドキュメントおよびチュートリアルや機能的にすぐに使える(少しのカスタマイズで済む)ような複合コンポーネント等をいただいたりすることはできないのでしょうか？
３．１、２の内容に絡みますが、結局、MZPlatformを使いこなすためには、プログラム言語を学ぶことに近いぐらいの学習時間が最初にかかるような気がしております。さらに、その後、業務システムの作成にも、時間がかかることが考えれれます。
このような場合は、そもそも、MZPlatformを使用するべきではないのでしょうか？
以下、質問になります。
１．複数の複合コンポーネントが異なる階層にある場合に、複合コンポーネントへのパラメータの受渡しは、どのようにするのが一般的でしょうか？
今のところ、複合コンポーネント間でイベントを介してパラメータを渡す方法が複合コンポーネントの再利用性が高まるのではと思っているところです。
ただし、イベント番号での振り分けを多用しないといけなくなるので、イベント番号の管理のために、別途イベント番号対応表を作成しないといけなくなるのが問題となっております。
イメージ
最上位----複合コンポーネント１
|--複合コンポーネント２--複合コンポーネント３
のような場合に、複合コンポーネント３から、複合コンポーネント１の処理を呼び出して、結果を受け取りたいケースになります。
２．テーブル(GUI)について
セルの結合はありますでしょうか？
３．データベースアクセス時のSQL文中の特殊文字のエスケープ処理について
データベースアクセスチュートリアルを参考に、動的にSQL文を作成する処理を作りました。その際は、SQL文中の特殊文字のエスケープ処理は、自分で作成しないといけないのでしょうか？
イメージ
SELECT * FROM テーブル WHERE ID='パラメータ'
パラメータ部分を動的に変更するケースになります。パラメータに「'」などが含まれるケースです。
A122-1：
> ・確認したいこと
> １．MZPlatformのコンポーネントが低レベル(プログラム言語を組むことに近い)と感じております。もっと、大きいくくりのコンポーネントはないのでしょうか？
> MZPlatform複合コンポーネントを自前で作成できれば、いいのですが、プログラム言語がある程度、わかる人でないと敷居が高く、実用的なものを作成するのが困難に感じております。(当方は、プログラム言語経験者が少ない状態です。)
> カスタマイズを少し加えれば、実用的なシステムが出来上がるような複合コンポーネントはないのかという意味の内容になります。
MZ Platformのコンポーネントの大きさ（粒度）は、ある程度の汎用性を保ちつつ、プログラムを記述するための負担を軽減することを目標として設定されています。そのため、プログラムの論理設計（手順やアルゴリズムを考える）という点では、従来のプログラム言語を用いる場合と大きな差異はなく、ご指摘のような困難や一種の壁を感じる方もいらっしゃいます。
ご質問の「カスタマイズを少し加えれば、実用的なシステムが出来上がるような複合コンポーネント」ですが、現在、そのような複合コンポーネントは用意されておりません。これは、各企業により「実用的なシステム」の内容が大きく異なるため、少しの修正でそれらの様々な要望に対応可能であるような基本機能を用意することが困難であるためです。（なお、MZ Platform付属の「アプリケーション合成ツール」は、ご質問のようなことを目標として開発したものですが、操作性や作成できるアプリケーションという点で、機能不足の感は否めません。）
その困難さの原因として、根本的には、企業により扱うデータや、その取り扱い方が大きく異なるということが挙げられます。データの一元管理を前提とした場合、データベースの利用が必須となります。扱うデータの種類や扱い方はデータベースの構造に大きく関わります。実用システムはそれらのデータベースの構造やデータの運用方法を基本として構築されますので、その基本が企業によって大きく異なる以上、それらの違いに対応し、かつ、実用に近いものを用意するのは極めて困難と考えています。（現在、各ソフトウェアベンダーから販売されている生産管理系のソフトウェアが高価であることの一因は、顧客企業の状況に合わせたカスタマイズの負担が大きいためです。）
> ２．１の内容に絡みますが、プログラム言語経験者が少ないようなケースの場合に、MZPlatformで業務アプリを作成する為のドキュメントおよびチュートリアルや機能的にすぐに使える(少しのカスタマイズで済む)ような複合コンポーネント等をいただいたりすることはできないのでしょうか？
「このような機能を作りたいが、どうすれば良いのか」といったご質問は随時承っており、必要とあれば説明用のサンプルファイルを作成して、ご提供しております。MZ Platformを利用したアプリケーション開発では、コンポーネントを適切に組み合わせることが、機能的にも作業負荷的にも最も重要となります。現在200種類程度のコンポーネントがございますので、それらの中から適切なものをマニュアルのみを頼りにして選択するのは、慣れるまでは非常に困難です。どうぞ御遠慮なくお問い合わせください。
また、これまでに会員の方から頂いたご質問とそれに対する回答を、サンプルファイルとともに当研究会ホームページ（以下のURL）で公開しております。合わせてご覧いただければ幸いに存じます。
http://www.monozukuri.org/mzpf/mz_faq.html
> ３．１、２の内容に絡みますが、結局、MZPlatformを使いこなすためには、プログラム言語を学ぶことに近いぐらいの学習時間が最初にかかるような気がしております。さらに、その後、業務システムの作成にも、時間がかかることが考えれれます。 このような場合は、そもそも、MZPlatformを使用するべきではないのでしょうか？
MZ Platformの効果は、業務システムの作成はもちろんですが、その後の機能修正や機能拡張で大きく現れてきます。具体的には、ソースコーディングが不要なことによる作業負荷およびバグの低減です。例えば、データベースとの連携などは、通常のプログラム言語で作りこむよりもはるかに容易なはずです。
MZ Platformの使用可否は、習得に要する学習時間よりも、作成しようとされる業務システムの機能、引いては業務改善の内容に依存するものと考えます。例えば、エクセルなどの表計算ソフトで十分に対応可能ということであれば、MZPlatformをお使いになる必要はございません。実際、そのような判断をされた企業もございます。まずは、業務改善の内容を十分に検討し、その上で必要な機能を特定し、適切な実現手段を選択なさるのがよろしいかと存じます。
> 以下、質問になります。
１．複数の複合コンポーネントが異なる階層にある場合に、複合コンポーネントへのパラメータの受渡しは、どのようにするのが一般的でしょうか？
今のところ、複合コンポーネント間でイベントを介してパラメータを渡す方法が複合コンポーネントの再利用性が高まるのではと思っているところです。
ただし、イベント番号での振り分けを多用しないといけなくなるので、イベント番号の管理のために、別途イベント番号対応表を作成しないといけなくなるのが問題となっております。
イメージ
最上位----複合コンポーネント１
|--複合コンポーネント２--複合コンポーネント３
のような場合に、複合コンポーネント３から、複合コンポーネント１の処理を呼び出して、結果を受け取りたいケースになります。
このような場合にはファンクションコンポーネントを利用し、発生する処理要求イベントを上位層へつないでいって複合コンポーネント１の処理を呼び出すのがよろしいかと存じます。このとき、複合コンポーネント１の処理は、最上位層へ公開しておく必要があります。
処理要求イベントは他のイベントと違い、接続先メソッドのうち、最後に実行されたメソッドの結果を戻すという機能があります。これを次々とつないでいくことによって、バケツリレーのように結果を戻していくことができますので、イベント番号の振り分けを考える必要はございません。イベント生成コンポーネントの「処理要求イベントの発生(Object,int)」でも同様のことができますので、必要に応じて使い分けていただければと存じます。
ご参考までにサンプルアプリケーションを用意しましたので、どうぞご覧ください。こちらは、複合コンポーネント３から複合コンポーネント１に含まれるテーブルのセルデータを取得してテキストフィールドに設定するというものです。
> ２．テーブル(GUI)についてセルの結合はありますでしょうか？
セルの結合機能はございません。
> ３．データベースアクセス時のSQL文中の特殊文字のエスケープ処理についてデータベースアクセスチュートリアルを参考に、動的にSQL文を作成する処理を作りました。その際は、SQL文中の特殊文字のエスケープ処理は、自分で作成しないといけないのでしょうか？
イメージ
SELECT * FROM テーブル WHERE ID='パラメータ'
パラメータ部分を動的に変更するケースになります。パラメータに「'」などが含まれるケースです。
エスケープ処理は、ご自身で作成する必要があります。具体的には、文字列格納変数コンポーネントの「指定文字列と一致するすべての文字列を置換する(String,String)」メソッドを使い、パラメータに含まれる「'」などを「\'」に置き換えることになります。
エスケープ処理は、ファンクションコンポーネントを用いてルーチン化しておくと便利かと存じます。こちらもサンプルを用意しましたので、どうぞご覧ください。
関連ファイル：複合コンポーネント.mzax、エスケープ処理.mzax
> １．MZPlatformのコンポーネントが低レベル(プログラム言語を組むことに近い)と感じております。もっと、大きいくくりのコンポーネントはないのでしょうか？
> MZPlatform複合コンポーネントを自前で作成できれば、いいのですが、プログラム言語がある程度、わかる人でないと敷居が高く、実用的なものを作成するのが困難に感じております。(当方は、プログラム言語経験者が少ない状態です。)
> カスタマイズを少し加えれば、実用的なシステムが出来上がるような複合コンポーネントはないのかという意味の内容になります。
MZ Platformのコンポーネントの大きさ（粒度）は、ある程度の汎用性を保ちつつ、プログラムを記述するための負担を軽減することを目標として設定されています。そのため、プログラムの論理設計（手順やアルゴリズムを考える）という点では、従来のプログラム言語を用いる場合と大きな差異はなく、ご指摘のような困難や一種の壁を感じる方もいらっしゃいます。
ご質問の「カスタマイズを少し加えれば、実用的なシステムが出来上がるような複合コンポーネント」ですが、現在、そのような複合コンポーネントは用意されておりません。これは、各企業により「実用的なシステム」の内容が大きく異なるため、少しの修正でそれらの様々な要望に対応可能であるような基本機能を用意することが困難であるためです。（なお、MZ Platform付属の「アプリケーション合成ツール」は、ご質問のようなことを目標として開発したものですが、操作性や作成できるアプリケーションという点で、機能不足の感は否めません。）
その困難さの原因として、根本的には、企業により扱うデータや、その取り扱い方が大きく異なるということが挙げられます。データの一元管理を前提とした場合、データベースの利用が必須となります。扱うデータの種類や扱い方はデータベースの構造に大きく関わります。実用システムはそれらのデータベースの構造やデータの運用方法を基本として構築されますので、その基本が企業によって大きく異なる以上、それらの違いに対応し、かつ、実用に近いものを用意するのは極めて困難と考えています。（現在、各ソフトウェアベンダーから販売されている生産管理系のソフトウェアが高価であることの一因は、顧客企業の状況に合わせたカスタマイズの負担が大きいためです。）
> ２．１の内容に絡みますが、プログラム言語経験者が少ないようなケースの場合に、MZPlatformで業務アプリを作成する為のドキュメントおよびチュートリアルや機能的にすぐに使える(少しのカスタマイズで済む)ような複合コンポーネント等をいただいたりすることはできないのでしょうか？
「このような機能を作りたいが、どうすれば良いのか」といったご質問は随時承っており、必要とあれば説明用のサンプルファイルを作成して、ご提供しております。MZ Platformを利用したアプリケーション開発では、コンポーネントを適切に組み合わせることが、機能的にも作業負荷的にも最も重要となります。現在200種類程度のコンポーネントがございますので、それらの中から適切なものをマニュアルのみを頼りにして選択するのは、慣れるまでは非常に困難です。どうぞ御遠慮なくお問い合わせください。
また、これまでに会員の方から頂いたご質問とそれに対する回答を、サンプルファイルとともに当研究会ホームページ（以下のURL）で公開しております。合わせてご覧いただければ幸いに存じます。
http://www.monozukuri.org/mzpf/mz_faq.html
> ３．１、２の内容に絡みますが、結局、MZPlatformを使いこなすためには、プログラム言語を学ぶことに近いぐらいの学習時間が最初にかかるような気がしております。さらに、その後、業務システムの作成にも、時間がかかることが考えれれます。 このような場合は、そもそも、MZPlatformを使用するべきではないのでしょうか？
MZ Platformの効果は、業務システムの作成はもちろんですが、その後の機能修正や機能拡張で大きく現れてきます。具体的には、ソースコーディングが不要なことによる作業負荷およびバグの低減です。例えば、データベースとの連携などは、通常のプログラム言語で作りこむよりもはるかに容易なはずです。
MZ Platformの使用可否は、習得に要する学習時間よりも、作成しようとされる業務システムの機能、引いては業務改善の内容に依存するものと考えます。例えば、エクセルなどの表計算ソフトで十分に対応可能ということであれば、MZPlatformをお使いになる必要はございません。実際、そのような判断をされた企業もございます。まずは、業務改善の内容を十分に検討し、その上で必要な機能を特定し、適切な実現手段を選択なさるのがよろしいかと存じます。
> 以下、質問になります。
１．複数の複合コンポーネントが異なる階層にある場合に、複合コンポーネントへのパラメータの受渡しは、どのようにするのが一般的でしょうか？
今のところ、複合コンポーネント間でイベントを介してパラメータを渡す方法が複合コンポーネントの再利用性が高まるのではと思っているところです。
ただし、イベント番号での振り分けを多用しないといけなくなるので、イベント番号の管理のために、別途イベント番号対応表を作成しないといけなくなるのが問題となっております。
イメージ
最上位----複合コンポーネント１
|--複合コンポーネント２--複合コンポーネント３
のような場合に、複合コンポーネント３から、複合コンポーネント１の処理を呼び出して、結果を受け取りたいケースになります。
このような場合にはファンクションコンポーネントを利用し、発生する処理要求イベントを上位層へつないでいって複合コンポーネント１の処理を呼び出すのがよろしいかと存じます。このとき、複合コンポーネント１の処理は、最上位層へ公開しておく必要があります。
処理要求イベントは他のイベントと違い、接続先メソッドのうち、最後に実行されたメソッドの結果を戻すという機能があります。これを次々とつないでいくことによって、バケツリレーのように結果を戻していくことができますので、イベント番号の振り分けを考える必要はございません。イベント生成コンポーネントの「処理要求イベントの発生(Object,int)」でも同様のことができますので、必要に応じて使い分けていただければと存じます。
ご参考までにサンプルアプリケーションを用意しましたので、どうぞご覧ください。こちらは、複合コンポーネント３から複合コンポーネント１に含まれるテーブルのセルデータを取得してテキストフィールドに設定するというものです。
> ２．テーブル(GUI)についてセルの結合はありますでしょうか？
セルの結合機能はございません。
> ３．データベースアクセス時のSQL文中の特殊文字のエスケープ処理についてデータベースアクセスチュートリアルを参考に、動的にSQL文を作成する処理を作りました。その際は、SQL文中の特殊文字のエスケープ処理は、自分で作成しないといけないのでしょうか？
イメージ
SELECT * FROM テーブル WHERE ID='パラメータ'
パラメータ部分を動的に変更するケースになります。パラメータに「'」などが含まれるケースです。
エスケープ処理は、ご自身で作成する必要があります。具体的には、文字列格納変数コンポーネントの「指定文字列と一致するすべての文字列を置換する(String,String)」メソッドを使い、パラメータに含まれる「'」などを「\'」に置き換えることになります。
エスケープ処理は、ファンクションコンポーネントを用いてルーチン化しておくと便利かと存じます。こちらもサンプルを用意しましたので、どうぞご覧ください。
関連ファイル：複合コンポーネント.mzax、エスケープ処理.mzax