Design System オブジェクト (DSO) は、GeneXus におけるデザイン定義の枠組みが変わることを意味します。その目標は、テーマの短所をすべて解決し、生成されるアプリケーションに対するデザインの影響を高めることです。DSO は、テーマに代わるものとして作られ、テーマを進化させたものになっています。
デザインシステムの最初のバージョンは、テーマと同様に画面上のコントロールのスタイルに影響するだけでなく、それらのコントロールのレンダリングも含まれるよう設計されています。
テーマのどのような短所が対象となっているのでしょうか。Design System オブジェクトではそれがどのように改善されているのでしょうか。ここでは、こうした点について説明していきます。

テーマスキームの短所

ナレッジベースで少数のコントロールを使用してアプリケーションを開発する場合 (グリッド、編集、テキストブロック、エラービューアなど)、画面ごとにそれぞれのスタイルを定義するのではなく、このすべてのコントロールのクラスを処理するオブジェクトが存在すれば、大幅な改善が期待できました。テーマはこのようにして生まれました。ナレッジベース内でアプリケーションのスタイルを定義する場所は、GeneXus の開発者によく知られたスキームに基づき、プロパティが使われました。
その後、テクノロジーの進化により、Web だけでなくモバイル向けの開発も行われるようになりました。モバイルアプリケーションは、Web アプリケーションとは異なる、新しいスタイルの新しいアプリケーションとなります。こうしたタイプのアプリケーションも含めるよう、テーマのコンセプトは拡張されました。
このような経緯でナレッジベースが進化し、現在では、バックオフィスアプリケーションと顧客向けアプリケーションなど、複数のアプリケーションを実装しています。また、こうしたアプリケーションはマルチエクスペリエンス対応、つまりネイティブ Web とモバイルの両方のプラットフォーム向けに開発します。テーマは 1 つでは足りなくなり、Web とモバイルに少なくとも 2 つが必要になります。
さらに、UI が果たす役割の重要性も増します。その結果、より目を引く、カスタマイズされたアプリケーションが求められるようになりました。また、ナレッジベースを拡張し、エンドユーザーに大きな視覚効果やエクスペリエンスを提供するパターンやフレームワークが生まれました。全般的に、こうした拡張は、共有または生成するオブジェクトのデザインを既に提供しています。独自のクラスが定義されるため、Theme オブジェクトにこれらのクラスを追加する必要が生じ、結果的に Theme オブジェクトのサイズが大きくなります。
1 つ目の短所: テーマは組織化できないため、分割や組み立てができません。定義される構造はすべて同じであり、デザイン (テーマ) を提供するものは、ナレッジベースで定義されているほかのテーマに影響します。デザイン定義を含む結果としてのオブジェクト (Web の場合は CSS ファイル) には、各テーマで定義されているすべてのクラスの組み合わせが含まれ、これには使用されないクラスも含まれます。このことは、生成されたアプリケーションで、クライアントに表示する画面が計算されるときのパフォーマンスに直接影響します (リソースが大きいほど、レンダリングの計算時間が長くなります)。
テーマのこの特徴は、ある時点までは利点と考えられていました。実行時にテーマを変更しても、それぞれのテーマに、必要なクラス構造があると分かっていました。しかし、作成するクラス数が急増し、利点と考えられていた点が短所になってしまいました。
こうした経験から、配布しやすいようにテーマをパッケージ化するという方法はやめることになりました。優れた UX を備えたアプリケーションを生成するには、生成された CSS を分割し、そのページのレンダリングに必要な最小限の数のクラスを提供することが、現時点での優先事項です。
2 つ目の短所: コントロールのタイプによって扱われるクラスが異なります。

これは、コントロールに特定のクラスを選択するときには便利です。各コントロールには独自の特性があるため (たとえば、コンボボックスには境界線がありますが、テキストブロックには通常はありません)、定義されている全クラスのリストではなく、コンボボックスに適用されるクラスのグループを用意するのが適切だと思われました (タイプ指定のあるクラス)。しかし、このスキームの難点は、異なるタイプのコントロールにクラスを再利用できないことでした。たとえば、複数の異なるコントロールのフォントタイプの変更は、各タイプのクラスで行う必要があり、単にあらゆるコントロールタイプ内のフォントを含むクラスを参照することはできません。これは最終的に生成されるリソースのサイズに影響します。
3 つ目の短所: クラス間の継承関係を理解するのが困難です。クラスの継承により、生成するリソースのサイズを小さくできます。たとえば、親クラスでフォントを定義し、すべての子クラスでその値を継承した場合、子クラスごとに定義する必要がありません。しかし、階層ツリーと、ノードごとに一連のプロパティがあるこのスキームでは、特定のクラスに定義されているプロパティ値を確認できません。そのほとんどに指定がない固定プロパティの構造を共有した場合、どのプロパティが結果的に特定のクラスを定義しているのか、あるいは値が継承されているのかの判断が難しくなります。
この状況がもたらす問題は、ツリーが大きくなりがちだということです。構造が理解しづらいため、コントロールにスタイルを追加するときに、ほかのコントロールのデザインに影響が及ばないよう、新しいクラスが作成されることになります。

4 つ目の短所: 実行時のクラス変更が、開発者から見て明らかではありません。Web テーマで定義された Attribute クラスから継承するすべてのクラス、たとえば「AttributeX」は、自動的に子クラス「ReadonlyAttributeX」が定義されますが、その理由が明らかではありません。Java または .NET での生成時に、項目属性/変数コントロールが読み取り専用で、AttributeX クラスが割り当てられている場合、そのクラスは実行時に ReadonlyAttributeX に変更されますが、このことが設計時には明らかではありません。加えて、項目属性/変数コントロールが読み取り専用の場合、コントロールの具体的なクラスに関係なく、その特性は同じになります。たとえば、コントロールに定義されているクラスの特性を適用したいが、背景色と境界線の表示のみ一貫して変えたいとします。テーマソリューションの場合、各 Readonly サブクラスでまったく同じ背景色と境界線の特性を繰り返す必要があります。
詳細については、「Theme オブジェクトと Design System オブジェクトの Readonly クラスの比較」を参照してください。
5 つ目の短所: Theme のグローバルレベルで特定の色、フォントタイプ、またはその他の特徴を変更するときのクラスのメンテナンスの問題があります。テーマの比較的最近の進化の 1 つに、Color Palette オブジェクトの定義がありました。これはデザイン定数の抽象化です (デザインシステムにおける「トークン」)。「背景色」など、その内容を表す名前を定義し、クラスで色の名前の代わりにその名前を使用できます。このため、背景色の変更はカラーパレットの変更を意味します。しかし、フォントやフォントサイズは同様に処理できないため、各クラスの定義でこの特徴を変更する必要があります。フォントは、そのサイズ、半径、間隔、境界線などを含め、抽象化できません。カラーパレットの別の制限事項として、実行時に切り替えられないという点が挙げられます。
6 つ目の短所: デザイナーは、使用する言語が異なるため、テーマを理解できません。Web プラットフォームの場合、フロントエンドの開発者でもあるデザイナーが CSS で作業し、GeneXus 開発者がその CSS をテーマに変換します。複雑なシナリオでは、この変換を行わず、テーマ内のカスタムノードを使用して CSS 言語を直接定義する必要があります。それ以外にも、デザイナーがフロントエンドのデザインスキルを持っていない場合、Sketch などのツールで高レベルでのデザインを行い、ここから Web デザインであれば CSS コードを取得しますが、この場合、デザイナーと GeneXus 開発者のコミュニケーションはさらに難しくなります。この 2 言語間の隔たりが、場合によっては大きな障壁となります。

まとめ

●    テーマは理解とメンテナンスが難しい:
                           ○    モバイルと Web の間に重複がある。
                           ○    テーマ内のクラスの一部が、テーマが適用されているオブジェクトのデザインにまったく使われない場合がある。
                           ○    クラスのほとんどのプロパティが使われないにもかかわらず、エディターには表示される。
     ○    場合によっては設計時に定義されたクラスとは別のクラスが実行時に割り当てられることが、開発者にとっては不可解である。
●    サイズが原因で、実行時にオブジェクトのロードパフォーマンスに悪影響がある。
●    デザイナーが提供するファイルや、Web の場合は CSS からの変換が難しい。
●    モジュール化されていない。

Design System オブジェクト

Design System オブジェクトは、テーマの長所が維持されるよう設計されています:
●    コントロールのスタイルを 1 か所で定義できる。
●    デザインを実行時に変更できる。
●    画面のサイズや向きなどに応じてデザインを変更する CSS ルールがサポートされている。
また、テーマのすべての短所を解決します:
●    マルチエクスペリエンスに対応しており、同じ DSO を Web とモバイルの両方のオブジェクトに使用できる。
●    スタイルが理解しやすくなっている。定義がより細分化され、クラス間の継承や、実行時に各コントロールに適用されるクラスが明らかになっている。
●    生成される CSS ファイルはサイズが小さく、次の内容が含まれる:
                              ○    DSO で定義されているクラスの定義。そのデザインで使用されていないクラスのエントリーは生成されない。DSO でのクラスの定義は、そのオブジェクトの生成にのみ影響し、ナレッジベース内のほかの DSO には影響しない。
                              ○    任意のタイプのコントロールでのクラスの再利用。
●    別の DSO や複数の DSO、一部のセクションのみ、Web の場合は CSS をインポートして構成することもできる。これにより、柔軟性が大きく高まる。
●    言語がデザイナーの言語に近い。実際、Web の場合は CSS のクラスを直接コピーすることもできる。
こうした改善点を実現するために、テーマの強みとなる一部の側面を手放す必要がありました。たとえば、DSO ではクラスの相互参照が厳密ではありません。このため、使用している DSO で定義されていないクラスをコントロールで参照することも可能です。
しかし、DSO には特有の利点もあります:
●    フォント、境界線、半径、z-index など、定義できるトークン数が多く (色に限らない)、オプションを使用することで値を実行時に変更できる。たとえば、ダークモード用の配色とライトモード用の配色を変えられる。
●    デザインが完全に収まっているため、DSO のモジュール化を検討できる。
前述のように、目標は、近い将来 DSO にデザイン情報を完全に一元化することです。
この目標を達成するために最初のバージョンで欠如しているのは、ナレッジベースのグローバルレベルでのコントロールタイプの決定です。オブジェクトで既に定義されていた [ Tokens ] と [ Styles ] のパーツに加え、3 つ目のエレメントが設計されました: [ Elements ] です。これにより、各コントロールタイプに既定値を定義できるようになります。たとえば、画面上で項目属性を使用するとき、GeneXus ではそのエンティティを処理するために既定で編集コントロールが使用されます。このエンティティを別のタイプのコントロールで表示するには、画面上のコントロールのプロパティを開き、ユーザーコントロールなどに変更する必要があります。この変更は、各画面上のコントロールレベルで行うもので、アプリケーションのグローバルレベルで行う方法はありません。クラスを使用してコントロールのタイプも変更できれば、どうなるでしょうか。これは DSO のさらなる進化となり、完全なデザインシステムによりアプリケーションにグローバルな影響をもたらすこととなります。

テーマからデザインシステムへの変換

当面の間はテーマとデザインシステムが共存することになります。これは、GeneXus 開発者の皆様に、意図しないデザイン変更の影響をナレッジベースに及ぼすことなく、GeneXus をアップグレードしていただくためです。
今後は、テーマを使用できるあらゆる場所でデザインシステムを参照できるようになります。
また、既存のナレッジベースの移行を支援するために、Theme オブジェクトを Design System オブジェクトに変換できる [ デザインシステムを生成 ] というオプションが用意されています。今後は、ナレッジベースのスタイルをテーマから、変換されたデザインシステムに置き換えても、アプリケーションは同じように機能し続けるようになります。

主な機能の比較

 
テーマと DSO の共存に関連する制限事項: 
●    DSO とテーマを同じ名前にすることはできません。この両方が同じ物理リソースを生成する可能性があるためです (Web プラットフォームの場合、この両方でオブジェクト名を付けた .css が生成されます)。
●    DSO はモジュール化が可能であるため、同じ名前の DSO を複数のモジュールで持つことが可能です。
●    DSO を使用するオブジェクトを生成した場合、実行時にテーマを使用するよう変更できない場合があります。これは、HTML でセレクターが生成される方法が異なるからです。たとえば、DSO では Readonly クラスの処理が変わっています。詳細はこちらを参照してください。

ブラウザーのサポート

DSO を使用したアプリケーションでは、Internet Explorer はサポートされません。最新のブラウザーを最大限活用するため、DSO の使用時には、CSS 変数などの CSS 機能が使われます。
ブラウザーのサポートの詳細については、「GeneXus 18 のハードウェアとソフトウェアの要件」を参照してください。

使用可能バージョン

GeneXus 17 Upgrade 6 以降。