AIの統合
再利用可能なエイリアスでAIプロバイダーとモデルを一元管理
AIプロバイダーとモデルは、環境設定内の専用の「AI」タブで定義され、アプリケーション全体で再利用できるようになりました。
各プロバイダーには、ベースURL、APIキー、およびオプションの識別子が保存されます。接続は直接テストできるため、呼び出しを行う前にアクセスが検証されます。設定が完了すると、プロバイダーはプロジェクト設定の一部となり、ストラクチャー、ユーザー、またはデータレベルの設定全体で同じデプロイロジックに従います。
モデルの使用は、2つのアプローチによって簡素化されています。ProviderName:ModelName のようなプロバイダーベースの形式を使用してモデルを参照するか、カスタム名をプロバイダーおよびモデルIDにマッピングするモデルエイリアスを定義できます。model 属性がエイリアスと一致すると、4Dは関連するプロバイダーとモデルの設定を自動的に解決します。
これにより、コード全体でプロバイダーの詳細やモデル識別子を繰り返し記述する必要がなくなります。プロバイダーの切り替え、認証情報の更新、またはモデルの置換を行う際にも、複数のメソッドを変更する必要はありません。
プロバイダーおよびモデルの設定は、実行時にOpenAIProviders クラスを通じて引き続きアクセス可能です。必要に応じて利用可能なプロバイダーの確認、モデルエイリアスの取得、あるいは動的に動作を適応させるといったことができます。
AIの統合は、スケールアップしても管理しやすくなります。設定は一元化され、モデルの使用方法は一貫性を保ち、コードは外部の設定ではなくアプリケーションロジックに集中できます。
ユーザーインターフェース
macOS上の4DフォームにおけるLiquid Glassデザイン
4D 21 R3では、macOS上のフォームが自動的にLiquid Glassシステムスタイルを採用します。
ボタン、リスト、メニューなどの標準オブジェクトは、macOSで定義された最新の余白、透明度、視覚的フィードバックに従います。レンダリングは視覚的には変更されますが、フォームのロジックやイベント処理は変更されません。
このスタイルでは透明度や角の丸い形状が導入されるため、間隔が狭いレイアウトや要素が重なり合うレイアウトでは、若干の調整が必要になる場合があります。
フォームの構築方法を変更することなく、アプリケーションは現在の macOS の標準仕様に準拠します。
Fluent UI と Liquid Glass を使ったモダンなインターフェースの構築
4D 21 R3では、オブジェクトライブラリはWindows ではFluent UI 、macOS ではLiquid Glass に対応します。
既存のコンポーネントは、定義を変更することなく、選択したデザインシステムを使用してレンダリングされます。同様にフォームもプラットフォーム間で適応し、再設計することなく一貫性のあるモダンなインターフェースを維持します。
更新されたコンポーネントは最新の開発手法に準拠しており、追加や再生成時によりクリーンなオブジェクトメソッドが使用されます。
構造やロジックは変更されずに、プラットフォームをまたいでインターフェースが進化します。
紙面表示に最適化されたレンダリングでモダンなフォームを印刷
4D 21 R3 では、モダンな UI スタイルを採用したフォームが自動的に印刷用に最適化されます。
ウィジェットはフラットなモノクロ表示に変換され、透明度や影などの視覚効果は削除されます。レイアウト、配置、寸法は維持され、印刷される値は未保存のデータを含め、現在の状態と一致します。
この変換は自動的に実行され、印刷ロジックを変更することなく、macOSとWindowsの両方で一貫した出力を生成します。
ネットワーク
旧式ネットワークの削除
4D 21 R3 では、旧式ネットワークレイヤーが削除されました。
新規プロジェクトではデフォルトで QUIC が使用される一方、バイナリデータベースでは ServerNet が使用されます。ネットワーク層は、アプリケーションの種類に基づいて作成時に定義されます。
旧式ネットワークレイヤーを参照している既存のアプリケーションは、引き続き互換性を維持します。実行時には 4D が ServerNet を使用するため、アプリケーションは直ちに変更を加えなくても、サポートされているレイヤー上で動作し続けます。
結果としてサポートされるプロトコルが標準となり、旧式ネットワークレイヤーはその構成の一部ではなくなりました。
IMAP IDLE によるリアルタイムのメールイベント受信
4D 21 R3では、IMAPTransporter がIDLEプロトコルをサポートするようになり、アプリケーションはメールボックスの変更に対して発生したその場で反応できるようになりました。
IMAP New Transporter コマンドは、onMailCreated 、onMailDeleted 、onFlagsModified などのイベントに対してコールバック関数を定義できるリスナーオブジェクトを受け入れるようになりました。各コールバックは、トランスポーターと、メッセージ数、シーケンス番号、更新フラグなどの詳細を含むイベントオブジェクトを受け取ります。
通知は notifier プロパティを通じて制御されます。notifier.start() を呼び出すとサーバーイベントを聞く様になり、notifier.stop() を呼び出すとイベントを一時停止します。アクティブ状態では、トランスポーターは定期的なポーリングに依存することなく、常時接続を維持してイベントを配信します。
これにより、メール処理は定期的にチェックするタスクからイベント駆動型のフローへと移行します。アプリケーションはメールボックスの状態と常に同期し、不要なリクエストを削減できるほか、変更が発生すると同時に UI を更新したりロジックをトリガーしたりすることが可能になります。
4D Write Pro
階層的な番号付きリストでドキュメントを構成
4D 21 R3では、4D Write Proの番号付きリストが単なる書式設定から、構造化されたドキュメント構成へと進化しました。複数のレベルにわたる階層的な番号付けを定義できるようになり、セクション、サブセクション、およびネストされたコンテンツの一貫性を自動的に維持できます。
番号付けはリンクされた段落スタイルを通じて定義され、各レベルは構造化された階層に従います。1、1.1、 1.1.1といった形式が自動的に生成されます。
コンテンツの追加、削除、または再編成が行われた場合でも、手動での調整なしに全レベルにわたって番号付けが更新されます。
このアプローチにより、番号付けを最初からやり直したり、コードで管理したりする必要がなくなります。代わりに、定義した構造に従って番号付けが行われるため、長文や複雑な文書でも一貫性が保たれます。
4Dランゲージ
4D CLIENTからユーザーセッションに直接アクセス
4D 21 R3では、Session コマンドが4Dクライアントに拡張され、Null の代わりにリモートセッションオブジェクトを返すようになりました。
セッション ID、ユーザー名、コンテキストなどのセッションデータに、4D クライアントから直接アクセスできるようになりました。createOTP() 、getPrivileges() 、hasPrivilege() 、isGuest()などの関数は、サーバーのセッションを反映したままローカルで呼び出すことができます。
これにより、セッション情報にアクセスするためだけにコードを再構成する必要がなくなります。ロジックは使用される場所にそのまま残せるため、フローが追跡しやすくなり、クライアント・サーバーアプリケーションでよく必要となる中間メソッドの数を抑えることができます。
ハイブリッドなシナリオもより直接的になります。クライアントは、追加の調整を行うことなく、同じ認証済みコンテキスト内でOTPを生成し、Qodlyページを開くことができます。
サーバー側の制限は変更されません。権限変更機能は引き続きサーバー上でのみ実行され、クライアント側のストレージは独立したままです。
実行コンテキストに合わせてコードを再構築することなく、既存のコードにセッション処理を容易に統合できるようになります。
サーバー上で共有シングルトンおよびセッションシングルトンの関数を実行
4D 21 R3では、共有およびセッションシングルトンの関数がserver キーワードをサポートするようになり、4D クライアントから呼び出された場合でもサーバー上で実行できるようになりました。
関数は、シングルトンのサーバーサイドインスタンス上で実行されます。インスタンスが存在しない場合は自動的に作成されるため、シングルトンはクライアントとサーバーの両方に、異なるプロパティ値を持って存在することが可能になります。
これは、共有シングルトンおよびセッションシングルトンクラスに適用されます。明確化のために local キーワードを引き続き使用できる一方、ORDA データモデル関数でも明示的に server を使用することも可能です。
渡す引数および戻り値は、サーバー側のORDA 関数と同じ実行モデルに従い、ストリーム可能でなければなりません。
セッション関連のロジック、共有メモリ操作、およびサーバー依存の処理は、実行場所を制御するためにプロジェクトメソッドやORDA関数に移動させることなく、それらを定義するシングルトン内に留めることができるようになりました。
動的テキストを実際の実行可能メソッドに変換
4D 21 R3では、新しい4D.Method クラスにより、テキストとして保存されたコードをネイティブメソッドとして実行できるようになりました。
4D.Method.new() を使用して作成されたメソッドは、ネイティブメソッドと同様に動作します。実行したり、オブジェクトに格納したり、call() やapply() を使用して呼び出したりできます。パラメータは構造化された形式で渡され、This は実行中にはホストオブジェクトを返します。
実行前に、checkSyntax() はソースコードを検証し、エラーや警告に関する、行番号を含めた詳細情報を返します。
これにより、制御性を犠牲にすることなく動的なロジックを導入することができます。データベースや外部ソースに保存されたコードも、同じ言語モデルを使用して検証および実行できるため、実行時のカスタマイズがより信頼性が高く、メンテナンスも容易になります。
コンパイルされたアプリケーションでもメソッドはインタプリタモードで実行されるため、実行は環境を問わずに一貫性を保ちます。
動的な動作は、孤立したメカニズムとして取り残されるのではなく、アプリケーションに統合されます。
最新のスキーマ標準にで JSON を検証
4D 21 R3では、JSON Validate コマンドが最新のJSONスキーマ標準（Draft 2020-12）に対応しました。
スキーマには、条件付きロジック、高度な制約、拡張された形式検証を含めることができるようになりました。これにより、検証ルールをコードで実装する代わりに、より多くの検証ルールをスキーマ内で直接表現できるようになります。
その結果、検証ロジックをシステム間で重複なく共有できるようになります。バックエンド、フロントエンド、および外部サービスは同じスキーマに依存できるため、データがそれらの間で流れる際にも動作の一貫性が保たれます。
エラー報告がより正確になり、検証した結果の問題を特定・修正しやすくなりました。既存のDraft-04スキーマも引き続きサポートされており、$schema 属性に基づいて検証エンジンが自動的に選択されます。
JSONスキーマで日付を一貫して検証
4D 21 R3では、JSON Validate は、日付が文字列として保存されているか、ネイティブの4D 日付値として保存されているかに関わらず、日付に対して一貫した処理をします。
日付が内部でどのように表現されているかに関わらず、検証はスキーマ定義に従って行われます。これにより、データがJSON、API、および内部処理などでいろんなとこでやり取りをされたとしても、その際に日付の生合成が崩れてしまう現象を解消します。
スキーマは引き続き検証ルールの基準として機能し、検証前に追加の変換ロジックを必要としません。
エディタ内でコマンドパラメータのエラーを早期に検出
4D 21 R3 では、ドキュメントで定義された型や構文パターンを使用して、エディタ内で直接コマンドパラメータを検証できるよう、シンタックスチェック機能が拡張されました。
コマンドがテキスト、整数、オブジェクト、ポインターなどの特定の型、または代入可能な変数などを期待する場合、無効な引数は、実行時やシンタックスチェックの段階で表面化するのではなく、コードを記述している最中に検出されるようになりました。これは、ドキュメントに記載されたマルチタイプパラメータ、可変長引数、および可変長引数グループにも適用されます。
これにより、引数の型が間違っている場合、変数が必要な場所に代入不可能な値が渡されている場合、または特定のドキュメント化された構文に依存するコマンドのシグネチャなど、一般的なケースに対するチェックがより正確になりました。既存のコマンドシンタックスチェックがなくなってこれで置き換えられたわけではありません。4DコードエディタとVS Codeの両方で、より広範かつ正確な引数規則をカバーするように拡張されています。
これにより、コマンドの使用法がドキュメントで実際に定義されている内容に近づくため、無効な呼び出しが早期に特定され、開発サイクルのより深い段階に進む前に修正できるようになります。
4Dコンポーネント
プロジェクトインターフェースからGitLabコンポーネントの依存関係を管理
4D 21 R3では、プロジェクト依存関係インターフェースがGitLab リポジトリに対応し、既存の依存関係管理がGitHub 以外にも拡張されました。
コンポーネントは、完全なURL またはリポジトリパスのいずれかを使用して、GitLab リポジトリから直接追加できます。プライベートリポジトリは、サーバーごとに定義可能でかつ依存関係間で再利用可能なパーソナルアクセストークンを通じてサポートされます。
バージョンの選択は、他のコンポーネントと同様のロジックに従います。依存関係は、利用可能な最新リリース、特定のタグ、またはセマンティックバージョンをターゲットに設定でき、プロジェクトに統合される内容を正確に制御できます。
追加されたGitLabコンポーネントは、他の依存関係と同様に動作します。これらはプロジェクトの依存関係インターフェースに一覧表示され、プロジェクトの再起動時にインストールされ、環境を離れることなく更新、確認、または削除が可能です。
リポジトリソース間で依存関係管理が統一されるため、GitLab 上でホストされているコンポーネントも、プロジェクトの他の部分と同じライフサイクルとバージョン管理ルールに従います。
Visual Studio Code 拡張機能
VS Code でロール、権限、HTTP ハンドラーを視覚的に編集
構造化されたプロジェクトファイルは、VS Code内で専用のUIエディターを使用して直接編集できるようになりました。
ロールや権限、HTTP ハンドラーは、生の JSON ではなく視覚的なインターフェースで開かれます。フィールドは整理され、オプションはわかりやすく提示され、設定を変更するためにネストされた構造を探索したり構文を手動で管理したりする必要はありません。
また、検証機能が組み込まれています。無効な設定が混入しにくくなり、書式や構造に起因する一般的なエラーは、実行時に到達する前に回避されます。
同じファイルにいつでもテキスト形式でアクセスすることも可能です。ワークフローやツールを変更することなく、タスクに応じて直接編集とUI編集を切り替えることができます。
これにより、設定ファイルの可読性が向上し、変更時の安全性が確保され、チーム全体での共有が容易になります。同時に、VS Code 環境との完全な統合も維持されます。
VS Code で依存関係が完全に認識されるようになりました
4D 21 R3では、4D-Analyzer 拡張機能が4Dと同様にプロジェクトの依存関係を読み込みます。依存関係が自動的に解決されるため、シンタックスチェックやコード補完は4D IDEと同じコンテキストに基づいて行われ、環境を問わず一貫したフィードバックが得られます。
この拡張機能は、dependencies.json と environment4d.json の両方から依存関係を読み取ります。複数のプロジェクトで共有されるコンポーネントでも追加の設定をすることなく検出され、これらのファイルが更新されるとプロジェクトが自動的に再読み込みされるため、変更はエディタに即座に反映されます。
GitHub との連携も 4D と同じロジックに従います。コンポーネントは同じローカルストレージを使用してダウンロードされるため、重複を回避し、バージョンを同期させることができます。VS Code で GitHub セッションがすでにアクティブな場合は、それが自動的に再利用されます。そうでない場合でも、ワークフローを中断することなく拡張機能から直接セッションを開くことで、パブリックおよびプライベートリポジトリの両方にアクセスできます。
今まではVS Code は依存関係は推測するしかなかった訳ですが、今後は4Dアプリケーションと同じ依存関係、同じ構造、同じルールで動作するようになりました。
セキュリティ
HTTPSリクエストでmacOSキーチェーンの証明書を直接使用
4D 21 R3では、HTTPSリクエストおよびHTTPエージェントが、macOSキーチェーンに直接保存された証明書を使用できるようになりました。
HTTPRequest またはHTTPAgent を作成する際、storeCertificateName プロパティを使用して、名前で証明書を参照します。4Dはオペレーティングシステムを通じて証明書を解決し、証明書が見つからない場合は直ちにエラーが返されます。
これは、Windowsの証明書ストアですでに利用可能なアプローチと同じであり、同じコードをプラットフォーム間で動作させることができます。
これにより、証明書をアプリケーション環境内にファイルとして配布または保存する必要はなくなりました。証明書は引き続きシステムによって管理されるため、デプロイが簡素化され、マシン間で認証情報の処理が統一されます。