cancel
Showing results for 
Search instead for 
Did you mean: 

Why is wdDoModifyView not called?

Former Member
0 Kudos

I've run into a situation that is puzzling. Here's the scenario.

There is a window that contains a Main View and two other views (let's call them A and B). A or B is displayed depending on information set in the Main View. But there is a path from A to B also.

The sequence that is causing problems is this: The user sets data in the A View and initiates an OnAction. The OnAction sets some context variables and fires a plug to the Main View. The Main View sets some context data and fires the plug to show the B view.

At which point an exception is thrown because the B View's wdDoModifyView has never been called (there is some data that needs setting the first time the view is called).

If the user sets information in the Main view and intiates an OnAction which fires a plug for the B View wdDoModifyView is called. So what's the difference?

And how should this sequence (A->Main->B) be done?

Any help is greatly appreciated.

Lori <*>

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Lori,

It's quite hard to understand the reason, but just one guess: probably your navigation occurs at wrong phase (any onPlug events are not processed immediately but rather saved in some queue and processed at different phase, after onAction / onEvent processing completed).

Try to notify parent (A -> Main or B -> Main) via event (rather then plug). Keep all the rest as is (Main -> A, Main -> B communications).

Valery Silaev

EPAM Systems

http://www.NetWeaverTeam.com

Former Member
0 Kudos

Valery

At first the code did an event from A->Main and then fired a plug of Main->B. But that didn't work either.

A co-worker has the same type of user interaction (A->Main->B) and is firing plugs to do the work. So I changed to that sequence with no luck.

I'll look at sending an event from Main->B instead. Hopefully that will activate the wdDoModifyView.

Thanks for you help. Will let the list know what I find.

Lori <*>

Former Member
0 Kudos

Lori,

It is better to implement Child (A|B) -> Parent (Main) notifications via events, but for Parent (Main) -> Child (A|B) (what you plan to do now) use simple methods on Child.

VS

Former Member
0 Kudos

I'm still confused on this matter.

Main, A and B are all views. Main is always visible with A and B occupying the same cell. For one to show and not the other, Main fires a plug to the view desired. Any time Main fires the plug to A and/or B from an OnAction within itself the wdDoModifyView method for A and/or B gets called (I've check that this indeed happens).

But if the route is A (in an OnAction) fires a plug to Main which fires a plug to B; B's wdDoModifyView is not called.

The problem comes when B has yet to be viewed for the first time and the A->Main->B route is taken. Since wdDoModifyView never gets called the table filter and sorter don't get set. And when the items are referenced you (of course) get a NullPointerException.

Having A fire an event to Main which then fires a plug to B does not work either. That was the way it was orignally coded and it has the same problem - B's wdDoModifyView is never called.

Any ideas?

Lori <*>

Former Member
0 Kudos

Hi ,

Whats the lifespan property of these views.

Try this. Instead of making the view property as frame work controlled.. Make the lifespan property as when visible and try.

My guess is when u call from main, the view might be already available and hence no rendering was needed.. due to which wdDomodify was not called.

wdDOModifyView is not supposed to handling sorting etc., whihc is why Valery had suggested for eventing..

In case of eventing , we haev control over the events . .while in this , due to the phase model and due to lack of our complete understanding of it.. we might get issues like this..

I am not generalizing.. Thats only my opinion.

Regards

Bharathwaj

Former Member
0 Kudos

Hi,

As per WD phase model,

Dynamic UI Manipulation

In this phase, the wdDoModifyView() method is called for all views contained in the current view assembly. The view controller context can be considered stable at this point in processing. This means that the filling of the context with data for the display on the user interface is completed.

The following processes are not allowed in this phase:

· Calling outbound plugs

· Calling raise… methods of the Web Dynpro Message Managers (IWDMessageManager API)

SAP strongly recommends not to write data in the context of the wdDoModifyView() method. Also, the dynamic UI manipulation must not have any side effects

PLease also ensure the validity of the type of data.

wdDoModifyView willl be called definitely.Please post the code u have writteen

Reagrds

Bharathwaj

Former Member
0 Kudos

The code in wdDoModifyView sets the table sorter and filter. It requires access to the UI elements to accomplish its task. Here is the actual code


IContextElement contextEl = wdContext.currentContextElement();
if (firstTime) {
    IWDTable xTable = (IWDTable) view.getElement("XTable");
    TableSorter tableSorter =
        new TableSorter(xTable, wdThis.wdGetSortAction(), null);
    TableFilter tableFilter =
        new TableFilter(wdContext, xTable,
                        wdThis.wdGetFilterTableAction(),
                        wdThis.wdGetToggleFilterAction(),
                        "Filter On", "Filter Off");
    contextEl.setTableSorter(tableSorter);
    contextEl.setTableFilter(tableFilter);
}

Valery Silaev has suggest changing to using events rather than firing plugs. This needs further investigation.

Lori <*>

P.S. this code came from an SAP engineer.

Former Member
0 Kudos

Lori,

I'm not sure why the wdDoModifyView is not being called, but setting of data should not be done in this method. It should be put into the wdDoInit method.

Cindy