ABAP_to_the_Future

8
Business Object Processing Framework (BOPF)
IMPORTING et_data = lt_monster_header ).
LOOP AT lt_monster_header INTO ls_monster_header.
* Use the model to derive the transient values
lo_monster_model =
zcl_monster_model=>get_instance( ls_monster_headernumber
).
monster_
lo_monster_model->fill_header_derived_fields(
CHANGING cs_monster_header = ls_monster_header ).
* The combined structure is now full, so we pass it back to BOPF
DATA: ls_ref_to_data TYPE REF TO data.
GET REFERENCE OF ls_monster_header INTO ls_ref_to_data.
io_modify->update(
EXPORTING iv_node = is_ctx-node_key
iv_key = ls_monster_header-key
is_data = ls_ref_to_data ).
ENDLOOP. "Monsters being Queried
ENDMETHOD. "Execute
Listing 8.11 Executing a Determination
The wonderful thing is that you can test this straight away without having to create
a little test program or some such. This is because there is a dedicated BOPF
test transaction (/BOBP/TEST_UI) that shows the contents of business objects that
have been saved to the database and also automatically runs the determinations.
8.2.6 Disabling Certain Commands Using Validations
When designing applications, you often restrict what commands the user can see.
(In standard DYNPRO programming, this is done via PBO processing.) For example,
you would not want to allow a goods issue action on a delivery object that
has already been goods-issued, and you do not want to allow the HOWL command
for monsters with no heads.
In these cases, rather than having a button and showing an error when the user
presses it, it’s common to gray out or hide buttons the user is not currently
allowed to press. This can make things less confusing for the user: If there are six
logs they can look at, but five of them are blank, then you want to only display
the button to show the log that actually exists. Otherwise, the user has to click on
316