Inside of Teeda おおたに.

Slides:



Advertisements
Similar presentations
Copyright© The Seasar Foundation and the others. All rights reserved. 1 Seasar Conference 2007 Spring Seasar Conference 2007 Spring 今から役立つ !
Advertisements

年度 J2EE II 稚内北星学園大学 情報メディア学部 専任講師 安藤 友晴. 2 この講義の位置づけ 3年前期の「データベース論 (J2EE I) 」に続く講義。 「データベース論」の講義内容を理解 していることが前提。
© The Seasar Project and the others all rights reserved. 1 Seasar Conference 2006 Spring JSF の波に乗れ! ~ Teeda ではじめる JSF Teeda プロジェクトリーダ.
Struts VS SAStruts ・ STRUTS と SAStruts を比較します。. Struts のメリット1 STRUTS はディファクトスタンダード。 ↓ プログラマがたくさんいる。 ライブラリ、ツールがたくさんある。 ビジネス案件が豊富。 書籍などの情報元が豊富。
Flash SWF ファイル書き換え PHP extension 2008 年 7 月 21 日 よや.
Web アプリをユーザー毎に カスタマイズ可能にする AOP フレームワーク
情報・知能工学系 山本一公 プログラミング演習Ⅱ 第3回 配列(1) 情報・知能工学系 山本一公
2006年11月22日 植田龍男 Webサービス II (第9回) 年11月22日 植田龍男.
プログラミング基礎I(再) 山元進.
Struts1.xの脆弱性(CVE ) に対するSDEの対処:推奨タイプ (サンプルソースコードの公開)
CakePHPを業務に導入する Shin x blog 新原 雅司.
JSFによるWebアプリケーション開発 第9回
背景 我々の研究室で開発しているJavaプログラム解析フレ ームワークでは,解析情報はメモリ上に保持される 問題点
Win32APIとMFC H107102 古田雅基 H107048 佐藤一樹 H107126 山下洋平.
エンタープライズアプリケーション II 第10回 / 2006年7月23日
JSFによるWebアプリケーション開発 第11回
Servlet J2EE I 第8回 /
アルゴリズムとプログラミング (Algorithms and Programming)
JavaServlet&JSP入門 01K0018 中村太一.
第2回:Javaの変数と型の宣言 プログラミングII 2007年10月2日.
HTTPプロトコルとJSP (1) データベース論 第3回.
JavaBeans とJSP データベース論 第5回.
JSFによるWebアプリケーション開発 第6回
HTTPプロトコル J2EE I 第7回 /
エンタープライズアプリケーション II 第7回 / 2006年7月9日
第20章 Flyweight ~同じものを共有して無駄をなくす~
JSPの作成 J2EE II 第3回 2005年4月10日.
アルゴリズムとデータ構造 2011年6月20日
プログラミング 平成24年10月30日 森田 彦.
2004年度 サマースクール in 稚内 JavaによるWebアプリケーション入門
2003年度 データベース論 安藤 友晴.
第12回 2007年7月13日 応用Java (Java/XML).
JAVA入門後期⑩ 情報処理試験例題解説.
WebサービスII (第7回) 2007年11月7日 植田龍男.
理学部 情報科学科 指導教官 千葉 滋 助教授 学籍番号 03_03686 内河 綾
Windows PowerShell Cmdlet
EclipseでWekaのAPIを呼び出す
Javaによる Webアプリケーション入門 第6回
10-1 SAXの概要 10-2 Saxプログラミングの基礎 10-3 saxのプログラム例
Jakarta Struts (2) ソフトウェア特論 第11回.
Javaによる Webアプリケーション入門 第2回
Java/Swingについて+ (4) 2005年10月26日 海谷 治彦.
オブジェクト指向言語論 第十一回 知能情報学部 新田直也.
Javaによる Webアプリケーション入門 第11回
JSFによるWebアプリケーション開発 第3回
オブジェクト指向言語論 第十一回 知能情報学部 新田直也.
TDD ってどんな感じ? FizzBuzz を作ってみる 2010/01/22 biac 1.
オブジェクト指向言語論 第六回 知能情報学部 新田直也.
プログラミング言語論 第六回 理工学部 情報システム工学科 新田直也.
プログラミング言語論 第十三回 理工学部 情報システム工学科 新田直也.
EntityManager と EJB QL EJB 3.0 コース 第8回 2006年8月5日.
Webアプリケーションと JSPの基本 ソフトウェア特論 第4回.
Javaによる Webアプリケーション入門 第4回
System.AddInを利用したアプリケーション拡張 - アドインの開発 -
WebアプリケーションとTomcat ― これまでの復習とこれからの予習 ―
JSPの基本 データベース論 第2回.
Action Method の実装 J2EE II 第9回 2004年12月2日.
稚内北星学園大学 情報メディア学部 安藤 友晴
Jakarta Struts (1) ソフトウェア特論 第10回.
稚内北星学園大学 情報メディア学部 専任講師 安藤 友晴
JSPの基本 J2EE I (データベース論) 第8回 /
JSFによるWebアプリケーション開発 第5回
アルゴリズムとデータ構造 2012年6月21日
第7章 そろそろ int 以外も使ってみよう! ~データ型 double , bool~
Javaとは Javaとはオブジェクト指向言語でJava VM(Java仮想マシン)と呼ばれるプログラム上で動作します。
オブジェクト指向言語における セキュリティ解析アルゴリズムの提案と実現
プログラミング 平成28年10月25日 森田 彦.
JSFによるWebアプリケーション開発 第7回
System.AddInを利用したアプリケーション拡張 - アドインの開発 -
How To WPF アプリケーション Part3 By 中博俊.
Presentation transcript:

 Inside of Teeda おおたに

Teeda? JSF実装部分 拡張部分 Ajax 1.1ベース。TCKは(まだ)通してない。 ViewHandlerをエントリポイントとして介入。 PRGパターン、HTMLテンプレート Ajax 実はTeedaに依存してない。

Core 思想 最初のアイデアはJSFのDI機能 負の面で言えば、他JSF実装がいまいちだった(当時) 実はOSSになる予定も無かった。

Core(2) 一通り実装 DIコンテナとの連携を最初から意識 UIComponent、Lifecycle&Phase、Renderer、StateManager、Validator/Converter、Tag、ValueBinding、Handlerなどなど DIコンテナとの連携を最初から意識 普通にVariableResolverでS2を呼ぶ

Core(3) Lifecycleは以下のPhaseから成る RestoreView:Viewの復元 ApplyRequestValue:requestからdecode ProcessValidation:Convert/Validate UpdateModelValue:Modelの更新 InvokeApplication:Model実行 RenderResponse:描画

Core(4) UIComponent Renderer 画面上に配置される各項目を抽象化したもの このツリーが構築される 実際に描画する。 JSFで最も毒素がつまったところ。

Core(5) ValueBinding 内部的にはJSP2.0のEL式 ぶっちゃけCommonsELじゃん。 Extensionで多用 #{aaa.bbb} -> ${aaa.bbb} #{クラス.プロパティ} #{クラス.メソッド名}(メソッドバインディング) ぶっちゃけCommonsELじゃん。 Extensionで多用

Core(6) そのほか StateManager Test 他JSF実装ではしこたまSessionに格納 Teedaでは、ComponentTreeは1つのみ ほとんどのコンポーネントで動的に変更が入るのはvalueとsubmittedValueくらい。だからいいじゃん。 Test JSFとしてのテスト環境は群を抜いて揃ってる Test重要

Extensionのコンセプト S2JSFより軽いHTMLテンプレート 規約重視で設定少ない POJO Page駆動 JavaEE勉強会のyuki_neko_nyanさんの「私がほしいPresentationFramework」には結構影響を受けてる。

Extensionばっさり 基本的なベースは、S2JSFの発展系 Id書いて、HTMLとPageをマッピング ドン引きではそんなことは説明しません サンプル見て。ソース嫁。おしまい。 その代わりにHowを書き殴りご紹介

Extensionばっさり(2) HtmlViewHandlerがエントリポイント restoreView createView renderView

HtmlViewHandler#restoreView restoreView(TagProcessorCache) Teedaで扱う抽象的なリソースの作成・復元 HtmlDesc XercesにXHTMLとして読ませ、HtmlNodeのツリー構築 PageDesc NamingConventionにviewIdをキーにfind /aaa/bbb.html -> aaa_bbbPage ActionDesc どれも更新時間をstoreして、毎回チェック HotDeployのため

HTMLのparseと分類 TeedaではXHTMLとしてparse Neko使わないで、Xercesのみで。 HtmlNodeに分類 DocumentNode DOCTYPEをあらわす要素 ElementNode 基本idがついている要素(カスタマイズ可能) JSFのUIComponentとして処理される TextNode Textとして出力される要素

HTMLのparseと分類(2) XercesのXNIレベルで文字実体参照のまま、ブラウザに任せている。 DocumentScannerでnormalizeさせない http://d.hatena.ne.jp/shot6/20060730

コンポーネントとのマッチング準備編 構築されたDesc系はこのようになる。 HtmlDescはNodeツリーを保持。 PageDescはClassから、各要素を抽出・集約 各DescにあるFileは、更新チェックのため。 HtmlDesc PageDesc Htmlファイル Pageのclass Pageファイル HtmlNodeツリー pageName

各Descを元に規約とマッチングしたものをJSFのコンポーネントとバインディングする。 規約によるコンポーネントとのマッチング 各Descを元に規約とマッチングしたものをJSFのコンポーネントとバインディングする。 AbstractElementProcessorFactory 各JSFコンポーネント毎に継承して作成 Org.seasar.teeda.extension.html.factory isMatch 規約とのマッチング customizeProperties 各コンポーネント用にプロパティをValueBinding式で独自にカスタマイズ。

こんな感じ 各JSFコンポーネント毎の FactoryがDIされる。 protected void assembleTagProcessor(ElementProcessor parentProcessor, ElementNode elementNode, PageDesc pageDesc, ActionDesc actionDesc) { for (int i = 0; i < factories.length; ++i) { ElementProcessorFactory factory = factories[i]; if (factory.isMatch(elementNode, pageDesc, actionDesc)) { ElementProcessor elementProcessor = factory.createProcessor( elementNode, pageDesc, actionDesc); parentProcessor.addElement(elementProcessor); if (!factory.isLeaf()) { assembleElementNodeChildren(elementProcessor, elementNode, pageDesc, actionDesc); } elementProcessor.endElement(); return; 各JSFコンポーネント毎の FactoryがDIされる。

InputTextFactory#isMatch public class InputTextFactory extends AbstractElementProcessorFactory { public boolean isMatch(ElementNode elementNode, PageDesc pageDesc, ActionDesc actionDesc) { if (!JsfConstants.INPUT_ELEM.equalsIgnoreCase(elementNode.getTagName())) { return false; } if (!JsfConstants.TEXT_VALUE.equalsIgnoreCase(elementNode .getProperty(JsfConstants.TYPE_ATTR))) { if (pageDesc == null) { return pageDesc.hasProperty(elementNode.getId()); Tagがinputで、typeはText、PageにプロパティがあればOK。

InputTextFactory#customizeProperties protected void customizeProperties(Map properties, ElementNode elementNode, PageDesc pageDesc, ActionDesc actionDesc) { super .customizeProperties(properties, elementNode, pageDesc, actionDesc); if (pageDesc != null) { properties.put(JsfConstants.VALUE_ATTR, getBindingExpression( pageDesc.getPageName(), elementNode.getId())); } #{addPage.arg1}のようにEL式を生成して、 value属性に突っ込まれる。他もほぼすべてこれと同じ。 ここで初めてJSFのコンポーネントとマッピングされる。

HtmlViewHandler#createView JSPをエミュレートして、動かす 基本的にはS2JSFと同じやり方 ぶっちゃけコンポーネントツリーさえ出来れば良いので、その該当部分であるfindComponentだけ呼んで、構成。

こんな感じ protected void composeComponentTree(FacesContext context, PageContext pageContext, UIComponentTag tag, UIComponentTag parentTag) throws JspException { if (parentTag != null) { tag.setParent(parentTag); } tag.setPageContext(pageContext); Map ignoredProps = setupProperties(tag); tag.setupFacesContext(); UIComponent component = tag.findComponent(context); component.getAttributes().putAll(ignoredProps); tag.pushUIComponentTag(); try { composeComponentTreeChildren(context, pageContext, tag); } finally { tag.popUIComponentTag();

HtmlViewHandler#renderView S2JSFと同じ

PRG POST-REDIRECT-GETの組み合わせによる画面遷移を実現 TSSの記事読んでください。 URLが正しく出るのは、気持ち良い。

PRG、Teedaでの実装 HtmlNavigationHandler.handleNavigationでredirect Pageクラスのスコープはrequest PRGでは当然requestスコープのインスタンスを2つ使うため、インスタンス間でデータのLOSTが無いようにしないといけない。

PRGパターンイメージ(こぴぺ View(Client) Teeda(Server) POST REDIRECT ブラウザが反応 GET addInput.html addResult.html POST GET REDIRECT View(Client) Teeda(Server) AddInputPage AddResultPage 状態をsave 状態をrestore ブラウザが反応

PRG実装雑多ネタ編 HTTPのステータスコードが302の場合、ほとんどのブラウザはconfirmメッセージを出さない。 実は厳密には仕様ではそうじゃない。 PRGを考えた人は確信犯的にこれを狙ってる。 だからconfirmメッセージが出ない。

SessionPagePersistence Pageのプロパティのsave/restore 基本同一のプロパティ名があればコピー 画面から入力されてきそうな型しかサポートしてない。 余分なプロパティを渡さないため LRU形式でviewIdに対して10個のみ管理 TakeOverアノテーションで細かく管理可能

TakeOver public class AddResultPage { private Integer arg1; private Integer result; public static final String jumpAddInput_TAKE_OVER = "type=never"; 後、省略。

設定いらず ほとんどは規約のおかげ Navigationの部分はそれなりにやってる 現在のViewIdとValueBinding結果(outcome)から行き先を類推 viewId=/view/aaa/bbb.html、outcome=ccc   とすると、/view/aaa/ccc.htmlと類推。 viewId=/view/aaa/bbb.html、outcome=ddd_ccc   とすると、/view/ddd/ccc.htmlと類推。

ま、そんなもんでげす。

Teeda再考 私がほしいPresentationFrameworkをベースに再考してみる。 ここからが実は一番やりたかったこと

Architecture 普通にMVC ひたすらWrap(request/responseAPI、JSFのXxxとか) 当然使うことも当然出来る。 しかしJSF自体を隠蔽しきれてはいない。 Unobtrusiveだとは少しはいえる。

ConfigurationとOCP 新しいAction追加したときに何故かXMLをいじったりしてない? してない。そもそもConfigurationをほとんどXMLでは書かない。 規約ベースはやはり楽。

Rule and Conventions そのルール(規約)は明解か? 余計なことは言わず、必要なことだけちゃんと言ってる? 直感的? 多すぎてない? これらが正直ちょこっと改善の余地あり。規約が増えていったときの対策は必要。 でも規約は決めてしまうと変えずらい。 今後の方向性に影響。

Simplicity/Complexity do one thing very well? とは言えず、多方面に手を出しすぎてる JSF実装した時点でわかれよw>自分 正直自分のポリシーからは、ずれが出ている。 JSFとの協調 ベースのJSFの制約が徐々に増加。 コードベースの拡大につながる。 個人的には割と不安。良い傾向じゃない。

UserInterfaceとしてのFW 動かすまでの設定 開発/運用モードのDebugスクリーン Doltengのサポートつきで及第点 いまだHotDeployをゼロからは多分難しい 開発/運用モードのDebugスクリーン Clickにあるブルースクリーンのような機能は無い。ユーザーに易しいとはいえない。 ExceptionにJIRAとMLのアドレス埋め込むくらいからスタートしてもかも。

UserInterfaceとしてのFW(2) VisualConfiguration(設定の可視化、Deploy/Undeployも操作可能、履歴・状況把握機能など) HotDeploy/CoolDeployなどはようやく可視化 でも他にもやれる事はたくさんある。 Testability 今でもそれなりに高いが、それはUTの話。 IntegrationTestツールの提供は急務

Thanks ありがとうございましたm(_ _)m もう眠いです、限界ですZzzzz