*Introduction* I've experienced many times the situation when users were absolutely 100% sure that some value (for example, tax code) will never ever change, not in a million years, for some functionality that I was doing development on. I believed them and hardcoded it, since it was the easiest and fastest way. And later, when the program got to final development phase, or even productive, they remembered an exception which got me in trouble. I had to change the code. Although at first glance a trivial problem, it caused me a lot of frustration and headaches. I'll describe here a component which enables storing and editing fixed (constant or rarely changed) values in programs or program parts. It's object-oriented, and works in a flexible way, with no need to create additional dictionary components. *Unload your burden to users* My experience is that a developer must always avoid responsibility for data in program, even if the user is absolutely sure that some value wouldn't change. You must never trust this. It's better to always let the users decide in program runtime and be fully responsible, so that they can't bother you later. You should parameterize as many values as you can. And if they're really not expected to change, place a tiny command button somewhere aside, where it doesn't distract the users in daily work. Classical options to do this require a lot of application-specific coding and/or creating dictionary objects for each application or application part. You'll have to maintain and transport those objects. These are pretty time-consuming and inflexible solutions. It's also boring and frustrating work and you'll always be tempted to hardcode. *What to do with fixed values in program?* It's not always easy to decide what to do with rarely changed, constant and "constant" values in your programs. What are the options? 0.1. 0.2. hardcoding: no doubt the worst possible solution 0.3. selection-screen parameters: The worst thing is that selection-screen variables are global for the program. They don't really fit to the objects world, the code becomes hard to maintain and it's easy to get lost when it becomes big. Besides, users will hate you if they’ll have to enter the values each time they start the program, which you can overcome by PID parameters. However, it would mean another set of DDIC components to maintain. 0.4. Z tables: a generic Z* parameters storage would not be bad, but a simple and intuitive UI must be built - coding effort 0.5. generic storage (such as INDX table): also a good option, but requires coding effort *The component to wrap INDX table* My goal was to create a flexible and simple reusable component which would require as little as possible Z* DDIC components specific for application. I decided to use the special table: INDX, where you can store and retrieve all types of data - simple variables, internal tables... There are even special ABAP statements for this purpose: 0.1. 0.2. EXPORT obj1 ... objn TO DATABASE dbtab(ar) ID key. 0.3. 0.4. IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key. 0.5. I abstracted the table and all the coding within (at least 2) little dictionary classes: 0.1. 0.2. ZCL_PROG_PARAMS - an abstract class which handles data maintenance in db 0.3. 0.4. ZCL_PROG_PARAMS_* - subclasses which implement UI - my only implementation so far is with ALV grid 0.5. I abstracted data maintenance from user interface to enable access to the same data by different technologies. Like this: 
*Usage* Usage is simple. You only have to initialize the component with a unique database key (for INDX table), and name the parameters that user needs to maintain. There are two ways to define the parameter's description: 0.1. 0.2. by reference to a dictionary domain 0.3. by freely entered text A simple foreign key check against a check table is also possible. Unfortunately, I wasn't able to attach specific search help to each cell. It works like this: * initialize parameters "country CLEAR s_parameters. s_parameters-par_name = 'COUNTRY'. s_parameters-domain = 'LAND1_GP'. s_parameters-checktable = 'T005'. s_parameters-checkfield = 'LAND1'. APPEND s_parameters TO t_parameters. "company code CLEAR s_parameters. s_parameters-par_name = 'COMP_CODE'. s_parameters-domain = 'BUKRS'. s_parameters-checktable = 'T001'. s_parameters-checkfield = 'BUKRS'. APPEND s_parameters TO t_parameters. "some custom named parameter CLEAR s_parameters. s_parameters-par_name = 'DUMMY'. s_parameters-description = 'Freely entered name'. APPEND s_parameters TO t_parameters. * create object CREATE OBJECT o_pars EXPORTING i_id = 'SOME_UNIQUE_KEY' it_parameters = t_parameters i_title = 'Title'. It's very easy to get values into your program. Just one statement: v_comp_code = o_pars->get_value( 'COMP_CODE' ). You start the UI (editor) with a single statement too: CALL METHOD o_pars->edit. and it results with: 
If user enters invalid value and tries to save, the foreign key check issues an error message: 
Another expected functionality: if value changes and user tries to close, an options dialog pops up: 
*Usage* Usage is simple. You only have to initialize the component with a unique database key (for INDX table), and name the parameters that user needs to maintain. There are two ways to define the parameter's description: 0.1. 0.2. by reference to a dictionary domain 0.3. by freely entered text A simple foreign key check against a check table is also possible. Unfortunately, I wasn't able to attach specific search help to each cell. It works like this: * initialize parameters "country CLEAR s_parameters. s_parameters-par_name = 'COUNTRY'. s_parameters-domain = 'LAND1_GP'. s_parameters-checktable = 'T005'. s_parameters-checkfield = 'LAND1'. APPEND s_parameters TO t_parameters. "company code CLEAR s_parameters. s_parameters-par_name = 'COMP_CODE'. s_parameters-domain = 'BUKRS'. s_parameters-checktable = 'T001'. s_parameters-checkfield = 'BUKRS'. APPEND s_parameters TO t_parameters. "some custom named parameter CLEAR s_parameters. s_parameters-par_name = 'DUMMY'. s_parameters-description = 'Freely entered name'. APPEND s_parameters TO t_parameters. * create object CREATE OBJECT o_pars EXPORTING i_id = 'SOME_UNIQUE_KEY' it_parameters = t_parameters i_title = 'Title'. It's very easy to get values into your program. Just one statement: v_comp_code = o_pars->get_value( 'COMP_CODE' ). You start the UI (editor) with a single statement too: CALL METHOD o_pars->edit. and it results with: If user enters invalid value and tries to save, the foreign key check issues an error message: Another expected functionality: if value changes and user tries to close, an options dialog pops up:
12 Comments
Bluesky
