I know you can implement method IF_FPM_GUIBB~GET_PARAMETER_LIST in your OIF feeder class, to supply a list of parameters which you can then set with values against your GUIBBs.
How do you then use these parameetrs, i.e. what is the purpose, how do you exploit them, as you dont seem to have any further access to these parameters in other methods of your feeder class, for example IF_FPM_GUIBB_FORMGET_DEFINITION or IF_FPM_GUIBB_FORMGET_DATA to have some expression logic behind the setting of field lists/catalogs or data retrieval.
If anyone can indicate if/how these parameters can be exploited within the OIF feeder class I'd be most interested, as I would dearly love to use the parameters in order that I can create for example a generic feeder class for several GUIBBs on the same sub view and control the field catalog setting etc. (i.e. not create a seperate feeder class for each GUIBB).
>as you dont seem to have any further access to these parameters in other methods of your feeder class
While I'm not exactly sure what you are trying to do, perhaps the solution is simple. If you can get the data you want during the GET_PARAMETER_LIST method; why not just save the data into a custom global attribute of the class. That way the data is accessible later during the other methods. Otherise I'm not sure what kind of further access you are looking for.
Perhaps I did not explain well my requirement. Let's say Im configuring a main view of an OIF, and I have added subviews 1 to 5. I add a form GUIBB to each, and can configure each in the GUIBB form editor.
When I'm in the GUIBB form editor for GUIBB 1, I specify the feeder class. And so on, for all GUIBBs 2-5, specifiying a feeder class. Rather than create and maintain a separate feeder class for each sub-view GUIBB (hence 5 feeder classes) I'm thinking of specifying the same feeder class, say Z_FDR_GENERIC.
When in the form editor I add a group to each GUIBB. When I configure the group, it is the method GET_DEFINITION that supplies the field catalog to the configure group field list. I however want that field list to be restricted to fields appropriate to the GUIBB being edited, there may be a different DDIC structure that is appropriate to define the field list for each GUIBB.
Presently I dont see any attribute available that indicates to method GET_DEFINITION what GUIBB is being edited, in order to specialise the field catalog to the GUIBB. Unfotunately class CL_FPM_FORM_UIBB_ASSIST doesnt pass the GUIBB compoent name or configuration name when in method INIT_FEEDER calls the feeder class GET_DEFINITION.
We can add parameters in the GUIBB form editor, from the list of parameters defined in feeder class method GET_PARAMETER_LIST, but we cant access them in GET_DEFINITION to act as our rule base for specialising the field catalog.
To summarise, I'm looking at any option to enable use of a generic feeder class for multiple GUIBBs with the ability to determine the the active GUIBB within GET_DEFINITION and GET_DATA for example. I would want the generic feeder class to handle the setting of definitions and data retrieval for all GUIBB types (i.e. implementing the appropriate IF_FPM_GUIBB_**** interfaces).
Unless there is a better solution I would be tempted to enhance CL_FPM_FORM_UIBB_ASSIST to pass the active configuration name.
I dont know if that is any clearer??
Edited by: Jon-Paul Boyd on Jan 21, 2011 10:32 AM
I have a couple of suggestions based upon some testing I just did.
First is rather different than what you are describing. It really depends upon how generic you want this one feeder class to be. Instead of one generic feeder class with branching logic within it, why not use normal OO Inheritance. Create a generic feeder super class with all of your general processing. Then create children inheriting from it and only redefine the methods that need different logic. Each GUIBB Configuration will then be tied to the specific child class and not to the generic super class. This can still give you a large amount of code reuse, without the complexity of all the branching within one block of code in a single generic classs. In my opinion this is a clearer and easier to maintain approach than what you described.
Another appraoch is to setup parameters. Define the parameters you want to allow in GET_PARAMETER_LIST. Then on the start of configuration, the person doing configuration must indentify which specific GUIBB it is they are working with by supplying a value to this parameter.
The currently configured parameters are passed into the INITIALIZE method at both runtime and configuration time. The importing parameter of INITIALIZE is IT_PARAMETER. You can then save the values from IT_PARAMETER into a class attribute so that they will be available later during GET_DEFINITION and GET_DATA.
Your first suggestion with the superclass with sub classes inheriting from this would certainly meet requirements as this would allow for inheritance of methods doing data grabbing, validation etc, and I agree would be a more elegant approach than a singular class using more logical expressions.
Your second option would also work - I missed the fact that method INITIALISE imported IT_PARAMETER which could of course then be hived off to a global attribute. Provided of course the configurator specifies the correct parameter value.
But both certainly give me options and both meet my needs, many thanks for taking the time to allow me to bounce this idea off you, cheers!