ABAP Web Dynpro: Practical Tips
In this blog I will exchange my experience in the Web Dynpro for ABAP technology. The blog content will be extanded gradually…
Web Dynpro View
Dynamic Modification of View Elements Properties
Issue
The view elements are designed as ready for input (editable). There is a request to make view elements non-editable all at once.
A solution for this problem can be achieved in the view method WDDOMODIFYVIEW.
Solution
The method WDDOMODIFYVIEW receives two parameters: FIRST_TIME and VIEW. The view instance VIEW provides the access to all view elements. As the view elements are different of the type (Input Fields, Drop Down, Buttons etc.) we need to create right references to each of them.
Code
METHOD wddomodifyview.
DATA:
lo_view TYPE REF TO cl_wdr_view,
lo_input_field TYPE REF TO cl_wd_abstract_input_field,
lo_drop_down TYPE REF TO cl_wd_abstract_dropdown,
lo_button TYPE REF TO cl_wd_abstract_button,
ltbl_view_elements TYPE wdr_element_tab.
FIELD-SYMBOLS <lfs_view_element> LIKE LINE OF ltbl_view_elements.
IF ( first_time = abap_true ).
* The own method WD_THIS->GET_VIEW_STATE( ) delivers the state of view (CREATE, CHANGE, SHOW)
* The state values (CREATE, CHANGE, SHOW) are defined in the assistant class
IF ( wd_this->get_view_state( ) = wd_assist->con_view_state–show ).
lo_view ?= view.
* Get all view elements
ltbl_view_elements = lo_view->get_elements( ). ” this method is available within SAP system depending on its version and release level
* Loop the view elements and set theirs properties (here read only and enabled)
LOOP AT ltbl_view_elements ASSIGNING <lfs_view_element>.
* Abstract Input Field
TRY.
lo_input_field ?= <lfs_view_element>–view_element.
lo_input_field->set_read_only( abap_true ).
CONTINUE.
CATCH cx_sy_move_cast_error .
ENDTRY.
* Abstract Drop Down List
TRY.
lo_drop_down ?= <lfs_view_element>–view_element.
lo_drop_down->set_read_only( abap_true ).
CONTINUE.
CATCH cx_sy_move_cast_error .
ENDTRY.
* Abstract Button
TRY.
lo_button ?= <lfs_view_element>–view_element.
lo_button->set_enabled( abap_false ).
CONTINUE.
CATCH cx_sy_move_cast_error .
ENDTRY.
ENDLOOP.
ENDIF.
ENDIF.
ENDMETHOD.
Hello,
thank you for sharing your idea which might help somebody else.
I'm not that deep in Web Dynpro ABAP, but I think there must exist a better way to find out which type of view element you've got than using a try/catch block.
How about the interface IF_WDR_TYPE_ID?
I have no system to test it, but shouldn't the following work?
IF <lfs_view_element>-view_element->m_type_id EQ cl_wd_input_field=>cid_input_field.lo_input_field ?= <lfs_view_element>-view_element.
lo_input_field->set_read_only( abap_true ).
ENDIF.
Have a nice day,
Bernd
Hello Bernd André,
thank you for your comment and your idea.
It's possible indeed that we first check the type of a view element. For that reason is the attribute M_TYPE_ID of the interface IF_WDR_TYPE_ID responsible. Each view element class implemented the interface IF_WDR_TYPE_ID has the alias _CID for this attribute. We can check the type of each view element instance with their constance like CL_WD_INPUT_FIELD=>CID_INPUT_FIELD or CL_WD_BUTTON=>CID_BUTTON etc.
Example (like coding of you)
CASE <lfs_view_element>-view_element->_cid.
WHEN cl_wd_input_field=>cid_input_field.
lo_input_field ?= <lfs_view_element>-view_element.
lo_input_field->set_read_only( abap_true ).
WHEN cl_wd_button=>cid_button.
lo_button ?= <lfs_view_element>-view_element.
lo_button->set_enabled( abap_false ).
ENDCASE.
Best regards,
Andreas
Hi,
while this most certainly will work, please note that this is rather a quick and dirty solution. If you have any context binding for the corresponding properties of your UI elements, they will be overridden with this statement, making you Web Dynpro component harder to maintain.
If you think of the different combinations with editable/ read-only fields, you'll come up with a clean concept for context binding of your fields.
Best reagrds
Ole
Hi,
after eight years of practical work with Web Dynpro for Java, I have to totally agree with you, Jan-Ole, because I think the main aspects of this are the same in ABAP and Java.
It's sometimes a lot of work if you have to bind a huge set of UI elements to the context, but it is the recommended way. One major reason for this besides the ability to maintain the component is the performance which is stated to be better with less coding in wdDoModifyView and more static UI definition.
But in the manner of this blog, I think the main intention is to show that there is a way to dynamically modify view element properties. Additionally, you can even create and put together the whole content of the view in wdDoModifyView - that is really good to know, but it is also essential to know that it is not the recommended way.
Maybe Andreas can add a sentence to his blog post that his solution is only exemplary and not meant for an integration into a productive application.
Best regards,
Bernd
Hello Jan-Ole,
thank you very much for your comment.
@Bernd André
Thanks you also for your reply. Indeed my intention of this example was to show how to modify dynamically UI element properties.
Nenotheless this solution could be used in a productive application in the following cases:
- For instance each of UI elements has a separate static binding to the context attribute (for the property read-only). There is but necessity to lock all view fields for the edit at once ( e.g. because of an exception).
- Or if UI element properties haven´t conceptually context bindings at the design time. In that case it is the only way with this solution to set all view fields as non-editable.
This solution is to use thus rather for exceptions in an application.
Best Regards
Andreas
Good info, thanks!