 |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Workplace Designer の設計: IBM Workplace Designer 設計チームへのインタビュー |
|||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||
Dick McCarrick, Content Developer, IBM レベル：中級 原文の掲載：2005年6月14日 更新日：2005年10月21日更新  原文はこちら IBM Workplace Designer について知りたいとき、それを作成した人に聞くよりもよい方法があるでしょうか。このインタービューでは、IBM Workplace Designer チームの 3 人のメンバーと対談し、主な機能や今後の予定などについて聞きました。 IBM Workplace Designer は Eclipse ベースの開発ツールで、IBM Workplace Collaboration Service および IBM Workplace 製品群の他の製品に向けたアプリケーションの開発を可能にします。IBM Workplace Designer の詳細については、IBM Workplace アプリケーション開発ページを参照してください。このページには、最新の記事へのリンク、ビデオ、パンフレット、使い始めるときに役立つ他の情報が掲載されています。また、製品に含まれている IBM Workplace Designer オンラインヘルプも参考にしてください。広報によると、IBM Workplace Designer は近日中にリリースされる予定です。 このインタービューでは、IBM Workplace Designer の設計および構築を担当したチームの 3 人のメンバーに話を聞きました。
IBM Workplace Designer チームでのそれぞれの役割を説明してください。 Maureen Leland：私は Workplace Designer のチーム・リーダーです。フォームとコントロール、ビューなどの UI 全体を担当しています。私たちのチームは、この領域で多くのことをしています。私は Domino Designer のプロジェクト・リーダーを約 5 年間続けていたので、Domino Designer のビジョンをこの製品に持ち込んだのは私だと考えています。 David Taeib：私はチーム・リーダーで、Workplace Designer のスクリプティングの部分と、基礎となる Eclipse へのインフラストラクチャ接続、それに Workplace Managed Client を担当しています。IBM には 9 年半勤務しています。開発者としての仕事は、Domino Global Workbench と呼ばれるプロジェクトがほとんどです。Eclipse に大きな可能性があることに気づき、ここ数年で開発の方向を Eclipse へと変更しました。Workplace Designer が Eclipse をベースにすることを知り、私はたいへん興奮しました。これは完全な組み合わせですからね。つまり、Workplace Designer と Domino Designer に似た製品の概念、それと Eclipse 上に構築された UI は完全な組み合わせではないか、と思ったのです。 Philippe Riand：私は Workplace Designer のアーキテクトです。主な役割は、仕様を起案し、実装がこれらの仕様に適合するか確認することです。私は初期の頃から Java プラットフォームに携わってきました。JDK1.0 を使用していた初期の開発者の一人です。また、たくさんの Notes アプリケーションも開発してきました。Workplace Designer にはとても興奮しています。Domino と同じ概念を J2EE テーブルに取り入れているからです。
簡潔に言うと、Workplace Designer とは何で、それを用いると何ができるのでしょうか。 Maureen：フォームを構成する Workplace コンポーネントを作成できます。開発者が慣れている構造で Workplace コンポーネントを構築することを可能にします。J2EE 関連のものは構築しません。サーバー、ビーンズ、JSP ページ、これに類する要素は扱いません。実際には、「フォーム、ボタン、編集ボックスがある。これらにスクリプトを作成できる」と考えればよいのです。これは、フォームに基づくスクリプティング・ツールで、開発者が Domino Designer で慣れている手法に似ています。このため、既存のスキルが役に立つ方法で Workplace コンポーネントを作成できます。 しかし、Domino そのものではありません。もし、Domino を知らなくてもかまいません。Visual Basic ユーザーでも、この環境を快適に感じるでしょう。 Philippe：私はこの考えをさらに進め、慣れ親しんでいる概念を持ち込むことにより、Domino コミュニティで仕事をする、と言いたいです。しかし、Java 開発者にも魅力を感じて欲しいと思います。現在、唯一のオプションは J2EE ベースで複雑ですから。そして、デプロイメントなどの特定の作業は J2EE では簡単ではありません。このため、Java 開発者には、下位レベルのコードではなく、ビジネス・アプリケーションやビジネスコードに集中できる環境に一段ステップアップしてもらいたいのです。つまり、Workplace Designer は、いま現在できないことの一部を可能にします。 David：Phil が話したことに付け足しましょう。私は、キーワードは「生産性」だと思います。J2EE のパワーを維持すると同時にその複雑さを削減し、開発スピードを上げることによって生産性を高めるにはどのようにすればよいでしょうか。Domino の開発者はその方法を知っています。彼らは、ほとんど変更せずにアプリケーションの作成およびテストができる環境でアプリケーションを開発しています。テスト後に、新しいフィールドを作成したり、外観を変更したりして、再びテストを行います。私たちは Workplace Designer に対し、デプロイメントとテストを自動化するこのような機能を Eclipse プラットフォームに取り入れることを考えました。これは、作業を簡単にするための拡張であり、手動で行っていた数多くの作業を自動化することで、生産性を高めています。これは、J2EE の世界において大きな成功である、と私は思います。デプロイメント記述子の書き込みやテストといった日常の作業は、非常に面倒で退屈だからです。
Workplace Designer はどの点で Domino Designer と似ていますか。また、2 つの製品の違いはどこにありますか。 Maureen：Workplace Designer を見るとわかるように、環境が似ています。同じではなく、明らかにアップデートされています。それに適した新しい外観になっていますが、左側には設計コンポーネントが表示されています。これらは、Domino Designer で設計するデータベースやテンプレートに相当します。これらを展開すると、Domino Designer のブックマークの構造と非常によく似ています。さらに、フォーム、設計要素のリスト、スクリプトライブラリがあります。 Maureen Leland
1 つの違いとして、Workplace Designer がスキーマを持つのに対し、Domino は共有フィールドを持ちます。データの扱い方が大きく異なります。Domino の長所の 1 つとして、データの取り扱いの容易さが挙げられます。Domino ユーザーはこの点で恩恵を受けていると思います。しかし、データの取り扱いの容易さは、Domino の短所の 1 つでもあるのです。Domino 内ではデータを容易に扱えますが、データがいったん Domino に入ると、アプリケーションからは管理することが非常に困難になります。たとえば、共有フィールドを使用できますが、この共有フィールドは、実際には 1 つの大きな階層なしのスキーマです。Workplace Designer では、データを表す方法としてスキーマが使用されます。私たちは長い間、Workplace Designer を Domino のように使いやすくすることを望んでいますが、データの構造を制御する機能も必要です。もし、データが階層的であれば、階層的なスキーマを作成し、それに適した方法で扱うことができます。Workplace Designer はパワフルかつコントローラブルであると同時に、Domino と同じように使いやすくなっています。 類似している他の領域として、プログラムペインがあります。これはたいへん見慣れていますが、David のおかげで Eclipse のスクリプト編集を活用することができました。David のお株を奪うわけではありませんが、これは本当にクールな仕上がりです (笑)。プログラムペインには、ユーザーが常に求めているものが含まれるでしょう。 Philippe：Domino は文書ベースです。Workplace Designer では XML を使用します。XML はよく知られた文書形式で、異なるポート間でのデータ送信に使用されます。これは非常に重要です。なぜなら、現在 Domino 開発者は J2EE またはこのプラットフォームへ移行していて、慣れないオブジェクト・プログラミング・モデルに直面しているからです。クラスを使用し、EJB を扱うことが必要になります。また、スクリプトも扱わなくてはなりません。Workplace Designer では、ユーザーはコードの実行をともなう Java クラスを作成する必要はありません (もちろん、希望する場合は作成できます)。また、関連するいくつかの @関数を提供する JavaScript インタープリターも用意されています。 David：最も伝えたいのは、私たちは Domino の優れた機能を継承するとともに、特定の領域、特に標準の使用について強化している点です。私たちは、最初から業界標準を目指して Workplace Designer を開発しています。XML と XPath を使用し、CSS に力を入れています。また、これらの標準化コンポーネントを取り入れることにより、他のツールとの対話を簡単にしようと真剣に試みています。業界標準、品質標準、そして W3C が提案する標準など、これらの標準への取り組みが現在のテーマです。成功を目指すなら、オープンで、かつ相互利用が可能でなければなりません。 Philippe：同僚から受け取った文書を Workplace Designer で処理して、送り返したいこともあるでしょう。この場合、共通のフォーマットが必要です。このことは、標準が非常に重要であることを示しています。 David：これはたいへん重要で、大きな違いに発展すると私は確信しています。私たちは、他の大きなプラットフォームとの互換性を保ちたいと思っています。すべての種類の標準に対し、最終的にドアを常にオープンにしておくことが必要です。 2 番目として、Domino の優れた機能を Workplace Designer に取り入れています。たとえば、シンプルアクションの概念です。最初のリリースでは大きく制限されますが、これらの機能を Workplace Designer に実装したいと考えています。シンプルアクションは仕事をすばやく処理するために役立つので、シンプルアクションの概念は継続するつもりです。さらに、コードの作成を簡単にして、コードをシンプルアクションとしてまとめ、プラグインとして自由に配布できるようにしたいですね。これは、Eclipse によって可能になります。これによって、Workplace Designer を自由に拡張できるようになります。これは、たいへん重要なポイントでしょう。
多くの読者は Domino のバックグラウンドを持っています。再コーディングせずに、これまでに作成したものをどれぐらい Workplace Designer 環境で活用できますか。 Philippe：資産の活用を考えるとき、2 つの点に注目することが必要です。1 つは、このプラットフォームに関するスキルや知識の活用で、もう 1 つは、これらのスキルを用いてすでに作成したものを活用することです。私たちが最初に取り組んだのが、ユーザーのスキルをできる限り活用することです。すでに説明したように、Domino Designer の多くの概念が Workplace Designer に取り入れられています。これらの機能によって、すぐにでも既存のスキルを最大限に活用できます。 Philippe Riand
資産の活用の 2 番目として、必要に応じて、あるいは何らかの理由で、Notes/Domino からこのプラットフォームにアプリケーションを移行するケースについて考えます。私たちはインポート・ツールを提供しますが、このツールは、アプリケーションの移行用には設計されていません。特に、「そういえば、Notes にアプリケーションがある。同じものが Designer にも欲しい。ボタンを押して作成しよう」という形では使用できません。これはインポートツールが目指すところではありません。インポートツールの目的は、新しい Workplace アプリケーションの立ち上げを加速することで、アプリケーションを 1 対 1 に移行することではありません。経験的に明らかなように、Notes から他の環境に移行するとき、1 対 1 の移行では、新しいプラットフォームでの機能を活用することは困難です。このため、Designer アプリケーションでは、既存の Notes フォームを使用して始められるようになっています。 David：Phil が説明したインポート機能は、アプリケーションの設計に関してだけであり、データは含まれていません。これは総合的な問題です。もちろん、非常に単純なケースを除き、設計の 100% を移行できるわけではありません。目標は、よいスタートを切ることにより、Workplace の世界でのアプリケーション開発をすばやく始められることです。これが、このリリースで Domino からのインポートを提供する目的です。将来のリリースでは、ユーザーからのフィードバックに基づき、この機能を強化することを考えています。 Maureen：Domino のデータを Workplace にインポートすることも考えられますが、データを Domino と共有するという方法はどうでしょうか。Workplace Designer のコンポーネントでこのデータを扱い、同じデータを Notes アプリケーションでも扱うのです。つまり、将来のもう 1 つの目標として、Notes データを扱えるようにすることです。これはたいへん重要なゴールで、相互運用性にも貢献するでしょう。なぜなら、データが満載されたデータベースを処理するスタンドアロンの Notes クライアントもあるでしょうし、Workplace クライアントまたは他のクライアントにもそのようなデータがあるでしょうから。 David：今度の Notes/Domino 7 の新機能では、Notes から DB2 データへアクセスできます。これは、Notes と Workplace 間の転換点になるでしょう。同じバックエンドシステムで作業しながら、2 つのプラットフォームを扱うことになるからです。
Workplace Designer で、Domino プログラマーが驚いたり、慣れていないものは他にもありますか? Maureen：まず、彼らはビューの設計要素を探そうとしますが、それは存在しません。ビューは、Workplace Designer の設計要素ではありません。Workplace Designer には、クエリーを視覚化したものを内包するいくつかのコントロールがあります。これこそが、ビューの本質です。Domino では、選択式とその式を視覚化したものの組み合わせがビューとなります。Workplace Designer では、内部的にこれらを分離するよう設計しました。最初のリリースでは、十分な時間がなかったので、まだ分離していないように見えます。しかし、最終的には、選択式を表すクエリー設計要素を作成し、さまざまな視覚表現をこの要素に適用できるようにします。その 1 つがグリッド表示のビュー・コントロールです。このため、通常のビュー設計要素を求めているのであれば、フォームを詳しく調べる必要があります。実質的に、すべてのビューは埋め込みビューになっています。しかし、私たちは選択式を得る目的で設計し、将来の視覚化を考慮に入れています。これが、Workplace Designer と Domino の大きな違いの 1 つです。 Philippe：スキーマでは XML を使用しますが、Domino 設計者は XML にあまり慣れていません。Domino の方法では、フィールド、それも複数のフィールドを作成するため、最初は XML を使用することに戸惑うでしょう。そして、ここが方法を変更するポイントと言えます。複数の文書を扱い、しかも移行は自動では行われません。これらの機能を活用するには、考え方を少し変更する必要があるからです。また、Domino 開発者は計算結果フィールドに慣れています。何かを計算したいときは、文書内に計算結果フィールドを配置するだけで済んでしまいます。Workplace Designer を使用した作業方法は、これとは少し異なります。 David：Domino Designer で行われれないことの 1 つが、スクリプトにエラーが含まれる状態でフォームを保存することです。私たちはそれを許可しています (笑)。この方法の方が普通だと思います。Workplace Designer では、すべてのものを、たとえエラーが含まれていても、保存することができます。エラーは専用のタブにまとめられるので、ユーザーは、すべてのフォームに含まれるすべてのスクリプトエラーを見ることができます。ダブルクリックするとフォームが自動的に開かれ、スクリプト内のエラー箇所まで直接ジャンプします。これによって、スクリプトに含まれるすべてのエラーを非常に簡単に管理できます。これは、Eclipse から作成した機能です。もう 1 つの違いはイメージです。イメージはテキストと共にインラインで埋め込むことができません。文書内に単にイメージだけを追加することもできません。最初に、イメージをコンポーネントに格納することが必要で、このコンポーネントは共有できます。Domino が持っているイメージ設計要素は、Workplace Designer にもあります。 Maureen：「では、新しく始めましょう。どのようにしたいですか」と言える点は長所です。今では、アプリケーション内のすべてのイメージはイメージ・リソースとなっているので、これらを制御できます。 David：もう 1 つの違いは、Workplace Designer パレットです。Domino にはありませんでした。ドラッグアンドドロップが可能です。私たちは、コントロールのドラッグアンドドロップを多用します。Domino Designer では、カーソルをフォーム内に置いて、フィールドを作成していました。Workplace Designer ではフィールドの概念を複数のコントロールに分割し、1 つのパレットに収めました。つまり、コントロールのリストが得られたのです。編集ボックスやボタンなどは、すべて個別のコントロールになっています。フィールドを追加し、その後で種類を決めていた Domino とは、異なる方法です。 David Taieb
私たちは、ドラッグアンドドロップが可能な非常にリッチな環境を提供します。使用できるすべてのコンポーネントが状況に応じてパレットに表示されるので、これらをドラッグし、フォーム内の任意の場所にドロップすることができます。 Philippe：また、Domino と Workplace Designer では、設計方法が大きく異なります。Domino では、フォームを設計するときに、文書の実装を想定して UI とデータの主な容量を設計します。Workplace Designer では、これらの概念は分離されています。しかし、ユーザーが Domino を使用する方法は非常に一般的で、優れていると思います。このため、Domino での経験とまったく同じ経験をすることができますが、概念は大きく異なっていて、すべてが自動化されています。「Domino での方法」を用いてフォームを開発できますが、これとは別の方法でスキーマを開発したり、サードパーティのプロバイダからスキーマを入手してスキーマ上に UI を配置できます。どちらの方法も可能です。
Workplace Designer では、どのスクリプト言語がサポートされますか? David：現時点では、ビジネスロジックを書くことができるメインのスクリプティング言語は JavaScript です。このため、ランタイムには JavaScript インタープリターを用意しました。私たちはこのエンジンを Domino に似た @関数のセットで強化しました。このため、ユーザーは Domino Designer で使用するときと同様に @関数を使用できます。環境自身には Content Assist が使用されているので、任意の時点でブレークしてヘルパーを呼び出し、入力中のキーワードを補完することができます。たとえば、@記号を入力して Ctrl + Space キーを押すと、利用可能なすべての @関数のリストが自動的にポップアップウィンドウに表示されます。繰り返しになりますが、これによって生産性が高まります。 UI の左側には、状況に応じて変わる参照タブがあり、すべてのオブジェクト、つまりいつでも使用できるすべてのグローバルオブジェクトが表示されます。このため、状況に応じた適切な処理ができます。このような簡単な方法で JavaScript スクリプトを使用できる優れた環境がユーザーに用意されています。 また、Domino から取り入れたスクリプトライブラリの概念もサポートしています。スクリプトライブラリを利用すると、JavaScript 関数などの一連のコードを設計要素に格納し、これらをインポートすることで、フォーム内の任意の場所からそのコードを呼び出せます。最初に、「import」を使用します。利用できるすべてのスクリプトラブラリが表示されます。展開すると、利用できるすべての関数とグローバルオブジェクトが左側の参照タブに表示されます。スクリプトライブラリに何が登録されているかを確認する必要はありません。その場でわかるからです。Control キーを押しながらマウスを import ステートメントの上に置き、クリックするとスクリプトライブラリがすぐに開かれ、内容を確認できます。 Philippe：私たちは、Java API に関する JavaScript ラッパーのセットも提供します。これによって、これらの API へのアクセスが少し簡単になります。また、1 つの関数を呼び出すだけでこのライブラリへアクセスできるライブラリのセットも用意しました。XML 文書の移動、または XML 文書の複製は XPath のスタートへとつながります。このため、XPath は Workplace Designer と完全に統合され、JavaScript と Xpath を混合したり、組み合わせることができます。たとえば、JavaScript コード内で文書だけを検索するように、XPath を実行できます。 David：私たちは総合的な XPath エディターを用意しました。ヘルプやそれに関連する機能も充実していて、知識のないユーザーでも XPath を書きやすくなっています。
Workplace Designer のデプロイメント機能はどのようになりますか? Maureen：デプロイメントはたいへん簡単です。私たちは、テストとデプロイの繰り返し、およびアプリケーション開発の繰り返しに適応するよう設計しました。このため、簡単に言うと、最初にデプロイメント・プロファイルに書き込むだけで OK です。ユーザーの設計は設計用マシンのローカル・ファイル・システムにあるので、サーバーがどこにあっても、これらのファイルからサーバーに到達できることが必要です。これは、同じマシン上にあるか (プレリリースでは、同じマシンを想定)、部署の共有サーバーやテスト・サーバー上に存在する可能性もあります。このため、デプロイメント・プロファイルで、サーバー名、そのサーバーで使用するユーザー名とパスワード、使用するデータベース (Cloudscape、DB2 など) をセットアップする必要があります。一度このセットアップを行えば、コンポーネントを右クリックし、「デプロイ」を選択するだけで、デプロイが瞬時に実行されます。たとえば、編集フィールドの色を黄色に変更し、これがどのように見えるか確認するには、もう一度デプロイすればよいのです。ブラウザーを使用すると、その結果を表示できます。つまり、非常にすばやいデプロイが可能です。 これは、設計フェーズでのテストの説明です。出荷の準備が整った場合は、アプリケーションを WAR ファイルにエクスポートし、システム管理者に依頼して実際の実働サーバーに配置してもらいます。 David：これらのすべての機能は、製品に組み込まれています。専用のメニューが用意されているので、それに従って操作するだけです。たいへんシームレスです。 Philippe：一般に、J2EE デプロイメントはユーザーにとって苦痛と言われています。このため、Maureen が説明したように、私たちは 2 つの手法を用意しました。それは、サーバーへの WAR デプロイメントとデータベース作成です。ユーザーのためにすべてが完全に自動化されています。これは J2EE 開発者にとって夢のようなことです。また、生成物やサーバーへの実行内容をさらに制御したいシステム管理者は、サーバー標準 J2EE デプロイメント・モードを介して、データベースと Web アプリケーションを指定することによってビルドを実行できます。しかし、これは必須ではありません。もっと簡単な方法が用意されています。 David：コンポーネントを最初にデプロイするときは数分かかることがありますが、その後は一瞬です。本当に数秒しかかりません。生産性の高い部門を持ちたいユーザーにとって、これは非常に重要なことです。
Workplace Designer と Workplace Builder はどのような関係になりますか? Maureen：Workplace Designer は Workplace コンポーネントを構築します。Workplace Builder は、これらのコンポーネントをページ上に配置し、アレンジします。つまり、協調関係にあります。 David：Workplace Builder は Workplace コンポーネントのコンテンツまではあまり関与しないので、Workplace Builder の方が Workplace Designer よりも上位のツールです。Workplace Builder では、「points of variability」(変動ポイント) と呼ばれるものをパラメーター化することができます。Workplace Builder に習熟している人はこれについて知っていますが、Workplace Designer では、Workplace Builder がコンポーネントのインスタンスのパラメーター化に使用するこの変動を生成できます。 まだ話してないことの 1 つに、コンポーネント・スクリプトがあります。コンポーネント・スクリプトを使用すると、Workplace コンポーネントのイベント・ライフサイクルにビジネス・ロジックを追加できます。Workplace Builder はコンポーネントのライフサイクルを定義します。コンポーネントのインスタンスを作成すると、インスタンスの生成、インスタンスの削除、メンバーの追加など、多くのイベントが起動されます。私たちは、Workplace Builder によって消費されるこれらのイベントにプログラム的なロジックを追加するために、Workplace Designer でスクリプトを設定できるようにしました。これは、Domino におけるデータベース・スクリプトと同じものです。Maureen、間違っていたら訂正してください。 Maureen：そのとおり、正しいです。 David：データベースを開いたときや、閉じたときに起動されるスクリプトはほとんどありません。これらは、Domino Designer と同様です。 Workplace Designer の将来のリリースではどのような拡張ができると考えていますか。 Philippe：ランタイムを移行するつもりです。現在、ランタイムは Workplace Designer のユーザーには隠されていますが、前にも述べたように、私たちはプラットフォームをできるだけオープンにし、Rational と一部の要素を共有したいと考えています。このため、Workplace Designer の次のランタイムは JSF をベースにする予定です。フレームワークを JSF 上に構築することによって、スクリプト・エンジンに Java を導入し、サーバースクリプティングを行います。これによって、JavaScript をサポートするのは当然として、15 以上の言語に門戸を開くことになります。サードパーティも独自のスクリプト言語を提供できます。 David：私たちは、ワークフローの追加を考えています。もう 1 つは、円グラフなどのグラフです。これらは、コンポーネントの新しい設計要素として組み込まれます。ビジネスパートナーが独自の設計要素タイプを作成できるとしたら、それはたいへん興味深いことです。それに、非常にパワフルです。 Philippe：新しい JSF ランタイムは総合的なコンポーネント・モデルも提供します。ユーザーは独自のコンポーネントを迅速にフォームに取り入れられ、Java 以外の開発者もコンポーネントの開発に参加できます。このため、ユーザーは役割を分担し、機能の追加やコンポーネントの作成を分業できます。 Maureen：すべてをリソースにする、という私たちの考えが、コンポーネント化と共有に本当に役立っています。これが、私たちの設計にとって重要なことでした。 David：デバッギングです。Domino Designer の最初のリリースには、デバッガ・ファイルがあります。JavaScript インタープリターは製品の公式な一部ではなく、テクニカル・プレビューとして含まれています。次のリリースでは、すべての機能が実装される予定です。デバッギングは非常に重要です。私たちは、デバッグ関連の機能をできるだけ充実させたいと考えています。 Philippe：今のところ日付については明らかにできませんが、ポータル開発のサポートを計画しています。Workplace Designer にプラグインを提供する Rational Application Developer 7.0 が発売されることになっていて、これとの同期を予定しています。これは、インタビューの最初にお話しした内容に関連します。私たちは、生産性を高めるハイレベルの概念を提案することにより、Java コミュニティに貢献したいと思っています。Java コミュニティのユーザーは、生産性を高めるために Workplace Designer を使用できるでしょう。もちろん、開発者はこのために Rational を使用する必要はありません。あくまでも、1 つの選択肢です。 David：もう一度言いますが、Workplace Designer は Eclipse のプラグインのセットを使用して、このユビキタスな方法を実現しようとしています。これは、Rational Application Developer 7.0 でも使用され、自動的にすべての機能が使用されるでしょう。
このほかに、Workplace Designer について、読者の方に何か言いたいことはありますか? Maureen：世界で一番クールな製品です!
リソース
|
|||||||||||||||||||||||||||||||||||||||||||||||||
