On the topic of visibility - which is your favourite constant?

[ChrisPaine]

Hello,

Seems lots of people think that visibility is a boolean. Whereas it is, in fact, a tri-state variable with: blank, none, and visible as possible values.

Now when you have something like this, it is always good to have a constant that you can use to define these value.

It seems to me that there are quite a few different places where these values are defined as public constants.

Which one should we be using?

wdyn_ui_visibility_blank etc from type group WDYN? (seems that there are quite a few good constants defined here. - but aren't type groups a depreciated coding practice?)

if_wdl_core=>visibility_blank etc from class if_wdl_core ??

And if I searched a bit I'm sure I'd find more. The domain has them as a fixed list - not that it makes it any easier.

The pseudo boolean constants ABAP_TRUE and ABAP_FALSE and ubiquitous - not so with WD constants.

In WD Java there was 1 reference against the class that defined the type. Some may say that because WD ABAP is more flexible in this case (allows pseudo booleans to be used for visibility) it is better, I'd probably disagree (in this case). I worry that without a single good reference point, there is risk of different components using the same values for different meanings.

Anyway - to sum up what is really more a rant than a question - what should we use?

Cheers,

Chris

[thomas_jung · Accepted solution]

Personally I don't like type groups for the very reason you mentioned. When available I always choose class constants (enumerators) over type groups.

For visibility I tend to use:

cl_wd_uielement=>e_visible

I then use the enumerated values:

cl_wd_uielement=>e_visible-none

cl_wd_uielement=>e_visible-blank

cl_wd_uielement=>e_visible-visible

[thomas_jung · Accepted solution]

Just on this subject. All UI elements have generated classes. For instance CL_WD_BUTTON for the Button UI element. In these generated classes you have attributes for all UI element properties and enumerated constants for all property values. I use CL_WD_UIELEMENT for visibility becuase that is the abstract UI Element class and Visibility is so common. However if doing anything more specific I use the enumerators of CL_WD_<UI ELEMENT>.

During the generation process, SAP also generated DDic Domains for the UI elemen property enumerators. They can be found in the DDic as domains with the name WDUI_<property name>. These can be useful if you need to read the possible values for a property at runtime or if you need to have a DDLB or Search Help with the allowed values.

[ChrisPaine · Accepted solution]

Thanks Thomas!

given that each UI element has one of these generated classes then it would happily follow that the best (my opinion - often wrong!) place to look for and refer to a definition of the constant would be the generated class.

It is however suprising that internal SAP code reviews allow the multi-definition of these constants in so many places! The problem is though, I guess, that the horse has already bolted from the stable - and it's just not fiesable to remove them now and centralise on a single constant store/approach.

Scooby-doo wavy dream scene moment

-

---

... a future where the syntax checker looks at the referenced constants in your code and compares them to a list of "not advised" references and suggests a more "standard" reference...

-

---

end Scooby-doo dream sequence

but in a more real now - I guess that I can add another recommendation to my coding standards guide...

Thanks again - especially for the more general clarification!

Chris

[RMueller-Cajar]

Hi Chris - just to be crazy - I would recommend the following constants:

IFUR_NW7=>VISIBILITY_VISIBILE = 1

IFUR_NW7=>VISIBILITY_BLANK   = 2

IFUR_NW7=>VISIBILITY_NONE    = 3

After all, why use something as sensible as blank = '00'?

[Former Member]

Really a good Point Chris. The replies for this thread will refresh the visibility concept to all the WD developers.