git」タグアーカイブ

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することになる。

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

4D v18のテキストベースプロジェクトでgit

4Dはv18から、プロジェクト全体をテキストファイルに書き出してgitで管理できるようになった(涙)。これまでは自力でメソッドを外部テキストファイルに書き出して共通ライブラリメソッドだけgitでバージョン管理していた。フォームはテキストに書き出すことができないし、データ構造は別の仕掛けで書き出していたり面倒だし、なんといっても自力で書き出した情報は一体として動くプロジェクトを保証するものではなかった。

早速やってみよう。今回の目的は、半年間の間に行われたあるプロジェクトの変更内容を調べるというものだ。ローカルリポジトリを使って半年前のプロジェクトと今のプロジェクトを比べる。リモートのリポジトリは不要だ。

ステップ1 プロジェクトに書き出し

20190530のソースv17をv18で開いて「ストラクチャーをプロジェクトに書き出し」を実行。パッケージの中に「Project」フォルダができている(A)。

「Sources」フォルダを見てみると感動。フォーム、メソッド、テーブルフォームとそれらやオブジェクトのメソッドが並んでいる。フォームには「.4DForm」メソッドには「.4dm」という拡張子がついているのですぐわかる。

20191217のソースv17をv18で開いて「ストラクチャーをプロジェクトに書き出し」を実行。同じように「Project」フォルダができている(B)。

ステップ2 gitリポジトリを作る

次にgitフォルダを作る。ここでは「git_work」というフォルダを作っておく。ここにgitのリポジトリを作るのだ。gitのコマンドラインツールを使う方法もあるけど、差分をグラフィカルに見たいので今回は「GitHub」アプリを使った。

File -> New Repositoryを実行。リポジトリ名「dcc_git」、git_workを選択する。

ステップ3 リポジトリに「Project」ファイルを保存してコミット

(A)を「dcc_git」フォルダにコピー。GitHubでリポジトリを開くとソースが並んでいる。

SummaryとDescriptionをタイプインして[Commit to master]をクリック。これで最初のテキストファイル群がgitリポジトリに書き込まれた。

ステップ4 比較対象の「Project」ファイルを保存

最初にコピーした(A)を(B)で上書きして(A)がなくなってしまうのだが、ご心配なく。すでに(A)の内容はgitのコミットコマンドによって.gitファイルにコピーされているのだ。.gitは隠しファイルなのでターミナルアプリを使って確認できる。さあ(A)を上書きして(B)を置き換えよう。

ステップ5 GitHubで変更箇所を確認

GtHubアプリを起動して、リポジトリ「dcc_git」を見ると...。48箇所変更されていると表示されている。4dFormをクリックすると...うう感動。フォームの修正箇所、この場合座標値が変更されているのがわかる。うれしい。

フォームの座標値が変更されたことがわかる。ピクセル単位。
メソッドはこんな風に

修正箇所がすべてリストアップされている。やってくれました4Dv18。これからの4Dライフが大きく変化しそうな瞬間でした。

思えば2014年のDeveloper Summitでフランスに行ったとき「フォームをプログラムで作成したり修正することができないの?」と質問、そのときはv15では予定なしと言われた。今回のテキストベースプロジェクトの仕組みを使えば、メソッドでフォームを生成したり、修正することができる。こんな形になって実装されてくるとは。