究極のDiscussion Template? -5-
＜話題の履歴＞
今回は親文書や主文書の情報を作成時に保持するのではなく、リアルタイムに取得して表示するための改造を始めてみることにしましょう。
対象となるFieldは前回設計を調べた通り、"OriginalSubject"、"ImmediateParentSubject"、"ParentSubject"となります。
では、まず、"OriginalSubject"を取得することを考えて見ましょう。
これはMain TopicのSubjectを保持しているFieldです。
Fieldの設定は「作成時の計算結果」になっていますが、これを変更して「表示用の計算結果」に変更します。
これにより、文書に主文書のSubjectは保持しなくなります。
式は以下のような式が設定されていますが、この式も削除します。
@If(@IsAvailable(OriginalSubject); OriginalSubject; Subject)
さて、新しい式を考えて見ましょう。
主文書のSubjectを取る必要があるわけですが、何を使って取得すればよいでしょうか?
賢明な皆さんは直ぐに気が付かれるでしょうが、ここでMainIDを利用するのです。
MainID Fieldは「作成時の計算結果」で文書が作成された時に親文書が持っているMainID Fieldの値を引き継いでいくようになっています。
では、このMainIDでどのようにしたら、主文書のSubjectが取得できるでしょうか?
MainIDは主文書のDocument UNIDですから、@GetDocField( DocumentUNID ; FieldName )を使うことができます。
あるいは、Document UNIDでSortしたViewを作成して@DBLookupで参照するという方法もあるでしょう。
以前、Performance Design Tips で@GetDocFieldを使うとPerformanceが悪くなるということを紹介しました。
ここでは、@GetDocFieldを利用して、Performanceが悪くなることを実証してみることにします。
先程はOriginalSubject Fieldを改造することから手を付け始めましたが、一旦この作業は中止することにします。
というのもOriginalSubject Fieldは隠しFieldとなっていて文書に表示するために別の所にFieldを移動するか表示用のFieldを別途設ける必要がありますので、実験のためには作業が多すぎるからです。
今回は、ParentSubject Fieldを対象にして行います。
ParentSubject Fieldはその名の通り親文書のSubjectを持ったFieldで、"Response"や"Response to Response" Formに含まれる"RespBanner" Subformの中に定義されています。
このFieldもOriginalSubject Fieldと同様に作成時の計算結果になっています。
確認のために改造を行う前に、Main Topicを作成してからResponseを作成し、その後最初に作成したMain Topicを修正して返答文書を開いてみましょう。
Main TopicのSubjectが変更されても返答文書に表示される"Response to:"のSubjectは古いままのSubjectが表示されていることが分かります。
では、早速このFieldを変更して常に最新の親文書のSubjectが表示できるようにしましょう。
まず、Fieldのタイプを「作成時の計算結果」から「表示用の計算結果」に変更します。
これにより、親文書のSubjectは保持されなくなります。
また、書かれている式も削除し、元の式の代わりに以下の式を設定します。
@If(@IsNewDoc; Subject ;@GetDocField(@Text($Ref);"Subject"))
皆さんご存知のように親文書へのLinkは$RefというSystem Fieldに保持しています。
これを使って@GetDocFieldで親文書のSubjectの取得が可能です。
また、@IsNewDocで判断させているのには理由があります。
$Ref Fieldは新規文書を作成した場合、保持されていないFieldであり、文書が保存されて初めて保持されます。
つまり、新規文書作成時には$Refは値が無いため、@GetDocFieldがErrorしてしまうからです。
ParentSubjectの左側に作成されているDocLinkParent Fieldを参照してみてください。
同様に@IsNewDocで判断して処理していることがお分かり頂けるでしょう。
設計変更を保存し、文書を作成して試してみましょう。
親文書のSubjectを変更しても子文書に表示される親文書のSubjectは常に最新の物が表示されるようになったことが確認できます。
今回はLocalにDiscussion DBを作成して試していますし、単純な文書で動作確認されていますのでPerformanceに関しては全く分からないのではないでしょうか?
ここに開発者の落とし穴があるのです。
開発する際は、Localで開発したりTest環境を使って開発することがほとんどで、まさか本番環境で直接設計を変更するようなことは皆さん行われていないと思います。
このような環境では@GetDocFieldがどのように動いていてPerformanceにどのように影響するかは気がつかないのです。
では、次回はこの設計変更がPerformanceにどのような影響を及ぼすのかを以前紹介したNTPC Trace を用いて解析してみることにしましょう。