on 09-06-2013 3:59 PM
Hello everybody!
Currently using WebDynpro Java on NetWeaver 7.0, we need to perform one specific check on each roundtrip in every view in our WebDynpro component. If that check fails, we'll have to navigate to one specific view that is connected to every other view via plugs. Is there an easy way to accomplish this ? wdDoModifyView is not an option, since you cannot fire a plug from that method, so I'm looking for a method that is called on every roundtrip with the possibility to fire a view-specific plug in case my check fails.
Thanks
Michael
Hi Michael
Maybe try to create a dummy calculated attribute and use the getter/setter methods for your check logic.
those methods are called on every roundtrip as well (I'm not shure about the abillity to fire plugs in them).
Hope I'm helpfull
Shai.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Sharath!
Thanks for your hint. In the component controller, I created an event that is fired inside the doBeforeNavigation() method whenever my conditions are met. Then I created an event handler for this event in (almost) every view and fire the view specific outbound plug inside that handler.
Unfortunately, when the event gets fired (and it does, on every roundtrip, which is great), the event handler in one specific view (always the same) tries to handle the event and fire its very own view specific outbound plug. This results in an exception
com.sap.tc.webdynpro.services.exceptions.WDRuntimeException: Cannot navigate
from view <AlwaysTheSameView> because it is not part of the current view
assembly
So, I'd need to fire specific events from the component controller depending on the current view. Is there any way to accomplish that or even to know which view my user uses at that time?
Thanks
Michael
Hi Sharath!
The conditions are always the same, so I can check them in the component controller. But when I'm in view1, I have to fire a plug that navigates to view5, and when I'm in view2, I'll have to fire a plug that navigates to view4.
When I fire the event in the component controller, it seems it gets handled by a single handler in one of my view controllers and not by the handler in the controller of the current view, so when I'm in view2, the event gets handled by view1 anyway. In the handler When I try to fire an outboud plug from view1, although this is not in the current viewset, I get the exception mentioned above.
So it seems that I have to raise different events depending on the current view. Any ideas on that ?
Thanks
Michael
Try to pass some parameter(if possible with the event) or set some value in the context when the event is triggered.
Then, in the handler check for the value stored in context(may be string) or the parameter value(if you are able to pass it) and take an appropriate action.
I must admit the navigation concept seems a little complex. If possible try to find an alternative.
All the best.
Regards,
Sharath
Hi Sharath!
Thanks for your suggestions. But in any solution I can come up with (at least to my current knowledge), I'd have to know which view is the one that is currently being displayed to the user. If there would be a standard way to find that out inside the component controller, that would be great. Otherwise, I'd have to find out if a view is being displayed inside that view and write that into some context, but so far I was not able to find out which method inside a view controller would be executed whenever that view is displayed (brought on top in the z-order, to put it into a fat client wording). wdDoInit does not help me, as this method is called on initialization of the view (depending on the view lifecycle this might be only once and not every time the view is being displayed).
Thanks
Michael
The navigation discipline in web dynpro is called - Phase Model.
Refer the link to understand the methods and sequence in which they are invoked by WDF.
http://help.sap.com/saphelp_nw04s/helpdata/en/d2/8acd409cc4dd50e10000000a1550b0/content.htm
Regards,
Sharath
Hi Sharath!
Yes, I'm aware of the phase model and it's implications. But I still cannot find a method that is called on every roundtrip where I'm allowed to fire outbound plugs with the knowledge of the view that is currently displayed to the user.
wdDoModifyView would be great, but I cannot fire outbound plugs from there. wdDoBeforeNavigation (or maybe wdDoBeforeAction) would be great, but I do not know how to find out which is the current view, so I do not know which plug I'd have to fire.
So I'd have to find out a way retrieve the information which view is currently being displayed inside a method of the component controller. Right now, I can only think of setting some variable like "currentViewId" inside the component controllers context that is being modified to the current views name (or whatever) from inside wdDoModifyView in the view controller, but it seems to me that there should be some way involving less developer action. Do you know of any method or property in the component controller that gives me the information, which view is the current view ?
Thanks
Michael
Try This:
Set the Lifespan of view to "when_visible".
The WDF handles view with this setting as follows:
Lifespan = When visible: When the view disappears from the view compostion based on a navigation step the Web Dynpro Runtime automatically destroys the view controller. When the view afterwards reappears in the view assembly a new view controller instance is created and the wdDoInit() hook method is called by the Web Dynpro Runtime again.
Then, maybe you have to manually create the steps to call the view - for which refer to docu when view lifespan is set to "when_visible".
Then, (MAY BE) get to find if the view is visible ( MAY BE ) and decide which plug to invoke.
Its a MAY BE solution, which you can try it.
Regards,
Sharath
Also came across some text related to when_visible propety:
when a view's lifespan is set to "when visible" & when the view becomes invisible (via user navigation, for example) then "wdDoExit()" is called. The view controller and its attributes and the local view context are deleted. Also the UI element tree for that view is deleted as well.
Try to use this info, too.
Regards,
Sharath
Hi Sharath!
Yes, I was thinking about that, too, but discarded that since I'd be forced to reload lots of data when returning to a view that was opened previously (with load times up to two minutes) . So currently, I'll try to keep track of the view use in the component controller context...
Thanks
Michael
User | Count |
---|---|
87 | |
10 | |
10 | |
10 | |
7 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.