SAP FPM Form Repeater UIBB dynamic programming.

[maltesh0188]

Hi Experts,

I want to know how to change the form repeaters input fields length/Data type in form repeater UIBB dynamically. I have came across ET_FIELD_DESCRIPTION exporting parameter in form repeater interface-GET_DEFINITION method. In this exporting table there is a column called field length. I tried creating technical field in CT_DATA(within UI structure) and mapped the field name in GET_DEFINITION. And filled data for the column in GET_DATA. But the length is not reflecting in UI.

Am I missing something or some steps...!?

There was an another field called READ_ONLY_REF this worked perfectly fine for me.

System in use:

Component	Release	SP-Level
SAP_APPL	606	0010

Thanks In Advance...

Please let me know I you need further details on this.

[jens_boeckenhauer]

Hi,

you can use the field LENGTH_REF in the field description to declare another (technical) field as dynamic length reference. However, this does only define how many characters or digits can be entered by the user. As it is the underlying UX principle of the Form GL2 and Form Repeater, the visible field length is purely defined by column fit in the configuration and cannot be dynamically changed - unless you use completely dynamic configurations, IF_FPM_GUIBB_DYNAMIC_CONFIG with NW 7.40.

Regards

Jens

[maltesh0188]

Hi

I Tried using Length_Ref Field, Here are the steps I followed,

In get_definition I added the line to et_field_description with name as my input field name(available in ct_data), length_ref = 'FIELD_LENGTH'. and changed the structure of CT_DATA by adding additional column called 'FIELD_LENGTH'. and i have filled value for this column in CT_DATA but I really didn't see any changes in the UI.

Problem with the using IF_FPM_GUIBB_DYNAMIC_CONFIG is I can only define the form repeater attributes once in get_default_config. But I cant again modify the elements on the form.

My req. is something like below image.

My UI after getting the parameters list i looks something like this.

Parameter name and the parameter value fields.

So here I want to make this length dynamic. And F4 also. ( I have one more column in CT_DATA which tells what should be the type of the param_value. I want to use this column as ref. (like length_ref) is this is possible?

[jens_boeckenhauer]

Hi,

as I wrote: The visible length cannot be changed via LENGTH_REF. But you may observe that, if you put the field length to 3,5,8 (for example) for the reference field in the rows of CT_DATA, you should only be able to enter ABC, ABCDE, ABCDEFGH for the repeated field on the UI.

The F4 help cannot be changed dynamically. But maybe you can use the following trick: Use a DDIC structure as field catalog and assign a value help which is context sensitive i.e. has a second import parameter pointing to another field of the structure. If you fill such a context field differently in the rows of CT_DATA, your value help can behave differently for each repeated form.

Regards

Jens

[maltesh0188]

No I don't think I can consider an DDIC Structure for this. As my parameters list is the set of values in extracted form BO in the name and value pair. And as you can see add&remove line actions next to the input filed will actually add more parameters(basically same param name but one more diff. value) and I need to buffer them in CT_DATA or my be locally and later I want to call the modify of BO to update new parameters list in the BOPF.(includes adding new param name & value, & modifying existing Entries).

And No having that Lenth_Ref additional technical field has no effect.

Attaching the snapshot of debugger where it accepted value with length equal to length of the PARAM_VALUE column length.

I know it is bit complicated....

[jens_boeckenhauer]

If the field length via reference does not have the impact I described before this is a bug - please create a ticket for this.

About dynamic (row-dependent) F4: If you do not want to define your field catalog via DDIC you can alternatively use OVS by means of IF_FPM_GUIBB_OVS: Let your feeder class implement it and put the feeder class name in field OVS_NAME of the field description. In the OVS phases you have access to the row data via OVS context element, so you can implement row-specific F4 behavior.

Regards, Jens

[maltesh0188]

Hi ,

The Interface IF_FPM_GUIBB_OVS is for free style F4. I donot want an free style f4 I already have the F4 and I just want to redirect my F4 to an existing search help associated with the data element which is available in one of the column(OBJPARAMDATAELEM).

[jens_boeckenhauer]

Hi,

OVS is not WD Freestyle F4 (-> IWD_VALUE_HELP), just following the WD OVS pattern. But anyway, I rather feel that the form repeater does not cover your use case: My feeling is that you basically want to have a set of label value pairs where the type of the value varies across the rows. However, the form repeater is made for repeating equally typed structures, similar to lists but with focus on layout rather than table services (sorting and filtering in lists).

So I basically see the following options for you.

(1) Use fixed forms for each label value pair with dynamic visibility if you can foresee that the superset of types is small.

(2) Use dynamic Form UIBBs (-> IF_FPM_GUIBB_DYNAMIC_CONFIG) for each label value pair and add them by app controller with distinct instance IDs.

(3) Use a completely dynamic WD freestyle view for your label value pairs.

(4) Use the form repeater with fixed value type (probably STRING) and use OVS and dynamic field length (after bug fix).

Any option requires some amount of code. I'm afraid that's all I can recommend.

Regards, Jens

[maltesh0188]

Thanks A lot Jens,

Yeha I Coding is not an problem for me. But if I use the dynamic form UIBB then the problems that I see is that the default config is called only once. As I wrote earlier, how to handle the line actions of adding more rows for same parameter.?

Let me try with dynamic.!

[jens_boeckenhauer]

Hi,

you need to handle the add / remove actions by app controller. For each add you need to draw a new instance ID, so that FPM forces a new form instance. Then GET_DEFINITION and GET_DEFAULT_CONFIG gets called (once for each add, but this suffices). In GET_DEFINITION you build the field catalog for name value with correct type. In GET_DEFAULT_CONFIG you place the label value pair on the UI. The rest is standard.

Regards, Jens