Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
ChrisPaine
Active Contributor

Woe, woe and thrice woe...

This all goes back to a session some months ago at SAP Mastering Technologies where Karin Tillotson did an excellent presentation about the ASUG UI Inf.... At the time I was irritated, annoyed frustrated by the presentation. The Council had some excellent points, but I felt that they perhaps misdirected. To add to my frustration, although Karin pointed out all the shortcomings that exist in SAP's offering, because of NDAs we weren't allowed to know what SAP had responded to any of this!

Recently Why I believe in the power of ASUG Influence Councils Part 2 - The ASUG UI Influence Council, I'd recommend you read it - it's a good summary and development of the presentation linked above. But for me, it just scratched an itch that I'd been harbouring since I saw the presentation.

That's not what Web Dynpro is for!

One of the main complaints that the Council raised was that Web Dynpro isn't flexible enough. Well - should it be? If I want to dig a hole in the ground I start with my pickaxe, and then when I've broken up the soil, I use my shovel to scoop it out. I don't try to strap on a sheet of metal on my pickaxe to try and turn it into a spade. Likewise, Web Dynpro is not the leatherman tool of web development. It is not designed to allow customer tweeking to the level that the Council was/is demanding. There are RIA Islands that do allow a certain amount of custom build, but if you want a completely custom interface - well Web Dynpro is not the tool! I don't think the UI Influence Council should be calling for changes to this framework! I think they should be (to use some terms that I deal with every day) be writing Functional Specifications - not Tech Specs. Tell us what is wanted, by all means, but please don't then specify the technology!

But Fair play - they have a point...

Their list of points when abstracted from the particular technology however, is right. (again, my opinion!) BSP is slowly being removed from the market, and without it we are loosing our ability to build UI's in SAP in simple, enhance-able HTML. I think that the introduction of an HTML5 Island for WD would go a long way to fixing this - but it's certainly not going to fix the desire for a totally flexible UI experience - and building a UI using only RIA Islands isn't going to deliver much of the potential benefits of the WD framework. You'd be better off using another tool. (In my opinion).

But they were wrong - sort of...

However, on one particular point, they were wrong. You can event from an F4 help in Web Dynpro. It's not at all obvious how to do it, but it is possible. I'm not sure that it would even be a good idea to follow this code pattern - and I would encourage SAP to listen to the UI Influence Council and come up with a simple way of doing the same thing.

Firing an event from an F4 help selection.

First off, create an event handler in your component controller:

method ON_VH_CLOSED .

do_update_on_f4_help( cl_wdr_value_help_handler=>m_context_element ).


endmethod. 

which would be called when the Value Help window is closed/selection made.

This passes the value of the context element selected to your method to do whatever logic you want.

now this method should be triggered by an event. So create an event also, I'll call it VH_WINDOW_CLOSED. Attach your event handler to this event.

Now in the WDDOINT, register this event listener

* register as value help listener

  data: lo_listener type ref to cl_wdr_component,
        lo_component_api type ref to if_wd_component,
        lo_component type  ref to if_wd_component.
  lo_component_api = wd_this->wd_get_api( ).
  lo_component = lo_component_api->get_component( ).
  lo_listener ?= lo_component.
  zpa_pa_empl_maintain_vh=>register_listener(
      listening_component = lo_listener ).
* add reference to handler
  lo_component->add_event_handler(
       listener_name = 'COMPONENTCONTROLLER'
       handler_name = 'ON_VH_CLOSED'
       controller_name = 'COMPONENTCONTROLLER'
       event_name = 'VH_WINDOW_CLOSED' ).

You can see here that I have made reference to a method register_listener of a custom ABAP class  zpa_pa_empl_maintain_vh.

Here there are three event handlers. I'll cover them each - but first the method we called... REGISTER_LISTENER

 method REGISTER_LISTENER.
  ao_component = listening_component.
  set handler handle_vh_close.
  set handler on_ddic_search..
endmethod.

It has one import parameter - LISTENING_COMPONENT TYPE REF TO CL_WDR_COMPONENT.

This is also the type of the static class attribute ao_component.

It activates the two event handlers.

Event Handler method HANDLE_VH_CLOSE - Is a handler for the event

Class:CL_WDR_VALUE_HELP_HANDLER Event:IF_WD_VALUE_HELP_FORWARD~VALUE_HELP_CLOSED

method HANDLE_VH_CLOSE.
* window is closing - register change of context element
set handler on_search_context_changed.
endmethod.

It just starts up another handler - one which we only want to be active for a very short time!

Event Handler ON_SEARCH_CONTEXT_CHANGED - is a handler for the event

Class:CL_WDR_CONTEXT_ELEMENT

Event:ON_ATTRIBUTE_CHANGED

method ON_SEARCH_CONTEXT_CHANGED.
* deactivate handler
  set handler on_search_context_changed activation abap_false.
   ao_component->fire_event(
               controller_name = 'COMPONENTCONTROLLER'
               event_name      = 'VH_WINDOW_CLOSED'  ).
endmethod. 

It firstly deactivates listening for context changes and then fires the event in our WD component. The event has many parameters, but we can ignore all of them.

Event Handler Method ON_DDIC_SEARCH - is a handler for the event

Class:CL_WDR_VALUE_HELP_HANDLER

Event:IF_WD_VALUE_HELP_FORWARD~DDIC

method on_ddic_search.
  cl_wdr_value_help_handler=>if_wd_value_help_forward~set_context(
         context_element = cl_wdr_value_help_handler=>m_context_element
         context_attribute = cl_wdr_value_help_handler=>m_attribute_info-name ).
endmethod.

This method ensures that the context of the value help is available to us when the value help window is called.

Finally, one last method DEREGISTER_LISTENER

 method deregister_listener.
  set handler handle_vh_close activation abap_false.
  set handler on_ddic_search activation abap_false.
endmethod.

Because you don't want to having these events occurring when you don't want them to!

To wrap up

So using this code you CAN cause an event to trigger on the use of a standard F4 value help. But you can see it's pretty complex! 

And Finally

I still feel that perhaps the Influence Council are possibly going down the wrong path trying to make Web Dynpro the be-all tool for web development in SAP. It isn't that, and I doubt it will ever be that! I've published this method of getting an event from an F4 value help as much for the desire to educate others about the possibility, as from a desire to show that the Council were wrong. Wrong to try to consider making large scale requests of a specific technology without understanding how that technology works (as demonstrated), and whether it had ever been designed to do the things that they were wanting it to do.

But don't get me wrong - the job these guys do is GREAT!  I just got a bit "woe is me" about it all 😉

These are all my own opinions, I've often been wrong in the past, and I'm sure that I'll be so in the future, please don't assume that these opinions in any way reflect that of my company.

14 Comments