Navigation History in WebDynpro

[Former Member]

Hi all,

I was wondering if WebDynpro supports navigation hisotry that is similiar to that of IE or Netscape navigation history.

My objective is to reuse the standard components, if any, to mimic the "BACK" and "FORWARD" navigation in the webdynpro through the cache(History Object) of client browser as WebDynpro disables the client browser navigational actions;

Any help will be appreciated.

Thanks,

Paul

[Former Member]

You can use the wdportalnavigation API to navigate across iviews.

Look at the navigateRelative method and the levelsUp parameter to replicate this functionality.

This is portal only, however...

[Former Member]

Yeah.. I am looking for WebDynpro specific solution as my client might just deploy the app without the portal framework. I guess that's the tricky part. Thanks for the response tho.

[Former Member]

Hi Paul,

hmmm, that's tricky indeed. What you would need is something like a plug firing tracker (e.g. some kind of "service" registering the plugs fired by views and interface views on a stack for example). Since Web Dynpro never "leaves" the URL of an application, this kind of navigation is the only way to mimic BACK and FORWARD.

Problem #1 is that you can't get the plugs from the view/interface view controllers without leaving the holy tracks of API usage, there's no getXXXPlug method, you can only fire them.

Problem #2 is, even if you insist in doing this, each navigation link must be bidirectional (e.g. for each link from an out- to an inbound plug there has to be a corresponding link in the reverse direction available), so that you can "return" from a navigation link target back to it's sender. Well, this is also not really true, if you leave API's ground.

Problem #3 is, that the "state" in terms of context data might have been changed by a target's view logic, returning to the sender will not restore it. This conflicts with the "classical" BACK and is the biggest bite.

As a conclusion i would say, it's possible, but the effort might be tremendous and might be a starting point for a content suggestion. Maybe i'd take the challenge, sounds promising (even if i already hear some grumbling arising ;).

Regards

Stefan

[Former Member]

> Problem #1 is that you can't get the plugs from the

> view/interface view controllers without leaving the

> holy tracks of API usage, there's no getXXXPlug

> method, you can only fire them.

>

> Problem #2 is, even if you insist in doing this, each

> navigation link must be bidirectional (e.g. for each

> link from an out- to an inbound plug there has to be

> a corresponding link in the reverse direction

> available), so that you can "return" from a

> navigation link target back to it's sender. Well,

> this is also not really true, if you leave API's

> ground.

A better solution might be to define a generic method navigateToView( viewName ) that will automatically create inbound and outbound plugs through the IWDAbstractViewInfo object. ( using createOutboundplug / findInOutboundPlugs ). This way, all the views will be guaranteed to be bidirectional, and it would be a matter of storing the name of the created plugs in the stack.

> Problem #3 is, that the "state" in terms of context

> data might have been changed by a target's view

> logic, returning to the sender will not restore it.

> This conflicts with the "classical" BACK and is the

> biggest bite.

>

This is the biggie. A possible solution will be to serialize the context node, but even then you wouldn't be able to guarantee that all the mapped context nodes are restored to the previous state.

[Former Member]

Hi Stefan,

Thanks for the tips and concurrence.

I was hoping some magician might have found a loophole in the WebDynpro to accomplish the task that I had outlined.

Regardless, you have filled me in with some of the missing links.

Thanks,

Paul

[Former Member]

Thanks for the tips Tomas. That's a cool idea.