So I've been developing WD4A for a while now. But the language still manages to surprise me occasionally.
To put it mildly, if I were to meet an SAP employee tomorrow and he/she where to explain to me that Web Dynpro was coded and designed without any sensible project management at all - I would believe them in an instant.
A minor example: Visibility.
You would think visibility is a simple proposition - something is visible or it isn't, right? But trying to recreate the thought processes going around SAP at that point in time I arrive at this:
---------------------------
Visibility - Screams for a boolean really.
Wait... ABAP doesn't believe in something as fundamental as real booleans. (More here: ABAP Keyword Documentation.)
Doesn't matter, lets use WDY_BOOLEAN instead, we don't care about wasting 16 bits where one would suffice - this isn't assembler after all.
Noooo, X and Blank is too simple, lets use a NUMC2 - so that we can have a hundred different types of visibility!
What values are you proposing?
'00 - Visibility.blank', '01 - Visibility.none', '02 - Visibility.visible'.
Sounds complicated...
Your're right - lets create a domain (WDUI_VISIBILITY) and lets hide blank from the users.
I have a better idea - why don't we permit both. But don't tell anyone!
Hey guys - so when we develop EHP6, how about we create a new ENUM with reshuffled values and use blank = 2 and none = 3. (Note: And of course use Integers and not NUMC.)
High Fives all around!
....
--------------------------
How else could you possibly arrive at this:
View Element Tab - Visibility is a 'boolean' - SAP Library - Web Dynpro for ABAP
All other UI Elements I know of - Visibility is of type NUMC2 (WDUI_VISIBILITY) - SAP Library - layout Category. Which has two values in its domain - none and visible! (Which happen to be 01 and 02 - which is weird enough as it is.)
But - when using coding - you can use blank!
Class: CL_WD_UIELEMENT
Public Section:
Line 15:
constants:
BEGIN OF E_VISIBLE,
BLANK TYPE WDY_UIE_LIBRARY_ENUM_TYPE VALUE '00', " Visibility.blank
NONE TYPE WDY_UIE_LIBRARY_ENUM_TYPE VALUE '01', " Visibility.none
VISIBLE TYPE WDY_UIE_LIBRARY_ENUM_TYPE VALUE '02', " Visibility.visible
END OF E_VISIBLE .
That's obviously not good enough so here it is - everything reshuffled:
Interface: IFUR_NW7
Interface Section:
Line 188:
constants VISIBILITY_ENUM type I value 0. "#EC NOTEXT
constants VISIBILITY_VISIBLE type I value 1. "#EC NOTEXT
constants VISIBILITY_BLANK type I value 2. "#EC NOTEXT
constants VISIBILITY_NONE type I value 3. "#EC NOTEXT
Ok ok - that is only mildly crazy. I can live with that. After all nobody seems to use those new visibility values...
But what drives me up the wall completely is this:
If I now bind the attribute 'visible' of any View Element in the View Designer to the Context I can bind it to an Attribute of type WDY_BOOLEAN. Or to an Attribute of type WDUI_VISIBILITY (NUMC2 will do). Why is that? Because some clever soul at SAP decided to code something like this:
* >> Property: Get UIELEMENT-VISIBILITY
if wd_link_to_action->ip_visible = abap_true.
ifur_nw7_link~visibility = wd_link_to_action->pl_visible.
elseif wd_link_to_action->bp_visible is bound.
get_attribute_internal( exporting i_binding = wd_link_to_action->bp_visible
importing e_value = _vis ).
case _vis.
when abap_true.
ifur_nw7_link~visibility = cl_wd_uielement=>e_visible-visible.
when abap_false.
ifur_nw7_link~visibility = cl_wd_uielement=>e_visible-none.
when cl_wd_uielement=>e_visible-none or cl_wd_uielement=>e_visible-visible
or c_visibility_blank.
ifur_nw7_link~visibility = _vis.
when others.
cx_wdr_adapter_exception=>raise_for(
textid = cx_wdr_adapter_exception=>unknown_value_for_property
adapter = me
p2 = _vis
p1 = 'visible' ). "#EC NOTEXT
endcase.
else.
ifur_nw7_link~visibility = wd_link_to_action->vl_visible.
endif.
* >> enumeration with custom coding CORE/VISIBILITY => VISIBILITY
* >> UCA CORE|UIELEMENT|VISIBILITY
For those of you that do not want to read code - basically we check if the attribute is boolean first. Then we check if it is of type NUMC2. (Oh yeah - notice how blank and none amount to exactly the same here.)
But sometimes, just sometimes that will not work. Why? Because some other soul (here is me getting into the sensible project management bit) has decided to code the following:
* >> Property: Get TIMED_TRIGGER-WD_VISIBLE
if wd_timed_trigger->ip_visible = abap_true.
mv_wd_visible = wd_timed_trigger->pl_visible.
elseif wd_timed_trigger->bp_visible is bound.
get_attribute_internal( exporting i_binding = wd_timed_trigger->bp_visible
importing e_value = mv_wd_visible ).
else.
mv_wd_visible = wd_timed_trigger->vl_visible.
endif.
So when reading the Context it will crash if the attribute is of type WDY_BOOLEAN. (MV_WD_VISIBLE is defined to be of type WDUI_VISIBILITY).
Both of these coding excerpts are from the implementation of if_nw7_view_element_adapter~set_content (or for those of you on older SAP Releases try
if_wdr_view_element_adapter~set_content). But they both do something slightly different.
Which means something very logical which I have to do for Tabs (visibility is boolean) might work for other UI Elements. But sometimes it will crash.
tl;dr; The visibility of a Web Dynpro UI Element can sometime be controlled using boolean context values. Sometimes doing exactly the same will cause a dump. Oh the insanity...
update: My first version had something about insane simians in it. As I did not want to be rude to SAP developers who - when actually spoken to - seem to be a nice bunch, I replaced those comments with something possibly more realistic.
