Influence order of WDDOMODIFYVIEW methods

[roland_spindler]

Hello,

Is there a way to influence the order in which the WDDOMODIFYVIEW methods are called?

We have a view (let's call it SUPERVIEW) that contains a usage (of let's say SUBVIEW). Currently SUPERVIEW's WDDOMODIFYVIEW is always called before SUBVIEW's WDDOMODIFYVIEW.

However, in SUBVIEW we are determining values that should change the way SUPERVIEW is displayed. Therefore SUBVIEW's WDDOMODIFYVIEW should be called before SUPERVIEW's WDDOMODIFYVIEW.

Is this possible?

best regards

Roland

[thomas_jung · Accepted solution]

What exactly are you doing in the WDDOMODIFYVIEW methods that creates such a dependency? The method should only be used for dynamic rendering of the UI. Perhaps if there is logic that should fire to determine what gets rendered, it should be tied directly to the triggering action and not in the WDDOMODIFYVIEW. I'm not sure I would want to loop back up and render the super-view twice (and consequently all children views again). Not only could this lead to an endless loop if you aren't careful, but also is inefficient because it forces the phase model to run twice every time.

[roland_spindler · Accepted solution]

Hello,

Yes, that's how I finally decided to do it. The necessary decisions now happen directly after the user interaction and not at DOMODIFY.

best regards

Roland

[Former Member]

hi ,

in ur SUPERVIEW , make a global attribute of type WDY_BOOLEAN and set its value to ABAP_FALSE in WD DOINIT.

in WD DOMODIFY of ur Super view , put a IF condition b4 ur logic .

IF attribute value is ABAP_TRUE , thn execute the code in DOMODIFY of SUPER view ,

the control wud simply go to the DOMODIFY of SECONDVIEW , in that set the attribute value to ABAP_TRUE ,

nw after executing code in second view , the contrl wud go to SUPERVIEW's DOMODIFY .

this can help u

[roland_spindler]

Hello,

Why would SUPERVIEW's DOMODIFY be called again after SUBVIEW's DOMODIFY is finished? I suspect that it won't...

Roland

[Former Member]

thats fine , I only mean to say u , that is the way u can prevent the execution of DOMODIFY of ur SUPER view , using the logic discussed ,

whn u r in DOMODIFY of ur SUBVIEW , u can implement u r logic , whatever u wish to do

[roland_spindler]

Hello,

I'm not trying to prevent the execution of SUPERVIEW's DOMODIFY. I want to do different things depending on what happened in SUBVIEW's DOMODIFY.

Roland

[Former Member]

after u r done wid ur SUB view and make the attribute ABAP_TRUE therein ,

the control wud go to the modify of SUPER view , and wud execute ur piece of code , if u hv put the IF statement

IF attr EQ ABAP_TRUE

..

ur code..

ENDIF.

try once , and let me knw , if u need , hw is it gng !!

[roland_spindler]

No, it doesn't. This is the problem.

SUPERVIEW's DOMODIFY is always called before SUBVIEW's DOMODIFY.

Roland

[Former Member]

If after execution in SUB view, u r firing the plug back to the SUPER VIEW ,ry follwing these steps :

1 In comp controller make attribute attr of type WDY_BOOLEAN

2 In SUPERVIEW 's doinit wd_comp_controller->attr = ABAP_FALSE

3 In modify of SUPER view ,

IF wd_comp_controller->attr = ABAP_TRUE

...

ur piece of code .

ENDIF.

4 now in WD DOMODIFY Of sub view

..

ur code

wd_comp_controller->attr = ABAP_TRUE

..

thn it shud definitely execute ur piece of code in SUPER view