4D v18 で導入されたプロジェクトアーキテクチャーとは、4D データベースにとって重要な進化です。プロジェクトとは読むことのできるテキストファイルで構成されており、これによって4D のコードがバージョン管理ツールの力を利用することができるようになります。これに加えて、プロジェクトアーキテクチャーは最新のライブラリーとインターフェースをネイティブにサポートします。

プロジェクトモードについてのより詳細な情報については、developer.4D.com を参照してください。

4D バイナリーデータベース(.4db ファイル)のプロジェクトへの変換は、4D シングルユーザー版のメニューコマンドを使用することで簡単にできます。書き出しは既存のデータベースの新しいバージョンを作成するだけなので、オリジナルのファイルは手付かずのまま残ります。そのため、変換の結果に満足するまで、何度でもデータベースを変換することができます。.4db データベースを開き、変更を加えて、プロジェクトへと変換して結果をみてみましょう。変換をするごとに、前回のファイルは上書きされます。

変換は一方通行の操作であることから、次のことに注意してください:

• 4D データベースがプロジェクトへと書き出されると、両方のバージョンは互いに独立したバージョンとなります。
• プロジェクトモードのデータベースを.4db ファイルとして書き出すことはできません。
• プロジェクトモードでは最新のテクノロジーが用いられているため、一部の古い機能はサポートしていません。これらの機能は可能であれば自動的にアップデートされるか、あるいは変換エラーを生成します(以下参照)。

既存の4D データベースをプロジェクトに変換する場合、.4db ファイルは変換後も手付かずのまま残されます。"Project"という名前のフォルダが.4db ファイルの隣に作成され、必要なファイルはそこに全て格納されています。

注: "Project" という名前のフォルダがすでに.4db ファイルと同階層に存在していた場合(例えば、変換がすでに一度行われていたなど)、このフォルダは変換プロセスによって上書きされます。

データベースをプロジェクトモードへと変換するには以下のようにして下さい:

1. 変換するデータベースを開く。
2. ファイル -> 書き出し -> プロジェクトに書き出しを選択します。

   

注:

• このメニュー項目はシングルユーザー版の4D でのみ利用可能です。
• このメニューコマンドはバイナリーデータベースが開いているときにのみ有効化されています。プロジェクトモードのデータベースを開いた場合には無効化されています。
• コマンドを使用して変換を行うこともできます。

変換が成功し、エラーがなにも生成されなければ、以下のようなダイアログボックスが表示されます:

• 履歴を見る: ディスク上で行われた変換の履歴ファイルを表示します。変換の過程においてアプリケーションの一部が変更されていることがありうるため、このファイルを見ることは強く推奨されます(以下の変換をチェックするを参照してください)。
• プロジェクトを開く: 4D アプリケーションを再起動し、変換されたプロジェクトを読み込みます。

データファイルは変換による影響を受けません。つまり何も変わらないということです。開発要素のみが変換されます。変換後も、データファイルは引き続き.4db ストラクチャーファイルで開くことができます。

これに加えて、.4db のResources、Logs、Web フォルダも変更なしに自動的にプロジェクトで使用されます。これによってプロジェクトの変換とテストが容易になります。

変換の最中、新しい"Project" フォルダが.4db ストラクチャーファイルと同階層に作成されます。ここにはテキストファイルの形式でアプリケーションの開発(フォーム、ストラクチャー、メソッド、トリガ、メニュー、ヘルプ、リストなど)が全て格納されます。ここには変換された4D プロジェクトのメインファイルとなる.4DProject ファイルも格納されます:

.4DProject ファイルを4D アプリケーションで開くと、プロジェクトは既存の.4db ファイルと同じResources フォルダとWeb フォルダを使用します。これにより、プロジェクトのテストが容易に行えます。

.4db データベースも引き続き開くことができ、必要であれば変更を加えて(下記参照)、再度書き出してテストすることもできます。この操作は変換に満足いただけるまで繰り返すことができます。

変換のプロセス中、デフォルトでJOSN ログファイルが作成され、変換アクションが必要なあらゆる問題がここの記録されます。このファイルでは、メッセージは3つのカテゴリー("severity" プロパティ)に分類されます。例:

• info: 変換の過程において何らかの必要なアクションが自動的に実行されたが、その結果アプリケーションのインターフェースや機能には何の影響もないことを意味します。例えば、画像がピクチャーライブラリに入っていた場合、4D はそれらをデータベースのResources フォルダへと書き出します(上記の例を参照)。

• warning: 変換の過程において何らかの必要なアクションが自動的に実行されたが、その結果アプリケーションのインターフェースや機能に差異が出る可能性があるものの、データベースの実行を妨げるほどのものではないことを意味します。Warningの場合、通常、変換で発生した差異をコードで管理できます。例えば、"Unicode モード"、"ラジオボタンを名前でグループ"などのサポートされていない互換性設定が自動的に有効化された場合などに返されます。

• error: ユーザーが自分で修復しなければならない問題が発生したことを意味します。これが発生した場合、データベースが正常に動作しない可能性があります。例えば、ハイライトボタンなどの古いフォームオブジェクトはサポートされていません。この場合、変換オペレーションを再度行う前に.4db ファイル内のボタンを自分の手で3D ボタンへと変換する必要があります。

.4db データベースに変更が必要な場合、コードまたはフォームを適切に編集し、再度ストラクチャーを書き出してください。変換の結果に満足するまで、この操作を繰り返します。

変換の過程において、一部の旧式の4D テクノロジーはより現代的な実装へと変換され、その他は編集されるか何も行われないかのどちらかです。具体的には以下のように操作が行われます:

• プロジェクトモードにはピクチャーライブラリは存在しません。変換の過程において、4D はライブラリ内の全ての画像をデータベースのResources フォルダへと書き出します。
• フォームオブジェクトおよびフォームオブジェクトプロパティはアップデートされます(これらはダイナミックフォーム と同じシンタックスを使用します)。廃止予定のパーツはサポートされません。
• サブテーブル(4D v11 以降廃止予定、サブテーブル 参照)はプロジェクトではサポートされません。
• フォームオブジェクトのネストされたグループはプロジェクトではサポートされません(グループはオブジェクトの1レベルにのみ実装されます)。変換の過程で、ネスとされたグループは最低レベルに達するまで取り出されます。
• タブ有効プロパティはプロジェクトデータベースではサポートされていません。ダイナミックフォーム では入力順はentryOrder コレクションによって管理されているからです。変換の過程において、このコレクションには既存の入力順設定(オブジェクトのレイヤーとタブ有効プロパティ)に基づいた入力順が記録されます。変換後、プロジェクトデータベースにおいて入力順が正常に変換されたかどうかを検証することができます。
• データベース互換性設定は、全て新規データベースと同じようにリセットされます。データベースの互換性設定のステータスを検証するには、変換ログファイルをご覧ください。
• フォーム互換性オプション(例: "常にフォームサイズを自動計算"、"制約付き")は全て新規フォームと同じようにリセットされます。
• スタイルシートは、"/SOURCES" フォルダ内に保存されたJSON ファイル内のCSS スタイルシートとして書き出されます。ファイル名はOSによって異なります:
• macOS の場合には"styleSheets_mac.css"
• Windows の場合には"styleSheets_windows.css"
  
  適用されたスタイルシートは、フォームオブジェクトJSON 詳細に"class" 属性として追加されます。
• CSSまたはプラットフォームフォントサイズが大きすぎて切り落とされる場合には、フォームオブジェクトの高さは自動的に最下部まで自動的に拡大されます。
• プロジェクトにおいては、出力コントロールマーカーの表示状態はフォームを閉じてその後再度開いたときには保存されていません。
• エクスプローラーのコメントは、ドキュメンテーションマークダウンファイル(標準テキスト)として書き出されます。マークダウン形式のドキュメンテーションファイルの詳細については、developer.4d.com を参照してください。

以下のフォームオブジェクトとプロパティは、カレントのインターフェース要件とは合致しないため、廃止予定となっています。これらはダイナミックフォーム ではサポートされず、プロジェクト変換ログファイル内に警告またはエラーを生成します(以下の表のコメントを参照してください)。

振る舞いの違いから、プロジェクトモードにおいてはフォーマットコマンドをデフォルトの引数で使用した場合、あるいは一部の引数を省略して使用した場合には、オブジェクトのレンダリングが異なる可能性があります。

以下のデータベースストラクチャーオプションは廃止予定となっており、編集されるか、プロジェクト変換ログファイル内にエラーを生成します(以下の表のコメントを参照してください)。

以下のツールボックスエディターと機能は、廃止予定となっており、プロジェクトではサポートされません:

変換の過程において、既存の4D ユーザーとグループは.4db ファイルから自動的に取り出され、プロジェクトのdirectory.json ファイル内に保存されます。

プロジェクトにおいては、コードはオープンなテキストファイルとして保存されるため、4D ユーザーアクセス管理はバイナリーデータベースとは同じようには動作しません。具体的には、以下のような差異があります:

• シングルユーザーモードでは、パスワードシステムは常に無効化されます:
  • ログインダイアログは表示されません。
  • カレントユーザーは常にDesignerとなります。
  • SQL サーバーとWeb サーバーの設定は無視されます(ただしクライアント/サーバー環境においては設定可能です)。

• Designer が作成したユーザーにもAdministrator が作成したユーザーにも、違いはありません。
  • メニュー、メソッド、フォームにアクセスグループやオーナーグループを割り当てることはできません。コード保護についてはバージョン管理ツール側で管理してください。
  • ユーザーとグループのID (参照) はセッション中は動的に管理されますが、保存されません。

クライアント/サーバーモードでは、プロジェクトデータベースでもバイナリーデータベースでもユーザーアクセスコントロールは使用できます。しかしながら、メニュー、メソッド、フォームを特定のグループに割り当てることはサポートされていません(セキュリティノートを参照してください)。

そのため、変換後には以下のような点に注意してください:

• "Developer" タイプのユーザーは存在しません。全てのユーザーは"User"タイプのユーザーとなります(ただしDesigner とAdminisutrator を除く)。
• グループのタイプとグループのオーナーは削除されます。
• スタティックユーザーとグループIDは取得されません(ただしDesigner (ID = 1) とAdministrator (ID = 2)を除く)。
• データベースのログでは、"user4D_id" は"user4D_alias" で置き換えられ、これはつまり4D のユーザーエイリアスです(エイリアスが定義されていない場合には4D ユーザー名)。

セキュリティノート: 

• プロジェクトモードのデータベースではメソッド(およびメニューとフォーム)へのグループの割り当てをサポートしていないため、4DACTION/ urls や 4D Write Pro / 4D View Pro を4D ユーザーアクセスを通して管理しません。お使いのデータベースでこのタイプのコントロールが使用されている場合、メソッドに対してはOn Web Connectionデータベースメソッド あるいは“4D HTML およびURL(4DACTION) 経由で利用可能” 属性を、フォーミュラに対しては を使用する必要があります。
  

• ユーザーとグループを通してアクセス権を管理する、クライアント/サーバーのプロジェクトアプリケーションをビルドした場合、必ずdirectory.json ファイルをData フォルダ内のSettings フォルダ にコピーするようにして下さい。そうでないと、生成されたサーバーアプリケーション側でこのファイルが使用ができません。

既存のカスタムオブジェクトライブラリ(Windows では.4il、macOS では.4dlibrary)は、プロジェクトで使用したい場合、個別に書き出しをしなければなりません。詳細な情報に関しては、情報を記したblog 記事を参照してください。

4D プロジェクト配布の構想は、 .4dz 圧縮ファイル に基づいており、これはストラクチャー全体が読み出しのみ(リードオンリー)になっています。これは組み込みアプリ、コンパイルされたコンポーネントが該当します。結果として、ストラクチャーを編集するコマンドはこの環境では動作せず、配布されたアプリケーションでは使用するべきではありません。これらのコマンドが呼び出された場合、コンテキストによって、コマンドは何もしないか、エラーを生成するかどちらかをします。配布されたアプリケーションにおいてストラクチャーを編集することは、以下の理由から推奨されないという点に注意してください:

• 組み込みアプリを通常のアプリケーションフォルダにインストールすることができなくなるから(一部のユーザーが書き込みアクセス権限がないことがあるため)。
• 署名されたアプリケーションの署名を無効にすることになるから。この場合、OS はアプリケーションが汚染されたと判断することがあります。
• ローカルのアプリが編集されて保存したまま、配布されたストラクチャーのバージョンをアップデートするのはかなり複雑になるから。

しかしながら、.4dz フォーマットをどうしても避けなければならず、配布された環境でもソースファイルを編集できるように"Project" フォルダをそのままにしておかなければならない場合(これは上記で説明されているように推奨されませんが)、PackProject キーが役にたつかもしれません。

ストラクチャーを編集しうるコマンドの一覧は以下の通りです:

データベースがプロジェクトへと変換されると、バックアップのアーカイブカウンター はリセットされます。これはつまり、変換されたプロジェクトでの最初のバックアップファイルの名前は、バイナリーデータベースの時の最後のアーカイブファイルのシーケンス番号にかかわらず、myBase-0001 となります。

バックアップのアーカイブカウンターは、データベースのストラクチャーファイルとリンクしています。.4DB ファイルを改名、もしくは移動させた場合、そしてもちろん.4DProject へと変換した場合などには新しいバックアップカウンターが開始されることになります。

変換されたデータベースに納得し、プロジェクトでの作業を始めたい場合、作業ディレクトリを片付けることができます:

1. アプリケーションフォルダからファイルを削除します(あるいは、バックアップディレクトリに移動する)。macOS においては、最初にパッケージを表示コマンドを最初に使用するか、あるいは.4dbase 拡張子を削除する必要があるかもしれません(以下参照)。
2. macOS においては、開発フェーズの間、.4dbase フォルダ拡張子を削除しておいてください。実際にはテキストファイルで作業してそれらをバージョン管理ツール管理下においておく都合上、ツールが直接アクセスできる必要があります。

プロジェクトが他のマシンに移動した時に、データファイルが自動的に開くようにするためには、developer.4d.com で説明があるように、プロジェクトアーキテクチャに確認を取ることができます:

1. データファイルを"data.4dd" へと名称変更します。
2. "Data" という名前のフォルダを作成し、data.4dd ファイルをこのフォルダに移動させます。
3. Data フォルダをProject フォルダと同階層におきます。