4D v18からはストラクチャーではなく「プロジェクト」

これまで4Dでのアプリ開発はストラクチャーファイル(.4db)を作ることだった。ストラクチャーファイルはバイナリファイルだ。4Dで開けば中身を見ることができるが、外部からは何が書いてあるのかわからない。このためgitのようなバージョン管理システムでソースの差分を管理することができなかった。

4D v18から「プロジェクトモード」という形で保存できるようになった。プロジェクトモードではフォームもメソッドも「Sources」というフォルダにテキストファイルで保存されている。これらのテキストファイルをテキストエディタで修正すると、変更内容が4Dのフォームエディタやメソッドエディタに表示される。外部からテキストファイルを修正すると「ストラクチャー」に変更内容が適用されるのだ。

従来からあるストラクチャーもサポートされていて、従来通りの開発方法を選んでソースをバイナリ形式で保存することもできる。こちらは「バイナリモード」と呼ぶ。新規プロジェクトを始めるとき、開発者はバイナリモードかプロジェクトモードのどちらかを選ぶことになる。バイナリモードには「プロジェクトに書き出し」を実行してプロジェクトモードに書き出すことができる。v17以前のプロジェクトはこの方法でプロジェクトモードに移行する。プロジェクトモードからバイナリモードに変換することはできない。

筆者がプロジェクトを推奨する理由はいくつかある。

1)メソッドを生成したい

2)フォームを生成したい

3)gitを使って修正箇所(差分)を知りたい

これまで1)はプロジェクトメソッドであればやっていた。JCL4D(当社ライブラリ)を使えばテーブル定義のテキストファイルからプロジェクトメソッドを生成できる。ただしオブジェクトメソッドやフォームメソッドを生成することはできなかった。熱望していた2)はほぼほぼ実現は無理、3)もあきらめていた。

2014年にパリで開催された4D Developer Summitでに参加した際に、「フォームジェネレータを作りたい、使えるコマンドはないか」と質問した時は、そのようなコマンドの実装計画はない、と回答された。2020年のv18でフォームは生成できるようになった。対応が早いことに驚く。

以下、バイナリモードを使ってみたところ、いくつか注意事項があったのでメモしておく。

□ 標準入出力フォームを生成する機能がない

ウィザードを使ったフォーム生成機能がない。ユーザモードを使ってデータを確認するときは不便だろう。もともとフォームを自動生成する仕組みを作るつもりだったので、まあいいかという感想。半年くらいかけてJCL4DにFormGeneratorを作成した。これを使えばフィールド定義ファイルからテーブルを生成、続けてメソッドとフォームを自動生成することができる。

□ スタイルシートが開発モードでは確認しづらい

実行モードでは適用される。設定がうまくできているか確認しづらいので注意。

□ 外部テキストファイルを修正した場合、アプリに反映するのに少し時間がかかる

Finder/Desktop上でファイルの入っているフォルダを表示すれば変更が適用されたりする。

□ リモートの4D Server上のソースやフォームを4D Clientで接続して編集することができない

ソースはテキストファイルなので、開発者が各自手元で修正してアップしてcommitすることになる。

これ以外にも注意点や制約がありそうだが、気付いた時点でまたブログを追加する。