従来型 「domino web 開発」を見なおそう！201611 Notes Consortium Open Seminar 公開版

Notesコンソーシアムオープンセミナー2016 従来型 「Domino Web 開発」を 見なおそう！ ネオアクシス株式会社 阿部 覚

ごあいさつ 所属 ネオアクシス株式会社（neoaxis.co.jp) 顧客常駐ということもあり コンソーシアムの研究会には入ったことがありません テクてくLotus技術者夜会 無欠席キープ中 XPages.JPメンバー 主として「Collaboration Todayじゃぱ～～ん！」担当 式言語好き…というより、 新世紀のツール界に深入りできてない blog "abOut.nsf" > http://blogs.yahoo.co.jp/jftfw228 twitter > @abesat facebook > /abesat

ネオアクシス株式会社について

正直なところ、私の本音 Notesは 使いこむなら クライアント♥

喋ってるとバレると思いますが 古今のWeb系技術 そんなに 詳しくありません

私も当初は Web化開発って 非効率 ツライ

ただ、 あるPJ経験から Web化って面白い 工夫しがいあるな

ひょっとしたら シーンによって 使えるな

本セッションでお話しするのはたぶん… 従来型Web化の 利点と、工夫(案) です。

従来型Web化の概要 たとえば デフォルトアクセス権を 読者以上にした ローカルDBで

従来型Web化の概要

従来型Web化の概要

従来型Web化の概要 • Notes画面をそのままHTMLとして • Notes/Domino R4.5より実装 (1996年！) • 昔は「NotesのWeb化」で通りましたが いまは「XPages」と区別するため • ClassicalなWeb化 • フォームのWeb化 • HTML化 などと呼ばれているのでは

従来型Web化の概要 • 単一ページだけなら何もしなくても HTMLとして表示できます • ビュー→文書など メニュー上、きちんと動作させるためには パーツの追加変更＝開発が必要 • 見るだけでなく、 作成・編集・保存するためには パーツの追加変更＝開発が必要

従来型Web化の概要 使いこめるようにするための開発はけっこう厄介 • 標準的なビューの外観($$ViewTemplateDefault)を作成。検索したいなら$$SearchTemplateDefault • 使える＠関数には制限 LotusScriptもUI系のメソッドはダメ • 単一のボタン機能・フィールド選択機能実現のための、エージェントやフォームを追加 • HTMLやJavascriptを駆使して、組み合わせ、組み合わせ • ヘッダー情報はHTML Head Contents、フォーム上にはHTMLのコードやタグをちりばめ • JavascriptはフォームのJSHeaderやスクリプトライブラリやHTMLソース上や onLoad イベントへ • LotusScriptエージェント内のPrint文でHTMLを書きだし • WebQueryOpenイベントやWebQuerySaveイベント • リッチテキストはクライアントほど融通きかない、添付のためにはコントロール追加 • フレームセット（アウトライン、ページ）の作成、指定 • CGI変数やエラーチェックを考慮した数々の特殊フィールド追加 • 画面間でのデータやり取りにはURLの引数 ： ： ：

従来型Web化の概要 • それに対して、XPages化は 作るのは基本的には、 XPage・カスタムコントロールのみ、あとスクリプトライブラリくらいか 一見単純そうに見えますが、 これまでNotesの世界で表現してきた機能すべてを XPagesの世界(Web2.0の世界)で賄う必要がある (要するにこちらも結構しんどい)

従来型Web化のメリット ここでお話しするような利点を踏まえると 従来型にも芽があるのでは

従来型Web化のメリット その1 Notesクライアントのレイアウトを そのまま使える

従来型Web化のメリット その2 ということは、 非表示式もそのまま♥ この点が けっこう馬鹿にならない XPagesだと可視の式を新たに設定する必要

従来型Web化のメリット その3 「Web上では見るだけ」でよいなら 開発は早い 逆に言えば、作成･編集･保存／申請･承認･･ 更新系が入ると、 途端に難度が上がるのですが

従来型Web化を軽くする工夫 • ここで、過去の体験をお話しします かつての常駐先T社に １年ぶりに常駐することになり 行ってみると・・・

従来型Web化を軽くする工夫 「Notes環境全体をWeb化することになった」 「１年でやりたいので手伝って」 「簡単にWeb化できる と上に云った 稟議が通って、阿部さんを呼べた」 (1,000DB) そんな 簡単じゃないですけど・・・ （聞いたことない規模だし…）

従来型Web化を軽くする工夫 「Notes環境全体をWeb化することになった」 「１年でやりたいので手伝って」 「簡単にWeb化できる と上に云った 稟議が通って、阿部さんを呼べた」 「エンドユーザーにも 手伝わせますよ！」 (1,000DB) そんな 簡単じゃないですけど・・・ （聞いたことない規模だし…） 無理～

従来型Web化を軽くする工夫 従来のWeb化の常識 “１DBあたり■人月” DBにもよるが そこそこ工数必要 従来型 でも XPages でも 従来設計資産（DB）の機能とUIをWeb化するなら それなりに時間を要すると思います

従来型Web化を軽くする工夫 • 各DB共通の考えで作られたセットを作り、共通化・パターン化 • どのDBも共通で追加される設計要素が同じという状態に • 前提となる機能部分をなるだけ共通部分に集約することで 個別設計が増殖してしまうのを抑制 • 作り方も共通に、ある程度はEUCでのWeb化も

従来型Web化を軽くする工夫 • こんなところを共通化・単一化 • $$ViewTemplateDefaultページ(余談：極力フォームにはしない＆クイック検索つきに) • フレームセット • 文書フォーム上で必要な各種ヘッダー・イベント・CGI変数や制御 フィールドはサブフォームへ • アクション・ボタンを押したときに起動するエージェントは 処理にかかわらず同じに （工夫はほかにもありますが 今回触れるおもなもの↑ ）

従来型Web化を軽くする工夫 • こんなところを共通化・単一化 • $$ViewTemplateDefault こちらは比較的よくある共通化ですが • フレームセット • 文書フォーム上で必要な各種ヘッダー・イベント・CGI変数や制御 フィールドはサブフォームへ • アクション・ボタンを押したときに起動するエージェントは 処理にかかわらず同じに こちらについてはもう少し具体的に

軽くする工夫…サブフォームへの集約 文書フォーム上で必要な各種ヘッダー・イベント・CGI変数や制 御フィールドはサブフォームへ • ヘッダー・イベントとしてはこれらをサブフォームに集約しています • • • • • HTML Head Contents JSHeader WebQueryOpenイベント WebQuerySaveイベント onLoad イベント

軽くする工夫…サブフォームへの集約 文書フォーム上で必要な各種ヘッダー・イベント・CGI変数や制 御フィールドはサブフォームへ • ヘッダー・イベントとしてはこれらをサブフォームに集約しています • HTML Head Contents ただし、サブフォームには • JSHeader ありません • WebQueryOpenイベント • WebQuerySaveイベント • onLoad イベント サブフォームにあるけど 動きません

軽くする工夫…サブフォームへの集約 • サブフォームに存在しないイベントもありますが 古い予約フィールドやパススルーHTMLで代替可能 詳細は私のブログにて（ http://blogs.yahoo.co.jp/jftfw228 ） WebQueryOpenがなかったころの。。 WebQuerySaveがなかったころの…それと。。 $$Query- 予約フィールドは必須フィールドなのだ あと、これとコレもサブフォームに置けるのだ

• http://blogs.yahoo.co.jp/jftfw228
• http://blogs.yahoo.co.jp/jftfw228/13894587.html
• http://blogs.yahoo.co.jp/jftfw228/13918642.html
• http://blogs.yahoo.co.jp/jftfw228/13981605.html
• http://rdsig.yahoo.co.jp/blog/article/titlelink/RV=1/RU=aHR0cDovL2Jsb2dzLnlhaG9vLmNvLmpwL2pmdGZ3MjI4LzE0MDU3Mzg5Lmh0bWw-

軽くする工夫…サブフォームへの集約 • $$HTMLHeadでJavascriptライブラリやスタイルシートも読み込 めます。ある程度Web2.0的な機能と見栄えを工夫の余地も。 たとえばXPagesで使われるdojo toolkit （jQueryと 統合しちゃうらしいけど）

軽くする工夫…サブフォームへの集約 • フィールド属性に、 決まったコードを 入れるだけで dojo の表現に • 少し工夫すると 機能もクライアントに 近づけられる

軽くする工夫…アクション・ボタンは 単一エージェントへ 従来の「従来型Web化」の常識 ボタン･アクション少しでも複雑な処理は 元は単純な式でできていても ↓ ひとつひとつ LotusScriptとJavascriptを絡めた 長～いエージェントに 書き直さなきゃ

軽くする工夫…アクション・ボタンは 単一エージェントへ ここで一つ考えていただきたいのですが 「保存」「ドラフト保存」「申請」「承認」「公開」 ･･･ 多くのボタン・アクションで共通することは？

軽くする工夫…アクション・ボタンは 単一エージェントへ 大半の文書処理アクション/ボタンのキモは ・項目に値を入れて文書を保存すること これに、 ・データについて連絡･依頼する（メール） ・開始／終了／必須確認などのメッセージ が付随するものと 捉えられないでしょうか

軽くする工夫…アクション・ボタンは 単一エージェントへ 私たちの場合は、この観点で各処理を見直し 複雑に見えても整理 ひとつのエージェントから アクション・ボタン別に ・フィールドに文書をセット ・メール ・メッセージ ・保存

軽くする工夫…アクション・ボタンは 単一エージェントへ 私たちのケースでは ・フィールドに文書をセット ・メール ・メッセージ エージェントがアクション・ボタンごとに これらを記載した設定文書を参照するようにしています

軽くする工夫…アクション・ボタンは 単一エージェントへ 設定文書の例 元々 式で書かれていた ボタン･アクションを、 内容別に“お引っ越し“させる

軽くする工夫…アクション・ボタンは 単一エージェントへ 副次効果として 設定文書を順繰りに眺めるだけで このDBで何をしてるか大体わかる いつの間にか、各処理が見える化して 設計資源が 半ばたな卸しされた状態に

かんたんなまとめ Web化開発するなら

かんたんなまとめ Web化開発するなら × XPages 〇 従来型

かんたんなまとめ たとえばこんな使いわけ ・”コアなDBは手間ひまかけて Web2.0のメリットを享受 モバイルにも対応させよう” (たとえばXPages開発、もしくは各社対応製品の導入など） ・ ”残るDBは、 従来型で手早くWeb化♥”

ご清聴 ありがとうございました！