201912 のの会@関数Talk 18th | Talks around @Functions in Notes and Domino

@ -notes knows community- 2019/12/12 @関数Talk 第18回 公開版 @ 阿部 覚 (tw:) @abesat

@ @DbColumn, @DbLookupの お話しを3回続けました まだ残っているのですが ちょっと息切れした?ので @ 今回は 別の関数を挟みたいと思います

@ @DocumentUniqueID @InheritedDocumentUniqueIDの 雑談 @

@ 「文書ID」とか「ユニバーサルID」と呼ばれるものを 返す関数です @DocumentUniqueID ＝自文書のID @InheritedDocumentUniqueID @ ＝親文書のID おそらく、考えられる使い方は2通りだと思います

@ 考えられる使い方その1 @DocumentUniqueID ひとつは @InheritedDocumentUniqueID @ そのまんまの形で フィールドの式に使うこと

@ 使い方その1…@DocumentUniqueID を、そのまんま使う とりあえず、@DocumentUniqueID でやってみましょう そのまんま、フィールドの式に入れてみます @ つまり、 編集可能なフィールドならDefault valueに 計算結果系のフィールドならValueに @DocumentUniqueID とだけ記述します

@ 使い方その1…@DocumentUniqueID を、そのまんま使う テキストだけでなく、 他のタイプの フィールドでも やっちゃいましょうか @ 日付とか時間とか ついでだから チェックボックスなんかでも

@ 使い方その1…@DocumentUniqueID を、そのまんま使う どうせだからとマトリックスにして このくらいやっちゃいます 編集可能 計算結果 表示用の計算結果 作成時の計算結果 テキスト 日付/時刻 数値 ダイアログリスト チェックボックス リッチテキスト @

@ 使い方その1…@DocumentUniqueID を、そのまんま使う フォームを保存したあと、 ビューのボタンから… 余談ですが、われわれ開発者は ビューのコレのことを 「アクション」と呼びますが、 普通のユーザーさんにとっては やっぱり「ボタン」みたいですね アクションでもボタンでもいいけど話を戻して、 「新規文書作成」します … @ すると、

@ 使い方その1…@DocumentUniqueID を、そのまんま使う こうなります！ @ つまり、フィールドのタイプに関わらず、 常に文書リンクを生成するようです

@ 使い方その1…@DocumentUniqueID を、そのまんま使う ただし文書を保存してから開きなおすと 文書リンクが消えてしまうものもあります @ 日時と数値では編集可能な式と作成時の計算結果のリンクが消えました 本来のフィールドタイプのほうが勝ってしまったということか… この表ではすべてのフィールドのタイプをためしてはいないので 他が気になる方は是非おためしを

@ 使い方その1…@DocumentUniqueID を、そのまんま使う でも、この文書リンク… @

@ 使い方その1…@DocumentUniqueID を、そのまんま使う でも、この文書リンク… いったい なんの @ 役に立つの!?

@ 使い方その1…@DocumentUniqueID を、そのまんま使う @DocumentUniqueIDの文書リンクは 自文書への文書リンクだから、クリックしたところで リンク先も自文書、つまり、なんにも変わらない しいて意味づけするとすれば… @

@ 使い方その1…@DocumentUniqueID を、そのまんま使う @DocumentUniqueIDの文書リンクは 自文書への文書リンクだから、クリックしたところで リンク先も自文書、つまり、なんにも変わらない しいて意味づけするとすれば… ? し が 自分さ @ というわけで、 そのまんま使う@DocumentUniqueIDについて なにか有効な使い道が浮かんだ方は い 教えてください 😅

@ 使い方その1…@Inherited~ も、そのまんま使う 一方で、 @InheritedDocumentUniqueID をそのまんま使う場合は 多少は意味がありそうです @InheritedDocumentUniqueID は、 元文書からの値の引継ぎが設定された 返答のフォームで使用します @ 「返答のフォーム」と言われてもぴんとこない "ののさん"（開発ビギナーさん）向けに簡潔に： 「他の文書にぶら下がって表示される文書のフォーム」です - この後の画面でイメージしてもらえるかな…? -

@ 使い方その1…@Inherited~ も、そのまんま使う 同じようにフィールドの種類ごとに仕組んで 返答のフォームを保存したら、 クライアントで返答の作成「ボタン」をクリック @

@ 使い方その1…@Inherited~ も、そのまんま使う やっぱりこんな風に文書リンクになりますが 今度は、クリックしたリンクが、 元の文書（親文書）を開きます @

@ 使い方その1…@Inherited~ も、そのまんま使う ただし、どのフィールドでも、ではなく 編集可能と作成時の計算結果に限られます 元文書が開く 💛 自分さがし 😑 @ 元文書が開く 💛

@ ところで… 返答型の文書には $Refという隠しフィールドが必ずあって これが元文書（親文書）を指しています @InheritedDocumentUniqueID のヘルプには $Ref のことが一緒に書かれていることもあり @ @InheritedDocumentUniqueIDと$Refは 同じように使えるような印象を お持ちのかたがおられると思います。 せっかくなんで、ためしてみました

@Inherited~ を、$Refフィールドの参照とくらべてみる @ つまり、返答型のフォーム内で 式を $Ref に変更したセットも加えてみました @ 結果を簡潔にご報告しますと、

@Inherited~ を、$Refフィールドの参照とくらべてみる @ こんな感じでした @

@Inherited~ を、$Refフィールドの参照とくらべてみる @ @InheritedDocumentUniqueIDと併せてみると 💛 💛 自分さがし 😑 @ 💛 元文書が開く 💛

@Inherited~ を、$Refフィールドの参照とくらべてみる @ こんな感じでした 式 @InheritedDocumentUniqueID $Ref 編集可能 Editable 〇 ✕ 計算結果 Computed ✕ 〇 表示用の計算結果 Computed for display ✕ 〇 作成時の計算結果 Computed when composed 〇 ✕ @ 結果的に補完しあう関係に見えますが、 おそらく意図されたものではないだろう、と思います

@念のため… 実験精神で いくつかのフィールドタイプを同時進行で試しましたが ふつうに使う場合はテキストフィールドになると思います @

@今回はこれでおしまいです はじめに「使い方には2通りある」と申しながら 1つ目の「そのまんま使う」だけで 終わってしまいました 💦 年明け後にもう1つの「@Textと使う」をやるか それとも @DbColumn, @DbLookup 関数の続きを行うか これから考えます… @

@ 今回もお付き合い ありがとうございました @