上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

怪奇現象… [2008/10/28 (火)]

昔のホラー映画でなんかテレビに悪霊がいてって話があったけど、うちのPCも最近やたらと怪奇現象が多い。どうもこれにも悪霊が取り憑いたっぽい…。そう、うちのPCでは悪魔の言葉とおぼしき意味不明の文章がログにたまるは、血で綴られたような赤いエラーメッセージが出るは、独りでにプログラムが停止するは…。そのうち本人もバグの階段を…
┌(。ρ。┌ )┐三三三   …て感じで降りていくに違いない。(ネタ古過ぎ…)

さてさて、映画ではエクソシストが悪霊を退治してくれるらしいけども、現実エクソシストと思って頼ったフレームワーク(JSF)が悪霊以上に凶悪な気がするこの頃。…いや、でも実はそれは、おいらが既にアンチパターンに取り憑かれていて…だからエクソシストが憎いのか(恐)!…そんな感じの今日のネタ…。(つまり、簡単すぎてJSFが間違ってるとも思えない…何かおいらに見落としがあるに違いないって事(爆!!))

まず、コンバータを設定したValueExpressionを参照する入力コンポーネントを用意。それに空の文字列を入力、そして他のコンポーネントにValidationフェーズで検証エラーの起きる値を入力してサブミット。すると空の文字列を入力したはずなのに…ValueExpressionの値が優先されて元に戻っちゃう…。


<h:form>
    <-- 検証エラーをおこすために何も入力しない -->
    <h:inputText id="required" required="#{true}"/>
    <h:message for="required"/>
    <-- 空文字を入力しても元の値に戻る -->
    <h:inputText id="hasInitial" value="#{testBean.value}">
        <f:convertNumber integerOnly="true"/>
    </h:inputText>
    <h:message for="hasInitial"/>
    <h:commandButton/>
</h:form>

どうもコンバータがnullを返して、それがlocalValueとして設定されて、最後のgetValue()がJavaDocによると、localValueがnullならValueExpressionを使うって書いてあるので、たぶんこれだ…。うーん、isLocalValueSetとかで切り分けてくれると思ってたんだけど…違うみたい。

上記の現象の画像による説明

うーん、、、単純なんだけど汎用的な解決策が見つからない…。JSFの欠陥?なわけないよな…こんな単純な所で…。とするとおいらの理解が足りてないって事か…うーん。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

スポンサーサイト

前回に続きJSFと格闘中。ASP.Netで出来た事がJSFでクールに出来ない…。やるせないのでメモ。

おいらはASP.Netを使っていた時はUIコンポーネント(.Netでは確かコントロールとか言ってた)同士を連携させるまとめ役のUIコンポーネントを作って楽する手がお気に入りだった。で、ただコンポーネント同士をまとめるのでなく、あるコンポーネントに設定された値に基づき他のコンポーネントの値を調整するといった、やや混みいった事をしてた。

例えば、エンドユーザにラジオボタン等で幾つか代表的な候補を示し、それ以外の値を入力したい場合のみ最後のラジオボタンを選びその隣の入力コンポーネントにカスタム値を入力してもらう。カスタム値を入力するコンポーネントは子コンポーネントとして記述できるようにし、内容に応じて種類を変えられるようにする。そしてプログラムから入力された値を取り出す時はただの単一値入力コンポーネントと同様に扱えるようにしておく。名づけて"UISelectOrCustom"!うん、我ながらいいネーミング!

このUISelectOrCustomを実装する場合、モデル側からカスタム入力でしかあり得ない値を取得したらば、それを子コンポーネントにも設定しないといけない。すると問題になるのはJSFのUnifiedELの遅延評価式の存在とその評価タイミング。標準のUIコンポーネントの実装方法に倣うなら遅延評価のタイミングはRender Responseフェーズにおける描画時になる。となるとそこで取得した値を子コンポーネントに伝えるタイミングもRender Responseフェーズの描画時になる。

ここが問題になる。てのは、まずRender Responseフェーズでコンポーネントの木構造を書き換えるとクライアントIDの関係が崩れる。そのためJSFではこれは反則になっている。だから設定を受けてコンポーネントの木構造が書き換わるようなコンポーネントは取り扱えなくなる。また、保存する状態の取得は描画前にやっておくので、描画時に子コンポーネントの値を再設定されるとValueChangeEvent等がおかしな事になるし、保存前の状態を前提とするコンポーネント(標準のコンポーネントではないけど)も取り扱えなくなる。つまり、そんなこんなでRender Responseフェーズでコンポーネントに手を加えるのは禁止されていたり危険だったりでチキン野郎のおいらには到底出来ない…。

で、ASP.Netでこれが出来たような気がする理由はそもそも遅延評価ってのが無かったような覚えがある。データバインドにしろ何にしろどっかのタイミングではいドーン!って感じで設定される。だからレンダリング前に値は確定させれるし、それがASP.Netは普通なわけで…。おかげでまぁユーザコントロールやカスタムコントロールは気軽にほいほい作れる。

う~ん、、、せめてJSFが描画前に全ての値を確定するフェーズをデフォルトで用意して、値の確定はそこでやるのを標準にしてくれてればいいのだけど、そんなのは無い…。ま、JSFでも解決策は無くはないような気もするんだけど→追記を参照、なんかトリッキーな手のような気がして自分に自身が持てない。なので遅延評価はいいんだけど…この件についてはASP.Netに一票…。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

続きを読む »

う~こんにゃくゼリーが発売中止になってしまった…。アル中で頻繁に死ぬ酒はOKで、滅多に死なないこんにゃくゼリーがNGとは…意味が分からない。…梅味が好きだったのに。


さてさて元々は画像処理系と最適化系がメインだったおいらだけど…何かこのブログWeb系のネタばかりだ…。うぅ一度会社でASP.Netとやらを触って、自分のビジネスでもJSFとやらを触るはめになって、、、Webに取り憑かれたかのような今日この頃…。

何はともあれそういう紆余曲折で、JSFとASP.Net二つやって、ふと思った事があるので書いておく。(ASP.Net2.0以降は知らない)

てのは、両方とも状態の保存がコンポーネントだけってのが初学者の変なスタイルを助長してる気がする。てのは、View-Controler部分(コンポーネント)と違いModel部分はそのままでは状態として保存されない。仕方ないので、本来Modelで独立して管理すべき値が次第にView-Controler部分に埋め込まれるようになっていく。普通Model部分が他に移るのは異常な違和感があるので、初学者でも勘のいい人は何かおかしい事に気づく。けど、Modelを別個に保存させる方法を知らないので、それしか道はない。結果、本来Modelの管理する値がView-Controler部分に混ぜ込まれ複雑に絡み合う事になる。JSFにしろASP.NetにしろUIコンポーネントがその重要な要素でUIコンポーネントは特にWebにおけるMVCにおいてレガシーなそれよりもVとCの連携を強化してくれる…はずなんだけど…そもそもそうした使い方をされるとMVCですらなくなってしまう。
ASP.Netを始めたばかりの先輩プログラマが.NetでないASPで組んでた時の方がうまくいってた…と愚痴っていた。その時ははぃ?新しくなって駄目になったの?そんなマンナンライフと思ったけど背景にはこうした部分があるのかも…と思うこの頃。

なお、モデル部分を保存しようとしたらASP.NetならViewStateに、JSFなら保存したいBeanをリクエストスコープにしてマーカアノテーションを付け、それを自作のStateManagerで処理しダミーのコンポーネントに混ぜて保存するといい。ま、どっちにしろ何でこんなんせなあかんの感は否めない…。
ちなみにJSP+JSFに比べてASP.Netの場合、MVCを実践しようとするとコンポーネントとModelの値の連結を毎回やるはめになったと思う(おいらの記憶と理解度では)のでMVCの完成度ではJSFに一票かな…。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

続きを読む »

ありがたやな警告 [2008/10/05 (日)]

どうも最近、既存の製品におぃ!と突っ込みたくなるような事ばかりだったんだけど…、今日は逆に感謝したくなる警告を出してもらったのでメモ。というのはJSFの実装のSunのRIなんだけど、メッセージをFacesContextに放り込んだはいいんだけど、JSPやらで出力する際に出力場所書くの忘れてて、結局メッセージの出番無し…というミスをした。すると、なんとメッセージがほったらかしになってますよ~という旨のログが!以下抜粋

sourceId=j_id_id19:description[severity=(ERROR 2), summary=(j_id_id19:description: 未入力です。), detail=(j_id_id19:description: 未入力です。)];|警告: 1 つ以上の FacesMessage が待ち行列に入れられていますが、まだ表示されていない可能性があります。

おぉぉぉ!ありがたやぁ~!!ありがたやぁ~!!おかげさまですぐ気づけたよ。

こういう配慮は本当に助かるんだけど、、、作る側(Sun)としては面倒このうえないと思う。いや、これ一つだったらいいんだけどユーザが凡ミスしそうなところってのは何十箇所とあるはず。おいらみたいな輩が同じ事をしようとすると、エラー処理に埋もれて処理の本筋が見えないプログラムになるかもしれない…。う~ん、さすがだ。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

Copyright © ふらふら技術者の日記 All Rights Reserved.
Powered by FC2 Blog
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。