いったいCaretNoteIDってどんなときに使うのか？
369 Views
September 12, 18
スライド概要
LotusScriptのCaretNoteIDプロパティの使い方。
NotesUIView クラスのプロパティの1つ。
ビューで現在ハイライトされている (カレットの場所にある) 文書の note ID です。
このプロパティは R6 で新しく追加されました。
選択マークはカレットの場所には関係ありません。
CaretNoteID が参照する文書を取得するには、NotesDatabase の GetDocumentByID を使用してください。
便利なところはずばり UIViewからバックエンドのDBクラスの文書を1行でつかめる。
【公式】 OnTime Group Calendar for Microsoft ページ https://ontimesuite.jp/forms/ 【公式】 OnTime Group Calendar for HCL Domino ページ https://ontimesuite.jp/fordomino/ 高速グループスケジュールの OnTime Group Calendar for Microsoft / for Domino の日本総代理店をしています。 CEO at AXCEL corporation that the agency of OnTime Group Calendar in Japan.
関連スライド
各ページのテキスト
notes knows 2018.08.22 No.6
スポンサー
先日の”CaretNoteID”の件、 覚えてます？
「いったいCaretNoteIDってどん なときに使うのか？」 って話になりましたが、すぐにそ の事例となるDBが出てこず宿題 になっていました。 本日はその事例のお話しです。
そもそも”CaretNoteID”とは？ • NotesUIView クラスのプロパティの1つ。 • ビューで現在ハイライトされている (カレットの場所にある) 文 書の note ID です。 • このプロパティは R6 で新しく追加されました。 • 選択マークはカレットの場所には関係ありません。 • CaretNoteID が参照する文書を取得するには、NotesDatabase の GetDocumentByID を使用してください。 • 便利なところはずばり UIViewからバックエンドのDBクラスの文書を1行でつかめる。
選択マークとハイライト 選択マーク ハイライト
選択マークとハイライト • ハイライトはUIViewから１つの文書を識別できる。 • Set doc = db.GetDocumentByID(uiview.CaretNoteID) • 選択マークはUIViewから複数の文書を識別できる。 • Set dc = uiview.Documents Set doc = dc.GetFirstDocument
ハイライトの使い道 • UIから文書を開かずdocを取得出来る。 • 開くオペレーションから文書を開かず、ダイアログボックスを 使用して違うDBの違う文書や複合させた情報のダイアログ ボックスをポップアップさせることが出来る。 • 例えば、プロジェクト文書のビューでアクションボタンで顧客 文書のダイアログを開いたり、、、、文書内の埋め込みビュー で請求書一覧があれば、そこから請求書ではなく請求先マス ターの文書を開いたり。
事例１：稼働データの入力から集計まで • 仕事した内容を記録して単価計算して、集計した後に請求する システム。 • 仕事の入力は自身の業務内容に基づいた入力しやすい幾つかの パターンで行える。 • 1文書1文書で作業を行う。 • プロジェクト毎に入力する人。 • 日々精算する人。 • ランダムに入力する人。。。。 • 集計チェックはプロジェクト単位で責任者が承認する。 • 必ずプロジェクト単位で、複数文書を束ねて処理。
稼働入力用ダッシュボード
ビュー内の文書を開こうとすると。。。 この明細は既にしまっている ので編集は出来ません。
読みから選択 ダッシュボードで デフォルトを選択しているので 選び直す必要はない。
アサインされたプロジェクトから選択 アサインのエントリが 少ない人はこちらが便利
選択が嫌いな人は 文字列検索でリスト表示
フォームに依存したフィールドの値は？ • 様々なフォームで入力され、 • 編集自体もユーザーのロールや文書のステータスで変わる。 • そんなときに使える。 • XP,,,,,,
設計の中身を見てみる
入力者ロールや文書ステータスで変える いずれにしてもダイアログに表示します。 表示なら必要最小限の情報。 編集ならモードに応じて事前に選択肢な どを準備してあげる。
プロジェクトから複数選択して集計
複数文書をコレクションして扱う。 コレクションした文書をループを使って 内容の事前チェックを掛ける。 問題なければ本来の処理を実施。
別の会社のよく似たパターン • 稼働データの殆どはメールDBのカレンダーデータから生成さ れている。 • こちらはダイアログによるコントロールは必要なし。 • それよりも簡略化を最優先。 • 結果、ロールとステータス処理だけで充分。
既に登録済みの内容の詳細を記載ほか。
新規は文書を選択・未選択で処理を変更。
カーソルがある文書の情報をもらう シンプルに文書選択してたら 必要な値だけ持ってきてる。 「式で選択文書から値を引き継ぐ」 と似ている
話しはそれてしまいましたが。。。。 • 計算結果フィールドを多用しない。 • 作成時の計算結果やデフォルト値の式も排除しました。 • 多データベースが関係する際、競合が発生しやすい。 • 計算結果ではなくバックエンドで値自体の更新ロジックを走らせる。 • フォームをそのまま開かない。 • ロールやステータスによって表示する内容が変わる。 • 入力支援部分は文書データとして必要としない。 • ダイアログを使用した。 • 複数開けることによる誤入力防ぐ。 • 間違って文書コピーをしてしまわない。 • Notesじゃない方がよい？ • 開発と運用が同時進行できる。 • UIの配布が必要なかった。 • 慣れたオペレーションを使える。
データベースをまたぐ値更新の自動処理 • バックエンドで値の変更 を関連するDBの文書に更 新するエンジンを走らせ ることで計算結果ではな く常に値を最新にする処 理が行われている。 • このロジックでUIで編集 中の競合回避処理も行う • 今回のテーマと離れるの でこの話はまたいつか。