i getting confused computation points, such before_header , after_header etc.
i have computation, needs take page item value, , return result.
the computation pl/sql function body below:
declare v_response varchar2(1500); begin if :p4_renewal_required = 'yes' v_response := 'according register, license renewal required maintain registration. please choose whether agree or disagree statement.'; else v_response:='forget it...'; end if; return v_response; end;
the page item :p4_renewal_required calculated field sql value, relies on database populated page item p4_renewal_not_required. turns yes no , no yes.
select (case when v('p4_renewal_not_required')='yes' 'no' else case when v('p4_renewal_not_required')='no' 'yes' else '??' end end) dual
my computation not return result. p4_renewal_required value 'yes' computation return 'forget it'. if go page edit view, , run page again - value shows correct value of
'according register, license renewal required maintain registration. please choose whether agree or disagree statement.'
this implies me computation operating on old session value of p4_renewal_required.
i not sure computation points have this, if have data being returned via fetch row process executing on after header, populating fields in regions such p4_renewal_not_required, , p4_renewal_required being calculated....how computation populate field in region has dependency on existing page items?
i have tried making computation execute before footer, before regions, after footer etc. nothing works.
i not sure how before footer works, or how page items populated in point, when of rendered server side.
for example if set computation calculate "after region" late use value in region regions have been rendered?
if need calculate value in computation use in region , use "before region" computation point, have page items need use been tied page items underlying query @ point or early.
any appreciated.
the "source used" should set "always" since want value reflect it's dependant value. when set "only when session state null" value fetched when session state empty. after first submit (or other method of setting value in session state, such computation) source no longer retrieved each time. this'll give impression value old.
as docs: it's transparent, confusion exists when values retrieved through fetch row process: process fetches values relevant items (source=database column) , keeps them in memory duration of render (an "in-memory session state"). these values used item's source, though values not kept in session state afterwards (=when render finishes). can verify checking session state after page has rendered: empty! know i've read somewhere, it's not detailed in docs on how "fetch row" works.
computations set value of items in session state, persistently. yes - can use them set value of item , has additional effect. "caused" problem here (in combination): deriving value in item source work fine, long session state not kept through submit. since computation used, source disregarded since "only when session state null" used.
performing computation on database column set session state though, in-memory session state , source type have overruled value. after render session state set through computation still persists. when submitting submitted values once again put in session state. so, that's weird situation. can weird though - try avoid it'll though logic through mess.
this give meaning different computation points. compute item after rendering has ended, , session state set. item have rendered value prior computation (if done after render, otherwise, depends on eg source) , have value persisted in session state. can't come example i've never had use situation though. personally, before , after region points don't mean me. before headers , after headers used points, , processing, sequential. use appropriate.
once again, in normal situations items derived through source settings: they'll behave normal , no persistance session state occur. processes (except "fetch"!) , computations make values persist in session state.
Comments
Post a Comment