本文へジャンプ

ソフトウェア > Lotus > Lotus Developer Domain > 

Iris Today Archives

ドミノ・アプリケーションを Web 上に移植する


 Lotus Software
by David DeJean
レベル：中級者
対　象：Domino Designer 5.0
原文の掲載：2001年1月2日

Iris Today Archivesの原文

インデックス
相違点を理解する
移植の準備を整えましょう
フォームに関するヒントとテクニック
非表示フィールド
ビューに関するヒントとテクニック
データ取得に関するヒントとテクニック
ユーザー・インターフェースとグラフィックに関するヒントとテクニック
アクセス権限とセキュリティーに関するヒントとテクニック
ヘルプを活用しましょう

ノーツの開発者は、アプリケーションが実行されているクライアント・ソフトウェアよりも、開発ツールとますます深く関わらなければならなくなってきています。Web ブラウザーはノーツ・クライアントと並ぶようになり、もともとノーツ・クライアント用に開発されたアプリケーションをブラウザー用に作り直さなければなりません。

ドミノ・デザイナー R5 では、Web 上で動作する NSF アプリケーションの開発が容易になりました。今となっては、R5 の新しい特徴や機能、そして開発ターゲットとしてのブラウザーの強みと弱点に関する意義深い話もあります。

この記事では、ノーツ・アプリケーションの Web アプリケーションへの変換に関する分析をするための枠組を提供します。そして、アプリケーションの要素の違いを調べ、アプリケーションを Web 上でも問題無く動作させるためのヒントやテクニックを紹介します。

この記事は、ロータス スクリプトや JavaScript の知識だけでなく、ドミノ・デザイナーを使用してアプリケーションのデザインをするための深い知識をお持ちであるユーザーを想定しています。


相違点を理解する
ノーツ・アプリケーションを Web に移植するということは、数行の HTML コードをフォームやビューに加えるだけというような簡単なものではありません。ノーツ・アプリケーションでは、ドミノ サーバーが実行する部分とノーツで実行する部分に分かれていますが、これはブラウザー・ベースのアプリケーションとは大きく異なります。これは、ノーツ・クライアントの能力が Web ブラウザーと大きく異なっており、また、ブラウザーとサーバー間で使用するプロトコルも異なるためです。

R5 ではノーツ・クライアントの機能を忠実にブラウザーに移植するために JavaScript や Java を用います。そのため、Web ユーザーはアクション・バーやリッチ・テキスト、ビュー、その他のノーツの特徴を同じ方法で利用することができます。しかし、ノーツのドキュメント・オブジェクト・モデル (DOM) やリモート・プロシージャー・コール (RPC) プロトコルと同等の機能は Web にはありません。ノーツ・クライアントはサーバーに命令を送り、タスクを実行させ、その結果を、現在オープンしているビューや文書に反映します。このような双方向のやり取りはブラウザーとサーバーの間には存在しません。ブラウザーができることと言えばサーバーに要求を出すことだけで、サーバーができることはブラウザーにページを返すことだけです。

Web ブラウザーとブラウザー・サーバーのアーキテクチャーの限界は問題の根本的要因になります。これらの問題について、アプリケーションの機能をブラウザーで完全に再現できるかどうか、また、再現できるなら、どのようにすべきかという点を考慮しなければなりません。機能以外にも、クライアントとサーバーの両者のパフォーマンスや、セキュリティーやアクセス権、そして使いやすさなど、その他の要素も問題となります。
 
上に戻る
 
移植の準備を整えましょう
アプリケーションを Web 用に作り直す前に、現在の状況と本当に必要なことについて調べる必要があります。次にアプリケーションの分析をするための3つの重要な事柄について述べます。

基本的な仮定を再評価する
アプリケーションの再調査は、望ましい結果をできるだけ明確にし、その実現方法を考えます。以下の新しい場面の中で、誰が、何を、どこでという点を再考しましょう。
  • 誰があなたのアプリケーションの Web 上でのユーザーになるのでしょうか？ノーツ・クライアントを利用していたときの人々と同じでしょうか？まったく新しいユーザーでしょうか？もしくはそれの両方でしょうか？アプリケーションは Web 上だけで実行するのでしょうか？それとも Web とノーツのユーザーの両者を扱うのでしょうか？
  • ブラウザーのユーザーはアプリケーションで何をするのでしょうか？ノーツのバージョンで提供していたすべての機能が必要なのでしょうか？それとも一部でよいのでしょうか？Web に配置することで、アプリケーションの使用状況が変わり、サーバーへの負荷の影響も変わるのでしょうか？
  • Web ユーザーはどこにいるのでしょうか？アプリケーションは社内のイントラネットからしかアクセスできないのでしょうか？それとも、Web 全体からアクセスできるようにするのが目標でしょうか？ユーザーに必要なアクセス権はどういったものでしょうか？また、これらは Web アプリケーションにとってふさわしいでしょうか？
アプリケーションを実行する
これらの質問の答えに留意し、アプリケーションの分析に移りましょう。まず、あなたのノーツ・アプリケーションをブラウザーから実行しましょう。できるだけアプリケーションの機能を完全に見ましょう。できるなら、フォームを使って新しい文書の作成や保存をします。結果を考察し、エラーを記録します。そして、いったん逆戻りし、2つの主要なブラウザーでアプリケーションを比較します。つまり、あなたのユーザーが使用するであろう Internet Explorer と Netscape Navigator の2つのブラウザーでアプリケーションを実行し、両者の違いを記録します。この実地評価で、アプリケーションを改善する変更点を発見し、問題点を見つけることができるでしょう。

1つずつアプリケーションを再調査しましょう
さて、以下の点についてアプリケーションの機能を1つずつ調べていく準備が整いました。
  • その機能は Web 上でも必要かどうか
  • Web 上でも動作するのか
  • Web 上で実現するにはどうするか
これらの点を留意し、次の各カテゴリーについて考えましょう
  • フォーム
    各フォームはブラウザーから正常に見えるでしょうか？グラフィックは正しく表示され、フィールドやフィールド・ラベルは揃っているでしょうか？ブラウザーによって相違点は無いでしょうか？ノーツ・ユーザーや Web ユーザーのために別個のフォームやサブフォームを作成することで問題は解決できたでしょうか？フォームにはロータス スクリプトが含まれていないでしょうか？ブラウザー用に、ロータス スクリプトを JavaScript に置き換えなければなりません。既存のエージェントは Web でも利用できるでしょうか？検索文字列を処理するバックエンドのエージェントを書き直したり、もしくはそれらをスケジュールされたエージェントに変更する必要はあるでしょうか？
  • ビュー
    各ビューは Web 上で正しく動作するでしょうか？すべての列は表示されるでしょうか？文書を選択できますか？そうでなければ、HTML のリンクを作成するためにコードを付け加える必要があるでしょうか？アプリケーションで要求されるすべてのアクションは利用できるでしょうか？
  • データの取得
    データはどこから発生し、アプリケーションでどのように取り扱うのでしょうか？ユーザーが入力するのでしょうか？他のアプリケーションやバックエンドのデータ・ソースから引き出されるのでしょうか？ユーザー名や文書の ID、サーバーやデータベースの名前のような環境データでしょうか？
  • ユーザー・インターフェースとグラフィック
    アプリケーションのユーザー・インターフェースやグラフィックのデザインは Web アプリケーションとしてユーザーの意図と一致するでしょうか？アプリケーションの既存の操作方法はブラウザーで正常に動作するでしょうか？そうでなければ、ノーツ・クライアントの機能の欠落を埋め合わせるために、さらに指示の選択を加える必要があるでしょうか？ノーツでは不必要だった、ホームページやセクション・ページやヘルプ・ページへのアンカー・リンクが Web では必要になるでしょうか？
  • アクセス権とセキュリティーについて
    ユーザーのアクセスとシステムのセキュリティーとのバランスを保つにはどうすればよいでしょうか？あなたのアプリケーションでは、ユーザーがドミノ サーバーで認証をする必要があるでしょうか？ユーザーにはどの程度のアクセス権が必要でしょうか？アプリケーションをノーツ・クライアントとブラウザーの両方で利用する場合、それぞれでセキュリティーが異なるようにする必要があるでしょうか？
これらの質問を注意深く考えると、ノーツ・アプリケーションを Web に対応させるために成すべきことを入念に計画することになります。
上に戻る
 
フォームに関するヒントとテクニック
ブラウザーでフォームのテストをするのは、最初は大変だと思うかもしれません。というのも、なによりもエラー・メッセージばかりが表示されるからです。このような場合、フォームのコピーを保存しておき、ブラウザーにフォームが表示されるまで、フィールドや式や記述されたイベントをそこから取り除きます。そして、先ほど取り除いたものを、再びフォームに1つずつ戻していき、ブラウザーで正常に機能するかどうかをチェックします。うまくいかないものに関しては、書きとめておきます。

フォームには、ブラウザーで動作しない多くの部分があります。たとえば、キーワード・フィールドで、「リストにない値も可」という機能はブラウザーではサポートされていません。 (これには多くの代替策があります。たとえば、「Webfying an existing Notes application（英語）」という Iris Today の記事では、ブラウザーで、複数値フィールドにキーワードを付け加える例を紹介しています。)

ブラウザーで正常に動作しない ＠関数や＠コマンドがアプリケーション中に無いか確認してください。これらの正常に動作しない＠関数は以下のように、大きく3つに分類できます。
  • ノーツ・クライアントのインターフェース内でのみ動作するもの。たとえば、ブラウザーには @DialogBox や @Picklist、@Prompt に対応するものがありません。また、@MailSend や @IsDocBeingMailed といった、いくつかのメール操作の関数もノーツ・クライアント特有のものです。
  • Web の単純な構造のビューでは、@DocChildren や @DocNumber、@IsCategory、@Responses などの多くの機能をサポートできません。
  • ノーツのアクセス権や、プリファレンス、クライアント環境に関係する多くの機能は Web アプリケーションでは動作しません。たとえばこれには、@Certificate や @MailEncryptSavedPreference、@UserPrivileges などが挙げられます。
大抵の＠コマンドは、ノーツ・クライアントのインターフェースの制御と関係があるため、Web アプリケーションでは動作しません。とはいうものの、Web で動作する一握りの機能は頻繁に利用されるため、正常に機能します。たとえば、@Command([FileSave]) や @Command([FileCloseWindow]) などはサブミット・ボタンをエミュレートするために頻繁に用いられます。

＠式や他のプログラミング要素が Web 上で動作するかどうかについては、「R5 デザイナー・ヘルプ」の ｢Web アプリケーションでの使用を回避するため機能の概要｣ のリストを参照して確認してください。

複数のクライアントに対する複数の解決方法
問題を診断し修正すると、恐らくサポートするクライアントの数だけ解決方法が必要になることが分かるでしょう。仮にあなたのアプリケーションをノーツ・クライアントとブラウザーの両者で実行する必要があるとしましょう。この場合、ノーツ用、Internet Explorer 用、Netscape Navigator 用に分けてプログラムを書く必要があるでしょう。複数フォームやサブフォーム、選択式について多くの使用方法や、ユーザーのクライアントを特定し適切なコードを提供する多くの非表示（Hide-when）機能があります。

式では、@ClientType を用いることで、ユーザーが使用しているクライアントが、ノーツかブラウザーかを判別できます。2つの主要なブラウザーの違いを吸収するプログラムを書く必要がある場合、@BrowserInfo を使用すると、ユーザーがどのブラウザーで実行しているか判別できます。

異なる部分の範囲によって解決方法も異なってきます。クライアント特有のさまざまなバージョンのフィールドや式を用いて問題を解決することもできるでしょう。いくつかのフィールドを重複にする必要がある場合、それらをサブフォームに配置したり、同じフォームを2つ作成すれば簡単に実現できることが分かるでしょう。パフォーマンスも決定的な要因となるでしょう。単一の非表示（Hide-when）式を、2つのフォームのうちの1つで表示するための計算は、単一のフォーム中の 30 個の非表示（Hide-when）式を種々のフィールドに表示するための計算よりもずっと効率的でしょう。
 
上に戻る
 
非表示フィールド
ノーツで動作するフィールド式と、ブラウザー上で動作するフィールド式の2種類のフィールド式に関する問題を解決する場合を考えてみます。このような場合、両者ともにフォームに格納し、〔フィールド〕プロパティー・ボックス内の〔段落非表示〕選択肢で、ノーツでの表示/非表示と、ブラウザーでの表示/非表示を選択できます。

Field hide properties

ノーツとブラウザーで同じフォームを用いる場合、オブジェクトのプロパティーにおけるノーツとブラウザーの段落非表示属性は非常に有用です。しかし、非表示のフィールドの各クライアントにおける意味を忘れてはいけません。ノーツでは、非表示のフィールドは (見えないだけで) 文書中に存在しており、計算で用いることもできます。一方、Web ブラウザーでは、ページがサーバーからブラウザーに送られる前に、ドミノによって非表示のフィールドは文書から切り捨てられてしまいます。フィールドの内容は JavaScript からも利用できません。

ヒント：ブラウザーでフィールドを非表示にしたいが、その中身を JavaScript から参照したい場合は、段落非表示属性は使用せずに "type=hidden" という文字列をフィールドの HTML Body 属性のオブジェクトの前に記述してください。また、以下の点を確かめてください。
  • ノーツ・クライアントで非表示（Hide-when）プロパティーが正しく設定されているか
  • データベースのプロパティーで〔ページ生成時に JavaScript を使用〕がセットされているか
  • フォームのプロパティーで〔すべてのフィールドに HTML を生成する〕が選択されているか
ドミノは <type=hidden> タグを HTML ページ内で適切に生成します。

<input type="hidden" name="fieldname" value="fieldcontents">

このような方法で扱うフィールド名やその値は安全ではないことを覚えておいてください。これらは、ブラウザーの ｢ページのソースを表示する｣ 機能を用いることで、どのようなユーザーからも見えてしまいます。

また、すべてのフィールドが必ずしもこのようにしてブラウザーに渡されるわけではありません。たとえば、"$Updatedby" や "$HtmlHead" のようなパスワード・フィールドや、NULL 文字は HTML で表現できないため、NULL 文字を含むオブジェクト (これにはユーザーの公開鍵が該当します) もブラウザーに渡すことができないことを覚えておいてください。

サブフォームの使用
サブフォームを利用すれば、ノーツ・クライアントと Web ブラウザーの両者で動作するフォームを簡単に作成できます。計算結果サブフォームを追加し、適切に表示されるように非表示設定のプロパティーを設定します。以下の式では、@BrowserInfo を利用してブラウザーの種類がわかる CGI 変数を使用することで、NS や IE という名前で、それぞれ特有のコードを含むサブフォームのうちのどちらか1つを呼び出しています。

@If(@BrowserInfo("BrowserType")="Netscape";"NS";"IE")

この関数からアクセスできる変数の一覧をご覧になるには、「R5 デザイナー・ヘルプ」から @BrowserInfo を検索してみてください。

R5 では、各サブフォームには JS Header があり、計算結果サブフォームを用いることで JavaScript や他のデータタイプを含めることができます。

また、すべてのサブフォームはメインフォームに対して一斉にオープンすることを覚えておいてください。ページをオープンした後の計算結果を表示するために計算結果サブフォームを表示することはできません。

Web や ノーツのために重複フォームを利用する
段落非表示のプロパティーはフォーム全体に作用します。ノーツ・クライアント用とブラウザー用に2つのフォームを作成し、それぞれに異なる名前をつけますが、別名は同一にします。そして、段落非表示のプロパティーを設定して、1つはノーツ・クライアントからは不可視になり、もう1つが Web ブラウザーから不可視になるようにします。フォームをオープンする際に別名を用いることで、ドミノはユーザーのクライアントに応じて、正しいフォームをオープンできます。

ロータス スクリプトか JavaScript か？
あなたのアプリケーションで使用しているロータス スクリプトのコードの量や内容によって、アプリケーションをどれだけ簡単にブラウザーに移植できるかが決定します。

アプリケーションでロータス スクリプトを、主にクライアントのデータの処理に利用し、入力・保存データのフィールド内容のチェックや、データ・フォーマットの操作を行っているような場合、ブラウザーでは、JavaScript を用いて、同様のコードを書く必要があるでしょう。ロータス スクリプトがサーバーで実行されるエージェントに主に利用されている場合は、あなたのアプリケーションはノーツ上でもブラウザー上でも正常に動作するでしょう。

ノーツ R5 クライアントでは、多くのフォームやフィールド、ボタン・イベントは JavaScript を用いてもロータス スクリプト(つまり、＠関数式) を用いても記述できます。アプリケーションでのスクリプト・イベントの使用方法によっては、スクリプトを JavaScript に変更することで、ノーツ・クライアントとブラウザーで同じフォームを使用することができることもあります。しかしながら、この2つの利用可能範囲には違いがあります。ノーツ・クライアントで JavaScript を使用すると、現在オープンしているフォームのデータしかアクセスできません。これでは、フロントエンドやバックエンドのロータス スクリプトのドミノ・オブジェクトにアクセスできません。ノーツ・クライアントではロータス スクリプトを使用し、ブラウザーでは JavaScript を使用し、実行ファイルを1つにまとめるために、別々のサブフォームと非表示プロパティーを利用するというのが、最も良いアプリケーションと言えるでしょう。

ページとフォームの違い
静的な情報の表示や、アウトラインやナビゲーター、ビューといった埋め込みコントロールの送信をするフォームや文書、あるいは、ブラウザーのフォルダの代替として、ページを使用すれば負荷を低くできます。ドミノ サーバーは、フォームや文書をオープンしたときと比べて、ページをオープンしたときのほうがずっと少ない量の計算しか行いません。そのため、ページを用いるとパフォーマンスの点でメリットがあります。ページはデータベース・リソースとして保存されるため、アウトラインから参照したり、フレーム・セットに組み入れたり、アプリケーションのスタート・ページとして利用することもできます。ページ内にはフィールドを含めることはできませんが、計算結果のテキストを含めることはできます。

また、ページはフォームに比べて、低いレベルのアクセス権で構いません。〔読者〕のアクセス権を持つユーザーはページを閲覧できますが、フォームを見るには〔作成者〕のアクセス権が必要になります。この違いにより、認証されていないユーザーでもアプリケーションを見たり、潜在的な不正使用を生じることなくアプリケーション内を閲覧できます。というのも、以前はフォームに埋め込まなければならなかったナビゲーション構造 (たとえば、ナビゲーターとビューの組み合わせなど) をページ内に埋め込むことが可能になったからです。

Web ページを表示したいだけというような場合に、フォームをオープンする際のパフォーマンスへの影響を減らす方法として、ページのすべての HTML コードをフィールド名つきの HTML にします。ドミノはフォーム上のフィールドを検索するときに、フォームのチェックや計算を行わずにブラウザーにフォームの内容を送信します。また、非常に大きな HTML をドミノ・データベースに格納するために HTML フィールドを使用できます。フォームは HTML フィールド (テキストまたはリッチ・テキスト) と共に使用してください。そして、HTML コードをコピー・アンド・ペーストして、文書を保存し、リンクやパスの情報の修正をしてください。HTML フィールドは計算もできますし、編集することもできます。あとでユーザーが編集できないようなページを作成したい場合は計算結果フィールドを用いてください。HTML のページが含まれている文書を大量に作成するフォームを使用している場合は、編集可能フィールドを使用してください。

ノーツのダイアログ・ボックスをブラウザーで表現する
エラー・メッセージやヘルプ・ダイアログ・ボックスは、ブラウザーでは利用できないので、それに取って代わるフォームの設計を考慮する必要があります。特に、ユーザーがアプリケーションを利用する際に認証が必要な場合、$$ReturnAuthenticationFailure フォームを作成し、ユーザーに認証の失敗を知らせ、アプリケーションの通常の画面に戻れるようなリンクを与えなければなりません。

フォームを作成し、$$ReturnAuthenticationFailure という名前で保存します。このフォームをパブリック・アクセスに設定するためには次の2つのことをする必要があります。まず、パブリック文書を読めるように、アプリケーションのアクセス制御リストからデフォルトのロールを設定します。

The access control list

次に、パブリック・アクセス・ユーザーが利用できるように、フォームのセキュリティー・プロパティーの〔セキュリティー〕タブの最後の項目を選択します。

Form security properties

ブラウザーで、カスタマイズしたエラー・メッセージを作成するために4つのフォームの名前が予約されています。つまり、$$ReturnAuthenticationFailure と $$ReturnAuthorizationFailure、$$ReturnDocumentDeleted、$$ReturnGeneralError です。これらのフィールドや、使用法の詳細については、「R5 デザイナー・ヘルプ」の ｢カスタマイズしたエラー・メッセージを表示する｣ をご覧ください。

エージェントとアクション
アプリケーションの設計過程の一部に、ブラウザーでの JavaScript の利用法やサーバーでのエージェントの利用法を決定することが挙げられます。サーバー側では、WebQueryOpen や WebQuerySave イベントによってエージェントを実行できます。エージェントは @Command([ToolsRunMacro]) や @URLOpen を利用して Web から実行することもできます。

デフォルトでは Web エージェントはエージェントの作成者 (エージェントを保存したユーザー) の ID で実行されます。Web ユーザーの ID でエージェントを実行するには、〔エージェント〕プロパティー・ボックスの〔設計〕タブをクリックし、Web アクセスのセクションで〔Web ユーザーとしてエージェントを実行〕を選択します。

Agent design properties

Web ユーザーがエージェントをこのプロパティーを設定して実行した場合に、ドミノはユーザーに名前とパスワードを要求し、データベースのアクセス制御リストから権限に違反していないかどうかをチェックするため、このオプションを利用することでセキュリティーを強化できます。

Print ステートメントを使用してエージェントから URL の参照や HTML ページの生成ができます。リダイレクトのフォームは、WebQueryOpen イベントでは動作しませんが、WebQueryClose イベントからは動作します。これを、確認情報のユーザーへの送信やエージェントの実行結果の表示に使用することができます。

ブラウザーのユーザーには、ノーツ・クライアントのメニューに対応するものが無いため、アプリケーションで必要なアクションを提供しなければなりません。R5 のアクション・バー・アプレットでは、一貫性のあるユーザー・インターフェースでこれを実現しています。デザイナーでアクション・バーを生成するには、ページやフォーム、ビューなどのアクション・バーを表示したい場所をオープンします。〔設計〕-〔ページ/フォーム/ビューのプロパティ〕を選択します。そして、プロパティー・ダイアログ・ボックスでアクション・バー・プロパティーを変更し、以下に示すように〔Java アプレットを使用〕を選択します。

Action bar properties

各アクションがアクション・バー上に適切名順番で表示されるようにアクション・プロパティーを設定します。もし必要があれば、アクションにアイコンを設定できます。

Action properties

アプレットを使用することで Web ユーザーにノーツ・クライアントと同様のアクション・アイコンを見せることができます。画面よりもアクション・バーが大きな場合は、アクション・バーをスクロールすることができます。ノーツでは、アクションにはドロップダウン・メニューがあり、ユーザーがメイン・アクションをクリックしたときに、2段目の小さなボタンとして出現します。
 
上に戻る
 
ビューに関するヒントとテクニック
以下の例で示されるように、ブラウザーのビューのデフォルトの表示は、機能的ですがワクワクするようなものではありません。

Default view in a browser

ドミノはビューの主な特徴を忠実に表現しています。ユーザーは分類されたビューを省略したり展開することができます。そして、ビューが長い場合は前のページや次のページに移動するためのナビゲーションが提供されます。また、検索ボックスへのリンクもあります。

このビックリ箱のようなインターフェースは、うまく設計された Web アプリケーションのような見た目の魅力がありませんし、たとえば、ユーザーが複数の文書を選択できるというような、ノーツ・アプリケーションで頻繁に利用される機能をいくらか提供しているだけです。

HTML と JavaScript でビューをカスタマイズする
幸運にも、カスタマイズすることで、ビューをより Web ライクで機能的にすることができます。最も基本的な改良として、ページにビューを埋め込んだり、HTML コードを書き足すといったことが考えられます。以下に先ほどと同じビューがページに埋め込まれている様子をお見せします。

View embedded in a page

ページを使用するとテキストやグラフィック、背景画像を追加できます。一般的なナビゲーションのグラフィックやリンクを取り去り、それらを別のものに置き換えたり、ページをフレーム・セットに組み入れたり、ナビゲーションやナビゲーションを提供するアウトラインと組にすることもできます。

上記のビューは、さらにカスタマイズされています。三角アイコン (省略や展開できるカテゴリーを表すグラフィック) は取り去り、〔列〕プロパティー・ボックスの〔詳細〕タブ中にある〔列の値をリンクとして表示する〕を選択することで、右側の列の内容をハイパー・リンクにしています。

Advanced column properties

三角アイコンの色も変更でき、"imagereplace" という JavaScript 関数を埋め込みビューを送信するフォームに書きこむと、個々の埋め込みビューから完全に三角アイコンを消すことができます。三角アイコンを変更するには、OPEN.gif と CLOSE.gif という2つの GIF 形式のファイルを作成し、イメージ・リソースとしてアプリケーションに保存します。そして、以下の imagereplace 関数の JavaScript のコードを JS Header オブジェクトにコピーします。

function imagereplace()
　　　{
　　　for( i=0; i<document.images.length ; i++ )
　　　{
　　　if( document.images[i].src.indexOf('expand.gif') != -1)
　　　{
　　　document.images[i].src=src =
　　　'/DATABASE.nsf/OPEN.gif?OpenImageResource'
　　　}
　　　//end if

　　　if( document.images[i].src.indexOf( 'collapse.gif' ) != -1)
　　　{
　　　document.images[i].src= src =
　　　'/DATABASE.nsf/CLOSE.gif?OpenImageResource'
　　　} //end if
　　　} // end for
　　　 　}

そして最後に、ページの onLoad イベントに、imagereplace() を入力し、ページがユーザーのブラウザー上でオープンしたときに imagereplace 関数が実行されるようにします。

三角アイコンを削除するのに、単体の小さくて透明な GIF ファイルを作成し、そのファイルと collapse.gif 及び expand.gif ファイルを置き換えるため imagereplace コードを変更します。これは三角アイコンを機能的に残しますが見えないようにします。

ビュー・アプレットの使用
ビュー・アプレットという R5 で新しく登場した機能により、ブラウザーのユーザーは、列のリサイズや展開と省略、複数文書の選択、垂直スクロールといったノーツ・クライアントにあるような多様な機能を利用できるようになりました。ブラウザーのビューで Java アプレットを使用可能にするには、〔ビュー〕プロパティー・ボックスをオープンし、〔詳細〕タブの〔Web アクセス〕の欄にある〔ブラウザーでアプレットを使用〕を選択します。

View advanced properties

また、アプリケーションでは、1つのビューしか表示できないという制限もありません。ビューを複数のフォームやページに埋め込み場合、以下のビューの設定にしたがってオブジェクトのプロパティーを設定し、〔Java アプレットを使用〕とするか、上書きして HTML として表示することもできます。デザイナーで埋め込みビューを〔ビュープロパティを使用〕に設定するには、ビューが埋め込まれているページをオープンし、〔埋め込みビュー〕プロパティーを編集します。

Embedded view properties

ビュー・アプレットは、複数文書の選択をサポートしています。これにより、ユーザーがエージェントで文書の一群を選択する必要がある場合でも、Web アプリケーションに移行することができます。ビューをページに埋め込む場合、サーバー上のエージェントで処理するために、選択した文書の ID のリストを提出するホットスポットやボタンを作成できます。これを実現するには LiveConnect と呼ばれるプログラム技術が必要になります。これは、Internet Explorer や Netscape Navigator、ノーツ・クライアントに組み込まれています。LiveConnect により、Java アプレットのような他の言語で記述されたコンポーネントにJavaScript からアクセスできるようになります。他のドミノの Java アプレットのように、ビュー・アプレットはアプリケーションの JavaScript から指定できる API (Application Programming Interface) を備えています。ビュー・アプレット内で選択した文書の UNID (Universal ID) のリストを作成し、このリストをサーバー上のエージェントに渡すというようなコードの例は、Lotus Technology Learning Center の「Getting a handle to documents selected in a view applet」という記事や、BinaryTree 社提供の「JavaScript lessons」シリーズをご覧ください。

(複数の文書を選択する際の HTML による解決方法もあります。ビューでチェック・ボックスやリスト・ボックスを巧妙に実装する際には「Combining forms and views for friendlier Web applications (Part 2)」をご覧ください)


アクション・バーの作成
アプリケーションでアクションのカスケード・メニューを使用する場合は、一般に Web のビューやページでアクション・バー・アプレットを有効にすると思います。このアプレットは、以下の画面のように、アプリケーションのアクションを HTML ページの上部にあるボタンの列に加えます。アクションにサブ・メニューがある場合、アプレットは最上部の項目がクリックされると小さなボタンの列を表示します。アクション・バー・アプレットをより有効活用するには、上述の ｢フォームに関するヒントとテクニック｣ のセクション ｢エージェントとアクション｣ をご覧ください。

Action buttons in a view
 
上に戻る
 
データ取得に関するヒントとテクニック
Web ブラウザーでは、空欄に書き込んでユーザーからデータを収集するという最も基本的な手段以外のほとんどすべてにおいて、さまざまな制約があります。データ形式は制限されており、リッチ・テキストやファイルのアップ・ロードといった、ノーツの開発者やユーザーが当然のごとく使用している機能についても注意を払う必要があります。

R5 では、ブラウザーからのデータの取得に関して多くの機能が追加され、ノーツ・クライアントにさらに近づきました。フォームにリッチ・テキストのフィールドがある場合、フォームが Web から編集されたことを特定し、リッチ・テキスト・フォーマットの変換をサポートするためにJava エディター・アプレットが起動します。

フィールドで Java エディター・アプレットを有効にするには、以下のように〔Web アクセス〕の〔Java アプレットを使用〕を選択します。

Field web access properties

グラフィックの貼りつけや、ファイルのアップ・ロードのようなノーツ・ユーザーのリッチ・テキスト・フィールドの利用方法はアプレットではサポートされていません。ユーザーがファイルのアップ・ロードをできるようにしたい場合は、ファイル・アップ・ロードのためのコントロールをフォームに組み込まなければなりません。ファイル・アップ・ロード・コントロールをフォームに追加するには、〔作成〕-〔埋め込み構成要素〕-〔ファイルアップロード〕を選択します。コントロールは以下のようにフォーム中に表示されるでしょう。

Field web access properties

中間結果の扱い
ノーツ・クライアント用のアプリケーションと Web ブラウザー用のアプリケーションの最も大きな違いの1つとして、中間結果の取り扱いが挙げられます。Web ブラウザーと Web サーバーのやりとりはかなり制限されています。ブラウザーはサーバーに URL の要求を出し、サーバーは要求された URL の内容をブラウザーに返します。要求された URL は HTML のページかもしれませんし、サーバーでのアクションかもしれません。次に、HTML のフォームがどのように動作するか説明します。クライアントは、変数名や値を含んだ検索文字列や URL をサーバーに送ります。サーバーは検索文字列の内容を処理するスクリプトを確認します。

これとは対照的に、ノーツのフォームはより柔軟で、中間結果を持つことができます。アプリケーションで @DbLookup 式を用いると、ユーザーはリストから値を選択でき、フォームをオープンするときに、その値を別の計算で用いることができます。これは Web ブラウザーでは不可能なことです。Web ブラウザーでも同じような結果を得るためには、ユーザーが値をもつ文書を選択し、この文書の ID をサーバー上のエージェントに渡して、エージェントがその値を調べ、計算を行い、新しい HTML のページをユーザーに送り返すということを行います。

CGI 変数
ノーツでは開発者が簡単に利用できる多くの環境データがあります。もしユーザーの ID を特定したい場合は、@UserName 式を用いるだけで済みます。@Author や @DbName、@ServerName などを用いることで、アプリケーションの現在の環境に関する他の情報にも簡単にアクセスできます。ブラウザー上のアプリケーションでも同じような情報を利用できますが、そのためには、特別な手続きを取らなければなりません。

ユーザー名やブラウザーの種類、ユーザーの IP (Internet Protocol) アドレスといった情報を含むユーザーの環境情報は CGI (Common Gateway Interface) 変数として、ブラウザーからの要求と共にサーバーへ送られます。フィールドに CGI 変数の名前が付けられていると、ドミノにより CGI 環境からフィールド値がコピーされ、そのフィールドに代入されます。CGI 変数を利用するには名前フィールドをフォームに配置しなければなりません。

この情報の基本的な使用方法は、ノーツ・クライアントと Web ブラウザーとの違いを埋めることです。ノーツでは、@DbName は現在のデータベース名を返すだけでなく、サーバー名も返します。Web ブラウザーで @DbName を用いると、データベース名しか得られません。URL の計算をするには、サーバー名やその他の情報が必要になります。そのためには、servar_name という CGI 変数を利用します。server_name という名前のフィールドをフォームに追加するのが手っ取り早い方法と言えるでしょう。

これは、開発用のサーバーでアプリケーションのビルドやテストを行い、それを製品用のサーバーに移す時に特に有用でしょう。CGI 変数を用いることで、アプリケーションを製品に移行する際に、サーバー名やデータベース名を手作業で変更する必要がなくなります。

CGI 変数として利用できるデータは非常に多いです。利用できる CGI 変数を確認する場合は、「R5 デザイナー・ヘルプ」の ｢CGI 変数の一覧｣ をご覧ください。
 
上に戻る
 
ユーザー・インターフェースとグラフィックに関するヒントとテクニック
アプリケーションをノーツ環境から Web に移行できたので、ユーザー・インターフェースの設計に関する2つの点に挑戦しましょう。1つは、ノーツにあるような多くの特徴や機能に相当する部分が Web ブラウザーには欠けているため、実際には使い勝手が悪くならなくても、使い勝手に関しては、あまり高い期待は得られないことです。それに対して、アプリケーションを本気で使用してもらうには、Web ユーザーのグラフィックのデザインや視覚的なインパクトに対する期待を満たす必要があります。特にこれは、アプリケーションやナビゲーションに取り組む必要があります。

R5 では、現在ブラウザーにあるような多くの進んだ機能をサポートしているため、HTML や JavaScript に詳しいほど Web ライクなアプリケーションを作成できます。ダイナミック HTML を用いてレイヤーを使用したインターフェースを持つ Web サイトに関心があれば、たとえば、Iris Today の「新しい Web 技術：ダイナミック HTML をドミノで利用する」には DHTML を用いたドミノ・アプリケーションのレイヤー・インターフェースの作成方法が紹介されているので、それをご覧ください。

しかし、ノーツ・アプリケーションを Web アプリケーションに変更するのに DHTML について知っておく必要はありません。DHTML の基本をマスターし、うまく使えばいいわけです。そして、R5 が備えている視覚に関する機能を有効活用します。

配置の調整に表を使用する
Web ページで、構成要素の配置を調整するには表を用いるのが最も良い方法と言えます。HTML の経験があれば、フィールドやテキスト、グラフィックのような構成要素を適切に並べるのは難しいと感じるでしょう。配置を簡単にするために、このような構成要素をフォーム上の表に配置するという作業がアプリケーションをブラウザーに移植する際に必要になるでしょう。

ページのレイアウトで表を使用する際に、表のセルに、印刷ページ1ページ分よりも大きなリッチ・テキスト・フィールドを配置すると、問題が発生します。Web ページを印刷すると、セルの中身が最初のページで切り捨てられてしまいます。この問題の解決方法として、別々にフォームを作成し、表を使用せずに印刷するために、フォームを切りかえるためのボタンを使用します。

ヒント：ドミノ・デザイナーのバージョンは同じものを使用してください。いったん R5 デザイナーで、表を含むフォームを編集したら、それ以前のバージョンのデザイナーで編集しないでください。そうしないと表は破壊されてしまいます。

ユーザーの入力データをチェックする
ロータス スクリプトを使用して、アプリケーションで高度な入力チェックをしているなら、すでに文書内にあるデータを使用する限りは、ロータス スクリプトの大部分をブラウザーで動作するように JavaScript に移植しなければならないでしょう。たとえば、他の文書やデータベースの参照、文書の UNID の取得といった、外部からのデータをチェックする場合、このような動作をサーバー・エージェントに移さなければならなくなるでしょう。

単純なチェックには＠関数や＠コマンドを用いると容易に実現できるでしょう。次に、ファースト・ネーム、ラスト・ネーム、カテゴリー、項目名、説明の5つのフィールドを持つフォームの例を見てみましょう。以下の画面はデザイナーでオープンしたフォームのトップの部分を示しています。

Form for validation

赤く表示されている CheckEmployee という名前のフィールドは、計算して表示されています。これに、値として名前を与え、CheckEmployee="" のときは非表示になるように設定しなければなりません。各データ入力フィールドには、同じようなチェック・フィールドがあります。

Submit ボタンによって、入力項目がチェックされます。

FIELD CheckEmployee := @If(First = "" | Last = "";"<font face=arial size=4color=ff0000><b>You must enter your first and last name<br>beforesubmitting this document";"");
FIELD CheckCategory := @If(Category = "";"<font face=arial size=4color=ff0000><b>You must choose a category<br>for this item";"");
FIELD CheckItem := @If(First = "" | Last = "";"<font face=arial size=4color=ff0000><b>You must enter a a name<br>for this item";"");
FIELD CheckDescription := @If(First = "" | Last = "";"<font face=arial size=4color=ff0000><b>You must enter a description<br>for this item";"");

NoProblems :=CheckEmployee+CheckCategory+CheckItem+CheckDescription;

@If(NoProblems = "";
@Do(@Command([FileSave]);
@Command([FileCloseWindow]));
@Command([ViewRefreshFields]))

空のデータ・フィールドがあれば、チェック・フィールドにはエラー・メッセージが表示されます。一時変数として、NoProblem がチェック・フィールドをまとめています。空のフィールドが無ければ、NoProblem の長さはゼロになり、 @Do コマンドによりファイルが保存され、ウィンドウが閉じられます。空のフィールドがあれば、@Do コマンドは代わりに @Command([ViewRefreshFields]) が実行されエラー・メッセージが表示されます。

Validation error message

この最小限のチェックでは、入力が無いフィールドの場所にまで着目して画面に表示することはできていませんが、必要最小限の労力でユーザーに結果を与えることができています。

R5 でのグラフィックの改善
R5 ではグラフィックの扱いが大きく改善しました。最も重要な点としては、イメージ・リソースとして JPEG と GIF の最も良く使用されている2つのフォーマットをサポートしていることです。ドミノ R5 アプリケーションにファイルを取り込むと、独自のフォーマットに変換されるのではなく (以前のバージョンでは変換されていました)、そのままの形式で格納されます。もはや、カラー・パレットや、予期しない色の変化に煩わされることは無くなりました。しかしながら、画像を貼りつける場合にはうまく動作しません。グラフィックについての詳細は Iris Today の「ノーツでのグラフィックの取り扱いテクニックについて」をご覧ください。

イメージ・リソースによってはアプリケーションでのグラフィックの管理が大きく改善されました。アプリケーションで画像を保存するときは、イメージ・リソースを使用し、それをフォームやページで使用するようにします。イメージ・リソースでは、複数のアプリケーションのコピーが使用できるようにアプリケーションを複製します。複製である限りは、イメージ・リソースを一回置き換えるだけで、すべてのそれを使用しているすべてのアプリケーションのアイコンやロゴを更新できます。

扱いやすいロール・オーバー・ボタン
イメージ・リソースはアプリケーションをより Web ライクにするのにR5 の簡単な使用方法の例でしょう。ドミノでは、マウスが上を通過したときに状態が変わるロール・オーバー・ボタンへ、用意された画像リソースを自動的に変換できます。グラフィック・エディターを用いて、グラフィック間に1ピクセルの隙間を空けた単一の画像を編集します。

Graphics prepared for rollover buttons

ドミノは、自動的に画像の4つの状態を認識します。
  • 1番左のグラフィックは、通常の状態で使用されます。
  • 2番目はマウスが通過したときの状態です。
  • 3番目は選択されたときの画像です。
  • 4番目はクリックしたときの画像です
この順番は決まっていますが、4の状態ではなく、2、3の状態として使用するときは同じグラフィックを使用することで表現します。上の例では、マウスの通過時と選択時では同じグラフィックを用いておりクリックされたときは別のグラフィックが使用されています。通常時とマウス通過時のみで良い場合は、最後の2つを空にします。

次に、作成した画像をイメージ・リソースとしてアプリケーションに取り込み、プロパティー・ボックスでグラフィックの個数を確認します。

Image resource properties

ドミノは、ノーツ・クライアントと Web ブラウザーで画像を適切に表示するために自動的にこの情報を使用します。(〔イメージダウン〕はブックマーク・アイコンのような複数のサイズが必要になる場合のためのものです。イメージ・リソースについての詳細は「R5 デザイナー・ヘルプ」をご覧ください。)

ヒント：HTML の IMG タグを記述して画像をフォームやページに加える場合、グラフィックの寸法を指定することで、表示のパフォーマンスを向上できます。

"<IMG SRC=myimage.gif width=264 height=128>"

(イメージ・リソースを利用した場合、ドミノは自動的にこれを行います。)また、画像が表示されないときに現れる代替テキストを加えるとアプリケーションはより一層ユーザー・フレンドリーになります。HTML では、以下のように IMG タグを記述します。

"<IMG SRC=myimage.gif ALT="Photograph of new manufacturing facility">"

イメージ・リソースでは、〔図形〕プロパティー・ボックスの〔図形情報〕タブにある〔代替テキスト〕フィールドにテキストを追加します。

ナビゲーション
Web ブラウザーには、ノーツのメニューにあるようなナビゲーション機能が組み込まれていないため、Web アプリケーションでは、ノーツ・アプリケーションを作成する場合よりも入念にナビゲーション機能を組み込む必要があります。

Web アプリケーションに関する問題として、ナビゲーションを可能な限り文書から分離し、ナビゲーションの構造が変わった場合 (このようなことは必然的に起こり得ます) でも、なるべく変更すべき文書が少なくなるようにします。純粋な HTTP サーバーでは、サーバー・サイド・インクルード (SSI) や、ASP ページを使用して、ユーザーに提供される文書と、ナビゲーション・リンクのパネルとを連係させることができます。ドミノ・アプリケーションでは、サブフォームがこれと同様の役割を果たします。つまり、アウトラインをページやフォームに埋め込みます。

アウトラインは R5 で新しく採用された機能で、アプリケーションや Web サイトの多くの領域で、柔軟で高度なナビゲーションを作成できます。アウトライン・エントリーは、コマンドでプログラミングすることができ、アプリケーションの部分ごとで異なる単一のアウトラインが現れるというようなこともできます。アウトラインの外観は、使用例に応じて変更できます。Java アプレットを用いると、ブラウザー上でもノーツ・クライアントのようなアウトラインを実現できます。詳細については、Iris Today の「ドミノ・デザイナー R5：アウトライン」をご覧ください。

フレーム
フレーム・セットは、内容のすぐそばにナビゲーション・ペインを配置するために用いられます。ドミノ・デザイナー R5 は、視覚的なフレーム・セットの設計機能を用いることで簡単にフレーム・セットを作成できます。フレームをドラッグしてサイズを調整でき、フレームのサイズやスクロール、境界線の色と幅、フレームの間隔などを〔フレーム〕プロパティー・ボックスから設定できます。

前もって各フレームの内容を指定したり、フレーム・セットがオープンしたときに内容を計算して出力することもできます。以下の〔フレーム〕プロパティー・ボックスは、フレームに表示するナビゲーターの名前を計算する式の部分が表示されています。式はクライアントの種類や、ユーザー名などの CGI 変数をもとにして、フレームの内容を管理します。そして、ユーザーのロールに応じて、表示式を書くことができます。

Frame properties

また、データベースやフォームやページがオープンしたときに、自動的にフレーム・セットが起動するように設定できます。フレーム・セットの詳細については、Iris Today の「ドミノ・デザイナー R5：フレーム・セット」の記事をご覧ください。

フレーム・セットやナビゲーターは、サイトの一貫したナビゲーションを開発するには手軽な方法ですが、方向を逆にしたり、フレーム・セット内を逆戻りするのが難しいので、フレーム・セットを使用することでユーザーが混乱することがあることを覚えておいてください。フレーム・セットの使用には、くれぐれも注意してください。
 
上に戻る
 
アクセス権限とセキュリティーに関するヒントとテクニック
アプリケーションへのアクセスの設定は、しばしば厄介な問題となります。一方では、匿名アクセスが最も実現が簡単です。ユーザーに認証を強いると、管理上の問題が発生します。というのも、認証するユーザーごとに、サーバーのドミノ・ディレクトリー内にユーザー・レコードを用意しなければなりません。しかし、これにひきかえ、ドミノ・アプリケーションで新しく文書を作成するには、少なくとも〔作成者〕の権限が必要になります。多くのノーツの管理者は、〔作成者〕権限に匿名アクセスを許すという過ちを犯しています。このような解決方法は、アクセスを禁止するために、ノーツのデータベースに匿名アクセスを設定し、デフォルトのロールを〔作成者〕にすることで、ユーザーに認証を強制できます。

アプリケーションが、イントラネット上の企業ユーザーを想定している場合はこれは問題になりません。たいていの企業のノーツ・アプリケーションは恐らく認証されたユーザーの使用を対象としています。しかし、多くの Web アプリケーションは、匿名や、認証されていないアクセスを許容しています。

匿名ユーザーを〔なし〕の権限に制限することは、管理上の負担に加えて、いくつかの問題があります。1つには、すべてのユーザーから見えるパブリック・アクセス・フォームを作成する必要があることです。これについては、$$ReturnAuthenticationFailure フォームの解説で見ることができます。Web ユーザーが認証する必要があり、認証に失敗した場合、メッセージを作成して、それをパブリック・アクセスに設定しなければ、ユーザーはそのメッセージを見ることができません。

アプリケーションが、Web ユーザーに対しては、読み込み専用のアクセスしか許していない場合、〔読者〕のアクセス権に設定された匿名アクセスを用いるとよいでしょう。ユーザーは文書を作成や編集、削除したりできないが、文書の作成や編集、削除を行うエージェントは実行できるということを忘れないでください。

Web からのアクセスに対しては、ユーザーに1レベルのアクセス権に限定し、ノーツ・クライアントからのアクセスに対しては、通常のアクセス権を与えたい場合、以下の画面で表示されているドロップダウン・リストのように〔アクセス制御リスト〕の〔詳細タブ〕にある〔Web ユーザーによるアクセスの上限〕を設定します。

ACI advanced settings

たとえば、ここで〔読者〕のアクセス権限に設定すると、すべての Web ユーザーは、ノーツ・クライアントからアクセスするときには〔作成者〕や〔編集者〕のアクセス権を持っていても、〔読者〕のアクセス権に制限されます。

読者フィールドを利用してセキュリティーを最大化する
アプリケーション内で文書へのアクセスを制限する最良の方法は、文書を作成するフォームに制限をかけることです。これを実現するには、〔フォーム〕プロパティー・ボックスの〔セキュリティー〕タブで設定をするという方法と、フォームに〔読者〕フィールドを配置するという方法の2通りの方法があります。文書を見れる個人やグループやロールの名前を入力すると、それに当てはまらないユーザーが文書をオープンしたり、ビューで文書を一覧表示して見ることは無くなるでしょう。

プロパティーで設定するか、あるいは、フィールドを利用するかの選択は利用者次第です。両者には、それぞれ利点があります。〔読者〕フィールドに入力された値はプロパティーのリストと結びついています。フォームを作成したり編集するには、プロパティーの設定をしたほうが簡単です。というのも、選択ダイアログ・ボックスはドミノ・ディレクトリーを調べるからです。〔読者〕フィールドを使用している場合、文書が作成されたときに値を計算し、任意の〔読者〕フィールドを一度に更新するためにドミノ管理クライアントを利用できます。

他の選択肢として、アプリケーションのビューの表示を制限することです。これは埋め込みビューの場合に動作します。デザイナーで埋め込みビューを持つページやフォームをオープンし、プログラム・ペインの〔オブジェクト〕タブの〔単一カテゴリーの表示〕を選択することで、ビューで表示される内容を単一カテゴリーに制限できます。画面の詳細を以下に示します。

Object pane

プログラム・ペインのスクリプト・エリアで、カテゴリー名を入力し、カテゴリー名を評価する選択式を書きこみます。このテクニックを使用して、文書の作成者や、特定のグループのメンバーだけに文書を表示することができます。たとえば、以下の式は、Admin と Sales、HR、IS の4つのうちのどれかのグループのメンバーに当てはまるカテゴリーを表示する例です。

@If(@Contains(@UserRoles;"Admin");"Admin";
@If(@Contains(@UserRoles;"Sales");"Sales";
@If(@Contains(@UserRoles;"HR");"HR";
@If(@Contains(@UserRoles;"IS");"IS";
""))))

ワンポイント：アスタリスク (*) を評価すると、すべてのカテゴリーが表示されます。これは、あるユーザーには完全なビューを表示でき、他のユーザーへの表示は制限できることになります。また、@ClientType を用いてブラウザーでは単一カテゴリーのみを表示し、ノーツ・クライアントでは完全な内容を表示するようなビューを作成できます。

@If(@ClientType = "Web";"Newsflash";"*")
 
上に戻る
 
ヘルプを活用しましょう
ノーツ・アプリケーションを Web アプリケーションに変換するときに直面する問題の中に、ノーツでの動作をブラウザー上で実現する方法を探すということも含まれます。もしあなたがノーツの開発者で、Web のアプリケーションの開発に取り組み始めたばかりということであれば、解決方法を探し出す対象は身近にあります。
  • 「R5 デザイナー・ヘルプ」は素晴らしい情報源で、情報だけでなく用例も豊富です。
  • Iris Sandbox（英語） も忘れずに調べてください。これは、Notes.net 上にあり、ダウンロードできるアプリケーションや、サンプル・プログラムの宝庫です。
  • Lotus Technology Learning Center（英語） も、チュートリアルやプログラムの素晴らしい情報源です。Learning Center では、実践的で、自分のペースで学習を進めてけるチュートリアルを提供しています。たとえば、Killer Web App2 や、BinaryTree には、CSS や DHTML、HTML、JavaScript、XML などに関する情報があります。
  • Notes.net にある Notes/Domino Gold Release Forum（英語） を忘れないでください。この記事で紹介しているヒントやテクニックの多くは、最初はここで紹介されたものです。
  • そして、Iris Today には、多くの関連記事が掲載されています。これらの記事をチェックし、関心のある話題を探すには、全文検索を活用してください。以前のバージョンから R5 に移行する場合は、「Domino Designer R5 Technical Overview（英語）」や「Domino R5 Technical Overview（英語）」や、これらからリンクされている記事を参照してください。
  • R5 の最優良事例については、「ロータス ノーツ/ドミノ R5 ベスト・プラクティス・ガイド」を参照してください。
これらの情報源やこの記事を活用すれば、ノーツ・アプリケーションの Web への移行を成功させることができるでしょう。
 
上に戻る