[Seasar-user:8216] 【Teeda】forEach内のcondition が表示されない
の件に関してちょっと再調査してたのですが、ようやく再現トリガがわかりました。
“Teeda-1.0.8”で再現したのですが、“Teeda-1.0.9-SNAPSHOT”にしたら
再現しない...直ってる！？とにもかくにもどうやったら再現したかと言うと、
<tbody id="resultItems">
<tr>
<td>
<div> id="isEditable" ...
<div> id="isNotEditable" ...
</td>↓↓↓
<tbody id="resultItems">
<tr id="row" style="dummy">
<td>
<div> id="isEditable" ...
<div> id="isNotEditable" ...
</td>とすると再現しました。(Teeda-Exampleでも再現)
“row”は、一覧の背景色を行毎に変更するためにDynamicPropertyを使っています。
確かに「Conditionが両方とも消えてしまう」現象が簡単に発生しました。
その現象が発生する行は、そのConditionがtrueの行です(検証の限りは)。Teeda内部の動きを見てみると、TConditionの判定が悪いのかな？と思っていたら、
ComponentTreeが正常に作られてないような感じがしました。
TConditionのencodeBegin()が呼び出されていないのです。
LogでComponentのRenderingしているところを見てみると、
現象発生行では“row”以下のChildComponentが存在していないように見えます。
なので、本当はこのComponentがなぜ作られてないのかまで追っ掛けたいのですが、
体力の限界...すいません。Rendering周りのProgramを追っかけるのがかなり大変で現象がまとめきれないのですが、
“Teeda-1.0.9-SNAPSHOT”したら発生条件を満たしていてもパッとでなくなりました。これは、「修正された」のでしょうか？
それとも「別の修正によってたまたま直った」のでしょうか？TCondition自体は、refresh属性の実装でかなり修正が入ってましたが、
見る限りこれで現象がなくなるような修正内容ではない気がします。いずれにせよ、プロジェクト最大のリスクだった課題が最新では動いている。
結局display:noneによる回避をしてしまったので複雑な気持ちです。
(display:noneはProjectで制定されたAccessibilityに引っ掛かる恐れが...)
doOnce()で例外発生の件も6月3日に修正されていますが、
残念ながらリリース版Teedaは5月31日のもの...
IT1も終盤にひかえこの時期でのVersionUpは不可。前回案件：Teeda-1.0.7-SNAPSHOT(?月??日)によるリリース
今回案件：Teeda-1.0.8-SNAPSHOT(5月31日)によるリリース一度も正式Versionでのリリースができてない...
(Teeda-1.0.7は、doOnce()が全く動かないので論外)
「世界18カ国のサイトに進出」
「携帯サイトに進出」(これは今からリリース)
しながらも、残念ながら、Teedaの評価は大きく割れます。
悲観的な大きなポイントは：
・イレギュラーケースに弱すぎる
・不安定でVersionUpが恐い(安定版が存在しない)
前向きな大きなポイントは：
・素敵な仕様である。(特にHTMLテンプレート)
・MLの厚いサポートさらに、マネージャ視点から、
「開発効率の良い不安定なフレームワーク」
よりも
「開発効率の悪い安定なフレームワーク」
の方がマシという意見もあります。
後者の方が見積もりとスケジュールが立てやすいためです。
ただ、「開発効率の悪い安定なフレームワーク」は、
そのままずっと「開発効率の悪い」ままです。
(よほどのツールによるサポートが追加とかされない限り)
「開発効率の良い不安定なフレームワーク」はいずれ
「開発効率の良い安定なフレームワーク」になる可能性があります。
なので、単にWEBフレームワークの選定が振り出しに戻っただけで、
Teedaがとても優位なシード権を持っていることには変わりはないと思います。
多分、作り手も使い手も今が一番我慢のときかもしれません。
このトンネル抜ければ最高のフレームワークになっているかもしれません。
さて...Teedaのソース追い過ぎて脳みそがトロトロです...休みます。
