前回2回に渡りIBM Championがスピーカーを務めるセッションにフォーカスを当てたレポートブログを紹介してきました。

• IBM Connect 2016 XPAGES 最新動向
• IBM Connect 2016 XPAGES 最新動向 Part 2 – 外部連携

今回はPaul Withers氏の「”Marty, You’re Just Not Thinking Fourth Dimensionally”: Troubleshooting XPages」のセッションに参加した内容を振り返りたいと思います。
このセッションではStackoverflowで寄せられた質問などをもとにXPAGESでの間違ったアプローチの紹介やトラブルシューティングの方法などノウハウ情報を満載の内容となっていました。

また、このセッションではXPAGESの基礎知識を持っていることが前提になっており「XPAGESを既に使っている人は挙手してください」と質問すると会場のほぼすべての人が手を挙げていたのも印象的でした。 そして前列に座ったIBM Champion達が突っ込みを入れながらさらに話がディープに進んで行くのもIBM Connectのセッションならではの光景です。

documentidプロパティでは常に式言語(EL)を使うこと

このセッション内の数あるトピックの中でも全てのXPAGES開発者が知っておくべきノウハウであり、知らずにやってしまいがちな落とし穴であると思ったのがこの「documentidプロパティなどでは常に式言語(EL)を使う」ということでしたので、私自身でテストしたサンプルコードを交えてこのトピックを掘り下げて紹介したいと思います。

※ちなみに式言語(EL)とは${…}もしくは#{…}で始まるコードの事で#{javascript:…}ではないことと区別しています。

Stackoverflowのこちらのリンク「Why does this code write out TWO documents?」でPaul氏が自ら回答している内容にも絡んでいるのですが、Paul氏が指摘するには、式言語(EL)を使わなければページロード時にdocumentidのプロパティ計算ロジックが4回も呼ばれてしまうと指摘しています。

まずはこちらに用意したサンプルコードを見てください。

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core"
	xmlns:xe="http://www.ibm.com/xsp/coreex"
	xmlns:xc="http://www.ibm.com/xsp/custom">
	<xp:this.beforePageLoad><![CDATA[#{javascript:
viewScope.selectedPage = "AllContacts";}]]></xp:this.beforePageLoad>

	<xp:this.data>
		<xp:dominoDocument var="document1" action="editDocument">
			<xp:this.documentId><![CDATA[#{javascript:
var v:NotesView = database.getView(viewScope.selectedPage);
var doc:NotesDocuent = v.getFirstDocument();
if (doc == null){
	print ("not found");
	return null;
}
else{
	print ("doc found");
	return doc.getUniversalID();
}}]]></xp:this.documentId>
		</xp:dominoDocument>
	</xp:this.data>
	<xp:panel>
		<xe:widgetContainer id="widgetContainerHeader">
			<xp:panel>
				<!-- フィールドの表示 -->
			</xp:panel>
		</xe:widgetContainer>
	</xp:panel>
</xp:view>

Domino文書データソースを定義する箇所でdocumentIdプロパティに対して値の計算をしています。
UNIDを引っ張ってきたいのでViewを取得して文書を取得してそのUNIDを返すというロジックになります。

如何でしょうか？ 皆さんもこれに似たロジックを書いた経験はないでしょうか？
このサンプルには１つの致命的な問題と２つの推奨されないコードが含まれています。

1つ目の致命的な問題とはbeforePageLoadにてviewScopeの変数をセットしデータソース内でそのviewScope変数を利用しているという箇所です。
これはデータソースのほうが先にプロセスが走りその後にbeforePageLoadのプロセスが走るため5行目のviewScope.selectedPageが意図したとおりに設定されずサーバーエラーを起こしてしまいます。

そこでひとまず問題を解決するために以下のようにコードを書き換えます。

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core"
	xmlns:xe="http://www.ibm.com/xsp/coreex"
	xmlns:xc="http://www.ibm.com/xsp/custom">
	<xp:this.data>
		<xp:dominoDocument var="document1" action="editDocument">
			<xp:this.documentId><![CDATA[#{javascript:
var v:NotesView = database.getView("AllContacts");
var doc:NotesDocuent = v.getFirstDocument();
if (doc == null){
	print ("not found");
	return null;
}
else{
	print ("doc found");
	return doc.getUniversalID();
}}]]></xp:this.documentId>
		</xp:dominoDocument>
	</xp:this.data>
	<xp:panel>
		<xe:widgetContainer id="widgetContainerHeader">
			<xp:panel>
				<!-- フィールドの表示 -->
			</xp:panel>
		</xe:widgetContainer>
	</xp:panel>
</xp:view>

beforePageLoadでのviewScopeの利用をやめ、8行目にビューの値をハードコードで渡してやりました。これでとりあえずサーバーエラーは回避され、見かけ上は意図したとおりにブラウザでこのコードを表示されるでしょう。

推奨されないコード その１

しかし、このコードにはまだ推奨されないコードが含まれており、試しにブラウザでこのコードを表示してみるとAdministratorのコンソールに以下のような出力があることが確認できます。

HTTP JVM: doc found
HTTP JVM: doc found
HTTP JVM: doc found
HTTP JVM: doc found

このように、documentIdの値の計算の処理が4回も呼び出されています。これこそが今回Paul氏が指摘する問題の箇所になります。
Paul氏によると4回も呼び出される理由は以下のようになります。

式言語(EL) 【${…}もしくは#{…}】を使わなかった場合、documentIdのようなプロパティを

• Panel内に追加した場合、beforePageLoadの後に2回呼び出される
• XPage内に追加した場合、beforePageLoadの前に2回呼び出される。(このときbeforePageLoadで追加したscope変数は使えない)
• 常にrender response時に2回呼び出される

ということで、上記サンプルの場合４回呼び出されるということになります。
そこで回避策として式言語(EL)を利用することでこの問題は回避されます。

以下に1回のみ呼び出される式言語(EL)を利用したサンプルコードを追加します。

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core"
	xmlns:xe="http://www.ibm.com/xsp/coreex"
	xmlns:xc="http://www.ibm.com/xsp/custom">
	<xp:this.beforePageLoad><![CDATA[#{javascript:
javascript:viewScope.selectedPage = "AllContacts";
var v:NotesView = database.getView(viewScope.selectedPage);
var doc:NotesDocuent = v.getFirstDocument();
if (doc == null){
	print ("not found");
	viewScope.docId = null;
}
else{
	print ("doc found");
	viewScope.docId = doc.getUniversalID();
}}]]></xp:this.beforePageLoad>

	<xp:this.data>
		<xp:dominoDocument var="document1" action="editDocument"
			documentId="#{viewScope.docId}">
		</xp:dominoDocument>
	</xp:this.data>
	<xp:panel>
		<xe:widgetContainer id="widgetContainerHeader">
			<xp:panel>
				<xc:beforePageLoad></xc:beforePageLoad>
			</xp:panel>
		</xe:widgetContainer>
	</xp:panel>
</xp:view>

このコードをadministratorコンソールで確認すると

HTTP JVM: doc found

のように1回しか呼び出されていないことが確認できます。

また、式言語(EL)で「動的に計算」を利用しているため、beforePageLoadで設定されたscope変数が利用できていることにも注目してください。
documentId=”#{viewScope.docId}”
の箇所が
documentId=”#{javascript:viewScope.docId}”
では意図した動作になりません。

推奨されないコード その２

Domino文書のデータソースを定義する際にignoreRequestParams=”true”を明示的に定義してやらないとURLパラメータのdocumentIdで指定された値が常に優先されるため、このようなロジックを書くときはignoreRequestParams=”true”を明示的に定義してやるべきです。

こんな事例が沢山

今回はこのブログを書くにあたってPaul氏の指摘を深堀して実証実験を行ってみましたが、実際にPaul氏のセッションではこれに似た内容がいくつもスライドとデモで紹介され、どれもがものすごいスピードで紹介されるためはっきり言ってついていくのがやっとな状態のかなりレベルの高い内容となっていました。

1年を通してStackoverflowでいくつもの質問に対して回答をしているPaul氏ならではのノウハウの詰まったセッションであっただけに、今回のセッションに参加できただけでもIBM Connectに来た甲斐があったと思える、そんなセッションでした。

なお、こちらのセッションのスライドは既に公開されており、こちらより確認できます。
http://www.idonotes.com/IdoNotes/IdoConnect2013.nsf/dx/1279a-marty-youre-just-not-thinking-fourth-dimensionally-troubleshooting-xpages-2016.htm
Chris Millerさんのサイトでその他のセッションを含めLotusphere 2013からのセッションがタイトル別にまとめられています。既に2016年のセッションもいくつか登録されているようなので確認してみてください。