cancel
Showing results for 
Search instead for 
Did you mean: 

Differences between "Customer Controller", "Component Interface" and ...

0 Kudos
173

Who can tell me the differences between "Customer Controller", "Component Interface" and "Component Controller"?

Thanks in advance.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

Refer this threads,

/message/2423617#2423617 [original link is broken]

Regards,

Saravanan K

Answers (3)

Answers (3)

saraswathi_d
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi,

Custom controllers

These are the internal building blocks of a Web Dynpro component and have no user interface. They are only to be used when some unit of functionality is required by several other controllers. For instance, a custom controller could be used, when a BAPI is called, and the information returned requires some sort of intermediate processing before it can be displayed. This custom controller could then be declared for use by several different view controllers. Do not create a custom controller simply because you can! Only use one where its presence will simplify or optimize the component’s architecture.

Component Controller

The component controller is a special custom controller that is automatically created when a component is created. The lifespan of a component is defined by, and equal to, the lifespan of the component controller.

Component Interface: It provides an interface for other components to access its functionality

Regards,

Saraswathi.

Former Member
0 Kudos

Hi,

Custom Controller = Component Controller

Instead of using the Component Controller by default you use Custom Controller which is your own component controller.

Component Interface is used to communicate between WebDynpro Components.

Hope it helps you.

Regards,

Maheswaran.B

Former Member
0 Kudos

HI,

see the diff between custom and comp controller:

Each Web Dynpro component contains exactly one component controller. This controller is automatically created during the component creation and contains a context, events, and methods. Unlike a view controller, the component controller is visible for all views in a component. This means, the controllers of different component views can access context elements or methods of the component controller. For this purpose, the component controller usage is automatically created for every view controller.

This makes the component controller a central location for data exchange between different views of one component. The Web Dynpro framework provides the mechanism of context mapping which is a declarative tool to easily perform this data exchange.

In addition, the component controller allows cross-view method calls. For example, it might be useful to add the call of a function module to a method of the component controller if the function module is to be used by methods of different views. You can then access the methods of the component controller in the controllers of the various views. This enables you to structure Web Dynpro components in a better way and to reuse frequently used program steps.

Custom controllers are similar to the component controller in that they too have no visual interface. However, the existence of custom controllers is controlled entirely by the Web Dynpro developer at design time. Declaring the existence of a Web Dynpro Component causes the component controller to be created automatically, but this is not the case with custom controllers. Custom controllers are only created by an explicit design time declaration.

When should a custom controller be used?

Custom controllers should be created only when their presence will simplify the overall structure of the component. The principles to follow for deciding when a custom controller is needed are:

Reuse

Create a custom controller if you have identified a reuse case for a specific unit of code required by several other controllers within the component.

Task separation

To avoid placing too much coding in the component controller (and thereby potentially increasing its initialization time), place coding dedicated to a specific task into a separate custom controller

Lifespan of custom controllers

The lifespan of a custom controller is determined by a parameter setting made during the design time declaration. It can be either Framework Controlled or On demand.

If you choose Framework Controlled, then the Web Dynpro Framework will instantiate the custom controller when the component is instantiated.

If however, you choose On demand, then the Web Dynpro developer must write the coding necessary to instantiate the custom controller.

All this is from the SAP help, btw. You can find the information here:

1. http://help.sap.com/saphelp_nw2004s/helpdata/en/e2/434941d

b42f423e10000000a155106/frameset.htm

and 2. http://help.sap.com/saphelp_nw2004s/helpdata/en/44/0dca942d9d1ca2e10000000a11466f/frameset.htm

Both Custom controller and Component controller are used to connect to R/3 etc..The benifit of Custom controller lies in providing easy maintenance, bcoz it provides easy reimporting without affecting the View, suppose if you use the CC to connect to the R/3 you should delete the BAPI i/p node from CC and the binded Views.In the Case of using Custom controller, it is eliminated.

Most importantly, custom controller's value nodes should be binded to the Component controller and then to the view.No direct link between Custom controller and View.

and see this link

see also http://help.sap.com/saphelp_nw2004s/helpdata/en/b9/b82c4142aef623e10000000a155106/frameset.htm for information on the different types of controllers.

Thanks

Lohi