Welcome back.
Continuing from my blog - Eureka - FPM ( Floor Plan Manager ) is so simple, today was the second session in the FPM.
Today the topic of discussion was the role and implementation of feeder classes in FPM.
The concepts addressed today were as follows:
The User Interface Building Block ( UIBB ), in the FPM - FLUID editor for the component configuration can be provided with view - freestyle view using Web Dynpro component ( briefly introduced in the steps 5 in my previous blog) OR through feeder classes implementing relevant GUIBB ( Generic UIBB ) classes.
FPM provides generic WD components for FORM, LIST, TABBED etc. Ex: FPM_FORM_UIBB.
Steps to design the view using the feeder classes, are as follows:
1. Open the suitable, generic WD Component - FPM_FORM_UIBB - SE80
2. Create a Component configuration in the component and give a custom name.
3. The FLUID designer will prompt for a feeder class
3.1 Create a custom class SE24
3.2 Implement the feeder interface for form - IF_FPM_GUIBB_FORM.
3.3. Implement the following methods:
GET_DEFINITION - To descibe the structure i.e. fields and buttons and events, to be made available in the screen / UIBB
GET_DATA - Populate the data to the fields in the screen
PROCESS_EVENT - Handle the events defined in the definition using the event ID.
4. Fill the name of the feeder class with the newly created custom feeder class.
5. The FLUID ( Flexible UI Designer ) editor will open a Excel type of designer screen.
6. Open the properties panel which lists the elements defined int he GET_DEFINITION method in the feeder class
7. Drag and drop the relevant elements and button onto screen.
Note: The properties - visual only can be modified in this editor and will override the property defined in the method
Also, there is no restriction of Layout(matrix,grid etc.) in the screen design.
8. Save the configurations
9. Provide the FORM name and newly created configuration name in the FUILD editor of the component configuration created in the step 3 of my previous blog.
You can modify the view layout i.e. order of the appearance of UIBBs in the preview. Also, add more UIBBs, if necessary.
The execution of the main configuration, shows the screen with the UIBB defined.
Note, the execution of the methods in the feeder classes follows the FPM Phase Model concept( This is something of an amalgamation of WD Phase model and FPM eventing - Right now, I have little info regarding it.)
Tip: If a view contains more than 1 UIBB, then on event the PROCESS_EVENT method of all the UIBBs are invoked by the framework. Hence it is performance intensive and developer has to be very careful in the handling of events.
The FPM Apis can be used, in case the view navigation is to handled at the FPM level ex: if one UIBB event should trigger a view navigation from view 1 to view 2.
To summarize, the structuring of the components in FPM is done with a noble intention to promote better development practice. However, it is quite restrictive on the developer. It seems like SAP - FPM has decided what is the best option. Hence, discouraging any scope of manipulation. Also, the process of designing the fields using the FLUID screen designer seemed clumsy and property control at multiple points ( at feeder class level, at fluid editor level, at fpm config level etc. ) makes it difficult to track the changes.
But, Its also a good practice to think of the variables and handle them in definition thus reducing the code and promoting re-usability.
Looking forward for the next class or may be an opportunity to work on FPM.
Thank you one and all.
Regards,
Sharath
- SAP Managed Tags:
