cancel
Showing results for 
Search instead for 
Did you mean: 

Question on refactoring context attributes

Former Member
0 Kudos

Hi all,

I notice in WDP abap, if we need to set a context node/attribute

we would need to do this in the code.


my_ele->set_attribute(
   exporting = 'ATTRIBUTE_NAME'
   value = 'NAME' ).

So if i need to rename my attribute name to some other names, i would need to look in my codes where i have specified 'ATTRIBUTE_NAME' and change it myself.

Is there any faster way to do this?

Thanks

Accepted Solutions (1)

Accepted Solutions (1)

ChrisPaine
Active Contributor
0 Kudos

The other option is to avoid using the named attribute setting routines. Instead update a context by extracting and setting all static attributes of the context and using a structure. This way if you change the context, at least the syntax check will fail if you try to reference a field of the structure using the wrong name.

Given how the static attributes of a context element are referenced/stored (as a structure) then this shouldn't be overly expensive in terms of processing time - it might even be faster! - Has anyone run any tests on this? Thomas?

I have to mention that this use of hard-coded non-checked attribute values is one of my pet hates of the Web Dynpro ABAP implementation. In WDJ it was possible to get around this by using the static class attributes of the generated classes - these had the attribute names as strings but if you typed them in wrong - boom syntax error. But I can't see anything similar in WDA. So I always code so that attributes are not referenced directly but through the structure that they are bound to.

Then your need to search the code for incorrect references disappears!

Good luck,

Chris

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

>I have to mention that this use of hard-coded non-checked attribute values is one of my pet hates of the Web Dynpro ABAP implementation.

This actually used to be worse in the early days of WDA (pre-sp10 of 7.0). There used to not even be constants generated for the context nodes. At least now we have that. There has been discussion around the generation of constants for the attributes for some time, but there is some debate (usability vs. performance).

>Instead update a context by extracting and setting all static attributes of the context and using a structure.

Depending upon the number of attributes in a structure this can lead to a bit more processing. I find that using GET_STATIC_ATTRIBUTES_REF can help with this. You are passing back a reference to the complete structure instead of copy of the data in the structure. In the end you get the syntax check you mention, but don't take the performance hit of the data copy on a wide structure.

Example of GET_STATIC_ATTRIBUTES_REF:

data lr_sel type ref to wd_this->element_selection_criteria.
  data lx_exception  type ref to cx_root.
  try.
      lr_sel ?= wd_context->get_child_node(
        name = wd_this->wdctx_selection_criteria )->get_element(
         )->get_static_attributes_ref( ).
      wd_context->get_child_node( name = wd_this->wdctx_bp
         )->bind_table( cl_nwdemo_lean_service_bp=>read_bp_header_by_name(
           i_last_name    =  lr_sel->lastname
           i_company_name =  lr_sel->company_name  ) ).
    catch cx_nwdemo_bp into lx_exception.
      wd_this->wd_get_api( )->get_message_manager(
         )->report_warning( message_text = lx_exception->get_text( ) ).
  endtry.

Answers (1)

Answers (1)

martin_voros
Active Contributor
0 Kudos

Hi,

I don't think there is a "smart" way of doing this. Refactoring of context in WD4A is always painful. In my opinion there is a huge space for SAP to introduce refactoring features into ABAP workbench. Just simple refactoring features like "extract method" would give developers a boost in productivity.

Cheers