Creating the Components 

Use

In this step we will create all of the components needed for the application SFlightExample.

Procedure

We chose to use exactly one ‘master’ VAC for each step of the application floor plan and one utility VAC for the navigation buttons on the bottom of each perspective. Therefore, we end up with seven components: five VACs (four perspectives plus the VAC for the navigation buttons), one BLC, and one CC. The names and packages for these components are listed in the table (Components for Application SflightExample), below.

We use different packages for every component. For the CC and the BLC, this is merely for convenience. For the VACs, however, different packages must be used, because every VAC will have a window named IVACWindow and it is impossible to have a duplicate window name inside a single package.

Components for Application SflightExample
CcSFlight	com.sap.xss.xssexamples.sflight.cc	CC
FcSFlight	com.sap.xss.xssexamples.sflight.blc	BLC
VcSFlightSelect	com.sap.xss.xssexamples.sflight.vac.select	VAC
VcSFlightDetails	com.sap.xss.xssexamples.sflight.vac.detail	VAC
VcSFlightReview	com.sap.xss.xssexamples.sflight.vac.review	VAC
VcSFlightConfirm	com.sap.xss.xssexamples.sflight.vac.confirm	VAC
VcSFlightNavi	com.sap.xss.xssexamples.sflight.vac.navi	VAC

The BLC and CC are invisible components. Therefore, when creating the component, it is safe to deselect the Embed New View checkbox.

The remaining six components are created in a similar way. For the VACs the checkbox Embed New View can be left checked. Since the automatically generated window name is not the same as the name of the window used by the FPM, the embedded view, however, has to be re-embedded into the FPM Window, as explained see below.

Upon creating all the components, all of the corresponding component interfaces must be implemented:

·        CC: implement interface IXssAppConf

·        BLC: implement interface IBLC

·        VAC: implement interface IVAC

(For more information, see Elements of a Self-Service Application.)

Every VAC must be modified as follows:

...

       1.      The automatically generated component window of a Web Dynpro component is named ‘component name’ + Window. For VAC VcFlightSelect the name is VcFlightSelectWindow. After implementing the interface IVAC, the additional window IVACWindow is defined in the component. Since this is the window the FPM will use, the other window may be safely deleted. Any view defined in a VAC has to be embedded into window IVACWindow to be visible in a self-service application.

       2.      Having created the components of the application, we build the development component for the first time. This will result in a number of errors since some of the interface methods from the implemented interfaces must return values of a certain type (boolean, most often). From the errors reported in the Tasks window of the IDE one can navigate to the faulty methods and make them free of build errors.

All methods with boolean return values should return sensible values, that is the value true for the methods onEvent() and isConsistent() and the value false for isDirty(). This recommendation ensures that the FPM will not stop the event loop when the application runs for the first time.

This should already eliminate three errors per VAC leaving four errors on methods of the configuration component.

The method getCAPState() has to return an object of class CAPState. In this method, we add the statement return null; indicating that we do not implement a context assistance pattern in the first step.

To deal with the remaining errors of the configuration component, where the methods must return objects of types Perspective and ROPState, we implement the navigation graph  and the roadmap pattern for the application.